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.
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.
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.
> 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.
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.
> 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)
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?
> 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!)
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.
Also, I love MUBI.
The basic premise is how do you as a manager give your team 10x time to actually work, focus on work, and enjoy life.
Please don't be deterred by the terrible title. Or even not so fantastic intro.
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.)
For example, I've pushed back on management about deadlines because developers hate them and it causes stress / stagnation. BUT the business needs them and I love how you talk to that in a way that I can effectively manage both up and down. Thank you very much for this. If I'd read it 4 months earlier I'd have missed some major (self inflicted) pain points.
My number one goal as a lead is always for my team to come in and work without interruption. Everything they need to complete a task should be in the task management software. This is what I want as a dev, and so is what I aim to provide for my devs. This doesn't mean writing all the specs myself. Give the devs enough info to write their own tasks and review them before they start. This is manageable up to about 6 people. If you have a bigger team, then you need sub-leads to spread the load.
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.
Well, that's why the author had to call tech leads "100x developers". x inflation has led us to this situation where 10x is now a baseline minimum. Anything under 100x is just mediocre.
1) Make sure that the people working for them are happy and challenged
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.
I thought it was a well written article though, and the author’s company sounds like the best environment to be in with a tech lead.
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.
I've only known one. And having that type of engineer isn't necessarily all it's cracked up to be.
The other members of the team would discuss a problem, hash out a couple of potential solutions, and then begin assessing how long it will take and who will do which parts.
Two days later the 10x engineer would drop an amazing implementation of the solution into our laps.
The result is that everyone else on the team got demoralized and stressed about whether they were going to have meaningful work to point to in their performance assessments. The entire team ended up blowing apart.
The defining feature of the 100x tech lead for me was their ability to do code reviews-- with a tilt of the head, they would point out something that no one else thought of and helped make the code better. I really wish I had the ability to review code that way that 100xer did.
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.
> 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.
"Force multiplication or a force multiplier refers to a factor or a combination of factors that dramatically increases (hence "multiplies") the effectiveness of an item or group, giving a given number of troops (or other personnel) or weapons (or other hardware) the ability to accomplish greater things than without it."
 - https://en.wikipedia.org/wiki/Force_multiplication
10x already sounds a bit like exaggeration, but implying there's an engineer out there who can do the same amount of work in 3-4 days as a normal engineer in a year is too much lol.
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.
Person A should've considered alternatives and asked around before spending a week on that manipulation lol.
2) Does anyone know of any data to support the 10x/100x idea? I hear it thrown around so much, but it's always struck me as an echo chamber kind of self affirmation to support questionable hiring practices and cop-outs.
As far as the legend of the 10x or 100x developer, technically it does exist in the sense that the smart lead will not even entertain time wasting efforts, so to calculate the value of that you could say is infinite x.
I’m skeptical however that you can transfer your extraordinary abilities to your team members. The most brilliant productive people I cant imagine they can truly transfer that to others. Their ability comes off more like a God given gift, so to speak. Surely they add value individually and add value to each team member by their guidance and mentorship.
The 10x concept though somewhat confuses the truly important question, both to the technical programmer employee and their capitalist business bosses. How much value is really being added and at what cost.
It's hard to be on top of everyone else's work, the architecture, the weekly planning and the external team syncs while also trying to write features.
Being alone, I'm basically taking shortcuts to get results until I have more bandwidth or get a team member to help shore things up. The goals and deadlines were set way above my head so unfortunately outcomes are prioritized as it stands.
Read the article.
> 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.