A friend and coworker of mine from Zynga, Ellen, maintains a Slack group of tech leaders from various companies that I'm a part of. Recently, Ellen shared the following article on engineering leadership with the group: The Engineer/Manager Pendulum.
I found it really insightful and echoing a lot of thoughts I've had, but hadn't been able to articulate. Here is a couple of excerpts from it that really rings true to me, and some points that I'd like to add to them.
What one can learn from the pendulum
The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.
And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum.
...
Conversely: the best tech leads in the world are always the ones who done time in management. This is not because they’re always the best programmers or debuggers; it’s because they know how to get shit done, which means they know how to communicate and manage other people.
Up until the last few years, I had been stubbornly avoiding getting into a people management role. My nearly-6-year tenure in Zynga was spent squarely on the individual contributor / architect track. I took something that had some truth to it -- that "I'm not a people manager type" -- and mentally went all-in on it and did not even consider the possibility of going into management. (Zynga, like most large tech companies, had a management track and an IC track, so this was not an issue. As an early employee and important IC, I leveled up quickly from Software Engineer through Principal to eventually Architect.)
Stumbling upon a hybrid team lead / manager role
After shutting down my startup CoinTent (where I spent 3 years hacking up products and running dev ops, doing nothing about team management or tech leadership), I was made an offer to join Massdrop as a Principal Software Engineer, first as an IC. Soon after I joined, a team lead role had opened up. Since I had expressed that I wasn't really into people management, I was given the opportunity to be a hybrid team lead -- giving technical guidance, direction and planning for the team, but not having to do the meaty people management stuff (like holding 1:1s, performance reviews, that sort of thing. I would be able to still do some hands on coding with the remaining time that I had.). The Senior Director of Engineering offered to run those 1:1s himself for my team members directly, so my team would all officially direct-report to him instead.
Even then, I learned a lot about team leadership from my brief time there (I was in that role for only about a year until I moved for personal reasons -- mostly to switch to a fully remote company, instead of working in San Francisco any longer.). I must admit that having been an IC for a decade+ before this, it truly had not occurred to me what all the things are that a team lead is responsible for and why team leads are apparently perpetually busy and hard to reach. Why are they never available even though they barely get any code done?
What does a team lead do?
Let's look at some scenarios. We could get started with the various leadership meetings you'd be regularly in. Those take up a fixed amount of your work days every day -- whether it's project planning, meeting with business operations teams about their needs, or with product managers on consumer product (I've had all of these regularly). But that's the typical stuff you already know about. Let's talk about the remaining hours of your day outside of those meetings instead. Say you run a team of 5, and 4 of them have one question for you that day. Each question takes you anywhere from 15-30 minutes to answer and/or starting a conversation; whether it's because there's some issues they need help figuring out, or because they need some context in feature development, or some direction in design approaches. There goes most of your day. You only had 2-3 hours of non-meeting time to begin with, so those are the same time slots your team will reach out to you because they can actually find you at your desk.
Gaining insights and a new appreciation of team leads and their actual work is just scratching the surface of it. Then there's the real challenging part of being a team lead, which is dealing with humans. This is not about people management; but about actual tech discussions and direction. Working in a company of any reasonable size, you'll inevitably work with many different personalities on the team. Being a tech lead is not about ruling with an iron fist, that this is the system architecture you've designed, and that everyone is doing it this way now, or having everyone develop systems you designed. On any team with intelligent engineers, from a team of 5 you'll get 5 different ideas and system designs to solve a business problem. Your job as a tech lead is not just to evaluate the ideas based on merit, business context, time-frame; but also to facilitate discussion and narrow down on a solution design, while keeping everyone happy and productive and making sure no one feels like they haven't been heard or respected; all the while making sure progress is made in a timely manner (i.e. quickly) and moving forward in general! Think about this again. This isn't people management work; this isn't holding 1:1 meetings or performance reviews. This is the work that a tech lead does.
On working with people
The experience I described above echoes the following excerpt from the article:
They still need the full manager toolset. They’ll need to know how to rally people and teams and motivate them, or how to triage and restart a stalled project that everybody dreads. They still need to connect the dots between business objectives and technical objectives, and break down big objectives into components. They need to be able to size up a junior engineer’s ability and craft a meaningful assignment, one that pushes their boundaries without crushing them … then do the same for another twenty contributors. This is management work, from the slightly shifted perspective of “Get Thing X Done” not “care for these people”.
So these tech leads usually spend more time in meetings than building things, and they will bitch about it but do it anyway, because writing code is not the best use of their time. Tech is the easy part, herding humans is the harder part.
I feel that one of the more important and more delicate aspect for a tech lead to "herd humans" (in order to "get shit done") is to both know the personalities of your team members very well, as well as utilizing their strengths correctly.
Some of your team members come from backgrounds that have taught them to build for the proper engineering solution, for the long term, not incur tech debt. Sometimes, with the business context you have as a tech lead, you know that speed is necessary and sacrifices are needed. You have to juggle this delicate balance, while keeping the team happy. In other cases, it might be the total opposite. You got a builder in your team that's about coding up features as quickly as possible; so you'll want to encourage proper unit testing, documentation, and thinking of edge cases.
Some of your team members will have strong opinions. They may be right a lot of times, and sometimes they may be right only because of the context and background they came from. Either way, they are imposing strong opinions on other team members. In cases like this, your job may be to keep an open mind and listen and take what is appropriate. In some cases you may have to hold your urge to defend your solution in a technical debate (that most engineers tend to do); and sometimes you might just be surprised how much merit the idea/design of someone with the opposite opinion of yours actually has. Your job is to keep things moving, and keep things moving forward; and not dwell on "who wins" the technical debate.
Sometimes less mature engineers like to debate for the sake of debate. Your/other team members' solutions are not wrong, but they like to point out what the issues are, what edge cases are not being covered, and so on. In those cases, know to pick your battle and let folks take the position they insist on but keep things moving forward. You'll notice that's something I'm repeating, because that's really the key here -- move things forward and get things done.
Of course, in yet another scenario, you could have a team member who has too weak of opinions but have brilliant thoughts. It's also your job to draw out ideas from these folks.
Ultimately, being an effective tech lead is about getting things done. It's both about getting things done yourself, and making sure that your team gets things done (and coherently). In some cases that aligns with proper engineering. Sometimes it doesn't. And even when it doesn't, it doesn't necessarily mean you go cowboy all the way. There's a balance to strive for. In certain other scenarios it could align with cowboying code. There's just some things and some time, in a business, where the thing has to ship tomorrow. You have to understand the context fully and the consequences fully and know what needs to be done. That's the job of a tech lead.
Oldest comments (0)