The Effective Tech Lead Is a 100x Engineer (opens in new tab)

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.

> 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 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.

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.

> 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!

(fyi, I'm the article's author)

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.

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.

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.

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.

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.

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 like to think we are all 10x developers. The question of a 1x developer should be how to grow their productivity (assuming they are motivated to do so). Less productive developers should not feel like they have one tenth of the natural talent someone else has. Instead they should look at how they can improve their work flow/knowledge and companies should try and maximise the output of their employees.

Yes some people will always be better/more productive than others, but most people are differentiated by completely controllable factors.

1) Make sure that the people working for them are happy and challenged

and

2) Remove any roadblocks required for developers to solve the problems that they are working on (I would say "write code", but I don't think that the ultimate measure of developer productivity is how much code they write).

I think that good tech leads should help to keep productivity growing mostly (almost?) linearly as the engineering team grows.

That fact notwithstanding, I’ve never met someone more than 4x faster than anyone I would consider adequate. Maybe that says I have demanding standards (likely). Maybe that means I’ve never been in the presence of great developers (less likely).

What I have met is people who value their own productivity over that of the team. They create code that slows all but themselves down. The more clever the person the worse the damage. I have no doubt that such a one could force a situation with a ten to one ratio, especially with developers without the self esteem to push back.

100x 200x gives me an idea for terrible clicker game.

But I agree 100x is a little high. If you have a 10 person team and they all can do 2x what an unled team, The math might work out to be a 10x team lead. But there I go trying to use Math to justify hyperbole...

Suppose person A takes 40 hours to write C code to manipulate a large data set.

Person B puts the data in a database and is able to write commands, which only take 10 minutes, to achieve roughly the same thing.

  > There are two kinds of blog post titles
  >
  > Those that everybody complains about, and those that
  > nobody has read, because they attracted no attention.

I dont have data, but I think the whole 10x circle-jerk is harmful to our profession - non-technical people (e.g. managers, HR etc) think it is "a thing", which means we end up working with "10x" jerks and/or are getting pressured into working overtime/weekends etc so that we can live up to this unrealistic "10x" benchmark/expectations.

I'm the author of that article and I couldn't agree with your summary more.

"The basic premise is how do you as a manager give your team 10x time to actually work, focus on work, and enjoy life."

Thanks for sharing that!

(Also, apologies for the click-baity, terrible title, lol. I tried to make light of it in the article.)

> How can I avoid burning my team out?

If a team can't meet a deadline, it's a management problem, and not the team's problem. This means that, somewhere along the way, the project didn't go as planned and a course wasn't corrected. So, Rule Number 1 to avoid burnout is "Manage the project and expectations well" (See: Help! We are behind schedule!).

Rule number 2: Never ask more of your team than you would ask of yourself (and you mustn't ask yourself to work nights and weekends). Other organizations might ask their teams to pull longer hours when the going gets rough. This is a laser-focused bullet train to attrition and long-term inefficiencies. Webflow cares deeply about its team, not only professionally, but personally, so we must do our best to manage our time well.

I am pretty good at reviewing single blocks of code but if you dump a complex system on me I struggle to comprehend it in depth within reasonable time.