Ontra By Carrick Rogers, director of engineering, applications at Ontra
When you get bumped up to tech lead, one of the first things you do is schedule regular one-on-one meetings with your reports. The person who used to manage you probably had one-on-ones with you, and your new boss probably does as well; so, naturally, you follow the pattern and set up these meetings, just because that’s what management does.
You can dive into almost any pre-canned training course to get the basics of one-on-one meetings. Most of them say the same thing: schedule them regularly and start with some small talk to socialize. After that comes the problem. From there, the common direction veers into what I like to call “how to manage your report without your report realizing they are being managed.”
In reality, however, your reports are not oblivious; they’ll realize that management is going on. In fact, this blog post comes from a real-life training session I recently did. There, the trainer passed out example worksheets for your report to fill out before the one-on-one so they’d show up with a status report in hand, ready for their weekly dose of management.
The approach that doesn’t work
I have a fairly strong, adverse reaction to this “managing your report without your report realizing they’re being managed” approach. Here’s why: as a technical lead, you have the day-to-day task of running a team of engineers that can build solutions to problems. The longer-term mission is more expansive. You need to turn your junior engineers into mid-level engineers, your mid-level engineers into senior engineers, and your senior engineers into staff engineers.
Your ability to do the day-to-day tasks makes the product team happy and earns you praise in retrospectives; your ability to get the longer-term tasks of development is what makes talented engineers stick around and work hard for you. The bottom line? The minute an engineer thinks advancement under you is impossible, they’ll seek employment elsewhere.
The other side of that coin? Advancement, of course, takes time. Software engineering is an industry where experience comes denominated in years. If you bump someone from junior to mid-level engineer, it takes years after that raise to prepare them for the jump to senior engineer. You need them to stick with you through that process and for them to believe they can earn that next level under your leadership. They also have to enjoy working for you over the period it takes to get that promotion and associated pay raise. It’s all about mutual trust between tech lead and engineer.
The solution?
Regular one-on-ones are where you build that trust and that helpful rapport. That’s what makes them critical. In these one-on-ones, you’ll likely use some variation of a leveling matrix for analysis. Your report has a level, which, in turn, corresponds to a row on that matrix. Each row has several columns listing out skill expectations for a number of elements (technical skills, soft skills, leadership, etc.). The report earns promotions by exceeding the requirements of their row and progressing into the next one. So, in your one-on-one (at some point), you’re going to need to discuss how a specific cell in that matrix may take a significant amount of time to show skill growth.
The minute you bring project status into your one-on-ones, you’ve tainted the meetings. One of two things will happen during that status report. First, for a positive report, you’ll praise the individual for their hard work and progress, establishing an atmosphere of praise as the norm. After all, people like feeling good about themselves; this creates an incentive to spend the meeting seeking “instant gratification” with project-related praise, rather than having the hard conversations about growth.
The other option? In the case of a negative report, no matter how constructive the criticism might be, it’s still a scenario where the boss is “calling them out” on the carpet. If you call a report out for the first half of the one-on-one and then spend the other half of the meeting talking about how they’re at least a year away from their promotion to the next level, congratulations: you’ve likely done a fantastic job of demoralizing your report.
Finding the right one-on-one balance
It’s key to keep status report-seeking behavior out of your one-on-ones. Obtain them during your team’s regular workflow. Have a sprint cadence with regular standups of some type, along with regular reviews of your backlog and (of course) retrospectives. If you constantly crave status reports, ask yourself why the everyday workflow doesn’t meet those needs and then change the workflow. Don’t let status reports creep into your regular workflow.
Another thing to remember? Total inflexibility is terrible management. At times, the status of some projects will be the most pressing thing on a report’s mind when they come into the one-on-one. They may have specific needs (like a code review or a larger, general concern). Remember, no matter what it is, it takes a lot of courage to tell your manager, “I have a problem.” To reply “We don’t talk about those problems in this meeting” is demoralizing in its own right.
You need to acknowledge concerns without letting the meeting veer into a status report. I tend to treat these situations as the report asking me for more time. If they need a code review, I’ll schedule an hour later for a pair review. If they need something else, I’ll see about setting a solution to that issue; once we address that concern, I’ll steer the meeting back toward socialization. That’s when we’ll build rapport, discussing career growth and other issues. This approach also has the benefit of signaling to your report that no matter how crazy things are in engineering, you’ll always have some time to talk to them about their career path.
Using one-on-ones to be a good tech lead
Ultimately, this is one of those situations where there is no universally correct answer for the content to cover. I wrote this from the perspective of managing someone actively seeking a promotion; yet, in the case of a very senior engineer, they may see themselves more as terminal when it comes to their title. This person might just look for assurances that you see them as a person and not a disposable resource. With that kind of employee, you’d veer more toward small talk and getting to know each other, for example. However, remember this: turning your one-on-one into an exercise in status reporting (in ANY case) won’t create the space for your report to discuss what matters to them.
Explore Ontra’s career page to learn more about open positions in engineering and other departments.
