> The Tech Lead is a “hybrid” role with one foot in management and the other in engineering
I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more defensive/territorial than directing/guiding. In the end they end up more of a dev with super powers who has a veto over every other developer's technical decisions, but is still primarily concerned with completing their own contributions rather than the project and team health as a whole. In the best case, they do split work, delegate, mentor, and lead meetings, but always end up doing the business critical or challenging pieces themselves (because why would I take the time to explain this when I could just do it...), and in the worst case, they don't delegate at all and actually communicate even less than they did as an individual contributor.
> The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management.
I call this being a "dev++", and I think it's an unhealthy mindset for leadership. Moving into leadership means advancing beyond the tasks you used to do. This is true everywhere, and lack of promoting yourself beyond those tasks will drag you down. This goes all the way up to c-suite level, where people fail due to focusing too much on their old group and job, and neglect all the new groups they inherited in the promotion.
I've been an individual tech lead for a few years now, and am about to take on a team while still maintaining the technical leadership role. I'm basically going to be a blended technical lead, project manager, and people manager. The only way I could do this was to stop coding myself. If I'm coding, it's to investigate an issue that has stumped others, or do a proof-of-concept for a particular technology or pattern.
Otherwise, my time is entirely devoted to helping individual developers increase their understanding of our stack or engineering in general. Or, on the other side, sitting with business and understanding requirements so that I can determine how engineering will approach the problem. I then delegate that vision to the engineers to implement, with code review closing the loop.
I have been a non-coding tech lead before, and I do not understand how a person can both code and manage others without working overtime. Coding requires hours of uninterrupted focus time every day. Management requires making yourself available to help people. You cannot be both available and not available.
It's taken me a while to get to this point, but I enjoy the challenge of managing both sides of the house. I've learned that if I participate in a non-tech meeting, there is a high probability that I will be useless at coding the rest of the day. For that reason, I arranged my schedule to have almost all meetings on Mondays and Tuesdays. I've also learned that coffee helps me express my vision more effectively but can ruin my concentration, so I use it for "people" days. Also, little technical interruptions don't bother me so much as interruptions that get me thinking about a new course of action. When I'm not certain about the course of action I go into processing mode until I figure it out, which keeps me from making any coding progress. Recognizing those interruptions and logging them outside of my brain for later processing has helped a lot. I'm sure I have a few other little tricks too... Routine is really key for me.
My team is small and nearly everyone works well independent of my management. I expect that my coding time will diminish as the team grows larger.
I found this role was still manageable when my coding was just tools for the team with lose deadlines. Once I have to help out with production features on a deadline everyone suffers because all my time is on coding not helping everyone else.
You're describing individual personality shortfalls, not problems intrinsic to the role.
> In the best case, they do split work, delegate, mentor, and lead meetings, but always end up doing the business critical or challenging pieces themselves (because why would I take the time to explain this when I could just do it...)
The best case scenario is seeing yourself as a facilitator first and foremost. A tech lead that succeeds at delegating, mentoring, and developing their peers does not need to do the business critical work ... peers should be able to do so, with some light oversight (design/code reviews). If some complex/business critical work is a couple months away, the lead should proactively work to disseminate their knowledge.
This parallels management - a bad manager micro-manages execution, a good manager builds mostly autonomous teams... a bad lead engineer micro-manages execution, a tech lead oversees a team of mostly autonomous engineers.
Sure, your team will move slower at the beginning. But think long-term, maximize the integral.
I have been in this role at my previous job - I had the responsibilities of an engineering manager and a team/tech lead.
I focused on my team's productivity/management responsibilities first, and coding/my own technical productivity second. Even doing that, I was able to do so much coding that after I left, I heard that someone said that the company would have to hire 3 senior devs to replace just my coding. I was generally very hands off and tried to foster autonomy in my team as well, deferring to my team's judgment/expertise.
The people do exist, but I think it's a terrible idea to expect most engineers to be able to jump into a dual technical lead and manager role, as I don't think most engineers have the skills to pull off both.
Yup, great call out. As a Tech Lead your team productivity takes precedence, even if that means you don't spend any time coding during a sprint. That's why it's a different track than a IC or subject matter expert.
I agree. The most important question for me when looking at a position is whether the team has a lead or manager, if they have a lead it is a bad sign. They are too busy coding to manage, they are territorial and are responsible for the all the important, business critical, high profile pieces.
I wish leads did veto more - often I am "delegated" a task, spend a week on it, then they look at it and tell me to it a different way - a way they could have told me to do at the beginning of the week and not have wasted my time. So then I spend another week re-doing it to the way they want.
I should note this dynamic is at play not just for programmers, but for devops and other groups as well.
If you have a task that will take 5 days and someone has the ability to veto the design of the deliverable at the end, you need to talk through the design before you commit to it. Spend a few hours working out what you'd do, then whiteboard it or even verbally run through it.
It's worthwhile doing even if you wouldn't have ended up with wasted effort - other people can have helpful suggestions of things to look out for, or minor refactorings you might do along the way.
I want to add that the title "Tech Lead" doesn't always mean the person is a half-dev/half-manager, nor does the title "Manager" indicate the person has totally stopped coding. Often times, the "Manager" or even "CTO" title will be held by the principal developer. It's also possible to find "Tech Leads" whose duties are 100% management, but they cannot bear the title for reasons dictated by HR.
These are all fantastic points and are in the forefront of our minds as we support our Tech Leads in their difficult charter. I'll do my best to explain how we (at Webflow) mitigate such situations and why we find them symptoms of larger issues in our organization. First off, this requires a top-down commitment from leadership and clear expectations on their behalf. It requires us to provide our leads with the tools they need to succeed, hence the guide and the support systems it outlines. We have Engineering Managers at the helm who check in with each lead often and help them juggle their responsibilities. We also make our Product Managers aware of the Tech Lead's role and responsibilities and ask that they speak up if they see these struggles forming.
> The type of "management" they do then becomes more defensive/territorial than directing/guiding.
We do our best to limit defensive/territorial attitudes and have an open debate/decision protocol to iron out disagreements as they arise in a healthy and supportive manner. We encourage such heated, albeit respectful, discussions -- these are bound to happen when you hire talented, passionate folks -- while reinforcing team consensus and a need to work together (no winners/losers). Again, the more our leads see leadership behave in such a way, the more they are empowered to behave likewise.
> always end up doing the business critical or challenging pieces themselves
I admit this is tricky. Success here comes down to practice, which is something a lead learns over time. We have a couple ways to handle this. First, we have our rework/defer/abandon model, which provides some breathing room for deadlines and gives our leads a moment to pause and collect themselves, and gives them time to reconsider how best to delegate/mentor. And second, as most leads tend to be perfectionists and can easily fall into the trap of micromanaging, we discourage "prescriptive" advice in code reviews, such as "doing the work for the reviewee," and encourage outlining outcomes (with some supportive materials) so their team members can tackle the problem autonomously.
With all the above said, really it all boils down to the example leadership sets and how they go about supporting their tech leads. I hope that helps!
It sounds like you're aware of some of the problems I listed and have come up with novel solutions to them. Why not just employ true managers? What benefit do you get from having people who are half-in, half-out?
How do you deal with the fact that most developers do not like management? Have you ever had a Tech Lead who didn't want to actually manage other devs, but just liked having extra authority and access to stakeholders? What do you do, then?
Well, we do employ "true" managers (if by true you mean "people" managers), too. There are two types of managers in our org: people managers and technical managers. Tech Leads are the interface between product and engineering. Engineering Managers are the interface between Engineers and Webflow/life/career/support/advocacy. Tech leads do have to possess some people skills, too, but their technical expertise makes them key for playing that role and for setting expectations. That said, they can improve their people managements skills as well, which gives them a glimpse into if they might enjoy moving into Engineering Management.
> How do you deal with the fact that most developers do not like management?
The role is completely optional. It's a "hat" that our engineers pass around when someone wants to improve in that area or wants to create momentum in something they believe in. Once a project is over, the Lead can simply take the hat off if they do so choose. It's our job to make the role so enticing that they _want_ to pursue it. That's tricky, but that's why we write these kinds of guides. :)
> Have you ever had a Tech Lead who didn't want to actually manage other devs, but just liked having extra authority and access to stakeholders?
We've normalized the Engineering, Tech Lead, and Engineering Manager hierarchy. Each have specific roles and responsibilities, but they are all considered the same level, and have relatively the same access to stakeholders and possess the same authority in their respective domains. We want someone to take on the Tech Lead role because _they_ want to, not because it's a power grab.
> What do you do, then?
If that were to happen, however, we'd likely encourage the behaviors we wished to see by also demonstrating those behaviors ourselves. We try and remove the "power" incentive from the equation, and instead reward the role for being a force multiplier. This is a trick I picked up from some of the amazing managers at NoRedInk. (thanks Josh Leven!)
It's possible. The priority is management first so the team has everything they need. Cover for them, take all the blame, and make them a success. The technical experience is primarily so there is trust and authority when you have to make changes based on technical reasons, something that often gets lost in translation when it's not happening in the same brain.
We tend to prefer the word "role" over "position," these days. I think this hints at a quasi-idealistic blindspot we tend to assume, when it comes to questions like these.
Ultimately, you can't reason about this (IMO) without accounting for the hierarchical aspect. Saying "dev with super powers is similar to saying ""dev with one foot in management" because it captures roles and hierarchy. That's all you really need to know. There are mundane aspects to this: "engineers ... find their own powers magnified 10-fold..." Managers impact the work of multiple people, therefore... multiplication.
The less mundane aspects of this are sociological. Cultural distinctions, I guess you could call it. For example, in a not-so-long-dead culture, "X with superpowers" was how most professions worked. The called it masters & apprentices. A brilliant master, aided in his productivity by apprentices and journeymen was a rhetorical ideal.
The modern ideal feels a little confused. Our ideal seems to be (eg, our vocabulary) non-hierarchical. Leading is a role, not a position. OTOH, I think this makes us avoid some questions.
I agree. The two skill sets - management and technical ability - rarely overlap strongly, and even when they do, the person is usually comparatively better at one or the other where they're better off focusing - and I mean comparatively with reference to https://en.wikipedia.org/wiki/Comparative_advantage .
When someone is strong at making technical decisions, they'll also want to own the delivery of the most technically challenging bits - the bits they'd be best at. That either crowds out growth in the team (if they do it), or they swallow their ego and deliver something they're not fully happy with (if they delegate it), which isn't a whole lot of fun either.
There is a middle ground of delegating, and then refining approach as the team works. Of course, this must be done judiciously. Doing this for non-functional reasons like coding style will get quickly tiring to both the lead and the team.
On the contrary, if you don't code, you risk becoming too detached from the realities of the project. Not only that but you're also left behind in the macro sense of losing touch with the state of the art in general.
Never in a million years would I want to be an engineering manager (tasked to lead a team on a specific project) with no technical contributions to my team's work. The best kinds of contributions are those that are less fun or less critical, but being able to understand how things work and be able to give legitimate concrete feedback on work artifacts fosters the most important thing as a leader: trust. Spend too much time away from making the sausage and you risk letting those terrible words slip from your lips: "why don't we just..." :)
This is worth the trade-off in lost time towards other less critical management tasks (and of course there are critical managenent tasks that will always overrule everything else.)
One hack worth mentioning is that certain large categories of management work are corellated with the number of awake humans on your team, so if you can find a local minimum there that can be coding time with minimal opportunity costs.
> but always end up doing the business critical or challenging pieces themselves (because why would I take the time to explain this when I could just do it...)
If you're not doing design reviews + socializing large technical decisions/reasons then you really shouldn't be a Tech Lead in the first place.
> The amount of time these tech leads spend coding necessarily expands
FWIW this is the exact opposite of what I've seen at a Fortune 500 software company. Literally the job requirement is to spend less time coding and more time mentoring.
Counterpoint: I've made a 20-year career out of doing exactly this role, and it's been great for my career and for my teams. For me it's just another level of the specialization question. Just like being a specialist in some hot field will get you outsized compensation from a Google or an Amazon, it will also make you struggle in environments where you have to wear more hats. If you want to remain a pure IC and move up the technical ladder, you are A) limiting yourself to companies that have an honest IC tech ladder and B) at the mercy of whatever management you happen to land under.
Even your "best case" scenario is someone who is laughably incompetent at management, akin to a programmer failing fizzbuzz. Obviously there is some truth behind the stereotype of the incompetent manager promoted up from an IC role, but management is a skill that has to be learned. No one is surprised that it takes years of intense practice to become a competent programmer, but somehow there seems to be this feeling that management is based on intrinsic unlearned "soft skills". Nothing could be further from the truth. To be a good hybrid tech lead you have to first understand that management is a skill, and that the success of your team is by definition more valuable than your IC contributions.
Obviously doing this hybrid role comes at a cost in each of the respective skills, but having both management skills and technical skills in one brain is highly valuable in many situations. First of all, it's a clear win in early-to-mid-stage startups where you're too big to have everyone in a daily standup, but not big enough where you can justify the overhead of full-time managers. But more generally, as a hybrid tech lead, I can communicate up, down and laterally with more efficacy across the board. When communicating up or laterally I can more effectively speculate and brainstorm about technical approaches at an earlier stage without disrupting other devs who are in a flow state or are liable to get stressed out by blue sky ideation when they feel management does not respect the work that will get dumped on them. When communicating down, I can speak the language of the front-line engineers, and garner a lot more respect than a manager who offhandedly makes clueless statements that undermines their authority based on unfamiliarity with the code.
One way I can be optimally deployed is to build a new team from scratch. I can build a prototype and engage cross-functionally by myself initially, and then if it turns out to be something we want to invest in, I can smoothly add in other resources, recruiting from other teams, or hiring them myself if necessary. Unlike a pure IC I will not chafe at my shifting responsibilities, I will embrace the management aspect and be happy to turn over authority of the code base to new blood coming in.
I'm not a perfect manager by any stretch, I see a bit of myself in some of the horror stories for sure, and I learned a lot of lessons the hard way. However the hybrid qualities pay huge dividends. Specialization is for insects.
I may have a limited experience but I've never seen an effective Tech Lead who was a hybrid like this and I have serious doubts it's even possible. The amount of time these tech leads spend coding necessarily expands and consumes the time they have available for management. The type of "management" they do then becomes more defensive/territorial than directing/guiding. In the end they end up more of a dev with super powers who has a veto over every other developer's technical decisions, but is still primarily concerned with completing their own contributions rather than the project and team health as a whole. In the best case, they do split work, delegate, mentor, and lead meetings, but always end up doing the business critical or challenging pieces themselves (because why would I take the time to explain this when I could just do it...), and in the worst case, they don't delegate at all and actually communicate even less than they did as an individual contributor.