The Effective Tech Lead Is a 100x Engineer | Hacker News Reader

The Effective Tech Lead Is a 100x Engineer

hackernoon.com

205 pointskevinSuttle79 comments

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

This is exactly my experience and an environment I avoid working in if at all possible.

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

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

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.

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.

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!

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

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

Well, it sounds like you're one of the few companies that's actually thought this problem through. Bravo!

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

Thank you, this is exactly what I'm getting at.

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.

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.

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

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.

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.

Interesting. Do you have any more write ups on this published?

Also, I love MUBI.

This was a fantastic read that isn't done any service by the CRAPPY title of the article. I can say that they aren't trying to get 10x the work on 1x the budget, but how to effectively manage a team so that your employees feel motivated to work hard for you when they are at work, but aren't stressed by external factors.

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.

Hey @bargl-

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

I loved the article. I fell into a project management / tech lead role and while I love it I have failed at a LOT of things while working through it. I didn't have a mentor to what an effective Tech Lead which I feel like this article serves as. IMO the intro to the article makes up for the title and the content of it is amazing.

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.

If you are proud of your article, why give it a trash title?

I've found the key to being an effective tech lead is to look at the team as an extension of yourself. As a senior engineer there is only so much you can do. Given the right team, you can do much more. This requires you do the planning and specifications, and occasionally pick off the difficult task. However, you must balance your engineering time against the productivity of the team.

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.

Or, to be glib, you now program programmers, and so code in the highest level programming language of all.

I really don't think coining the term 10x did anything to help developers or the state of development, and likewise here.

Companies will probably start assigning us all badges soon like in game achievements/levels.

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

That day is when I’m checking out for ever and retiring. I would prefer to sell coffee over boarding the bs train.

Agreed. I think that the advantage of a good tech lead is that they:

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.

What you are describing also fits the description of a good manager. There is more to management than continuously asking "When is it done?" and the lines between tech lead and manager are very blurry.

Isn’t that the role of the scrum master? I fail to see the value that another layer of management provides vs a good scrum master... and if the scrum master isn’t any good, train them to be.

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.

I also agree that it is not a helpful term.

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.

> I like to think we are all 10x developers

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.

> I like to think we are all 10x developers

Who's "we"?

Great organizations have "10x" teams, not "10x" people. A good organization produces results that are the product of their parts, not the sum (or worse)

Agreed, any real 10x engineer would scoff at the term. I've known maybe a handful of people I'd consider 10x in my career.

> I've known maybe a handful of people I'd consider 10x in my career.

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.

I’ve known developers who couldn’t do certain hard tasks no matter how long you gave them.

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.

Having been on a project with a 100x tech lead who rarely wrote code (but every time it was amazing) due to their leadership position, followed (and preceded now that I think about it) by a project where the tech lead was a 10x engineer who wrote tons of solid, bug-free code ,but was not really a great tech lead, this is 100% true. The difference between the projects were night and day.

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.

Yeah. Reading code is definitely an underrated skill. I always think that Linus Torvals' secret is his ability to read code quickly and comprehend it on a deep level.

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.

I also had the opportunity of working with a 100x tech lead. Their coding skills weren’t that great (although they did very little, so it may have just been what I saw was rushed out), but they had a very good understanding of how all the parts fit together and what was important for the business, which I would say is more important. They were able to bridge the gap between the business and the tech team, and able to manage expectations on both sides without any issues.

You know what happens at 100x? You burn out 100x faster. But you aren't paid 100x more.

Yup, and they are willing to bet you will take a 3% yearly raise rather than look for another job.

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

Wouldn't people who are becoming ctos would already have enough experience to know that ?

"Force multiplier" -- love that you borrowed this term from military doctrine, because that is exactly what a good tech lead is IMO. Per the Wiki definition [0]:

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

[0] - https://en.wikipedia.org/wiki/Force_multiplication

Interesting, I didn't realize the term was so strongly associated with military doctrine. Just assumed it was a glorified way of referring to simple machines such as levers.

I know it's hyperbole and I'm being nit-picky but come on, 100x?

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.

Depends on how many direct reports the person can scale to.

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

I can think of an example, though even this is somewhat of astretch:

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.

Oh, I can see this, ok. I've spent an hour or so googling and debugging something before asking someone who knows the answer and does it in like 30 seconds hahah.

Person A should've considered alternatives and asked around before spending a week on that manipulation lol.

100x'ers do exist. But by Lokta's Law, they occur about 1 in 10000. Usually, a 10x'er is only 1/100 so they are much easier to find. You probably know them as Fellow/Staff Engineers.

I really don't understand what the difference is between tech lead and engineering manager after reading this article. I did exactly these things and also people management as an EM but I spent 75% coding/code review and 25% in meetings/one-on-ones. 30% seems awfully low for a tech lead; is this just like a new term that's been recently birthed in job descriptions? It seems like it's for companies that are too small to have principal software engineers/architects and also too small to have a management track, but they have EMs at Webflow so I'm really curious what the author does in his day-to-day.

1) Can mods change the title to something not-clickbait, maybe even related to the content of the article? The author acknowledges it's trash and does it anyways, but we don't have to. Perhaps "The Webflow Tech Lead Guide"

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.

Stress is more a function of the culture of the company you are working for and can be influenced by your manager and direct coworkers but not by much. Culture is like the weather and is created by the very top level executives.

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.

Why not a 1,000,000,000x engineer? There, I win.

Click bait. Even the author recognizes it in the very first paragraph.

I'm a little surprised that in the article, the tech lead is in charge of breaking up a task into parts. That seems like something a capable SEII should be able to handle, and it only improves them to be able to develop that skill. (Though maybe that means I was a lot less effective as a tech lead than I thought.)

I don't think you're wrong here. Relatively experienced SWEs should be able to do this by themselves. Tech leads should be delegating some of this responsibility to the individual contributors and only offering minor pushback to keep general clean architecture and higher level tech infrastructure goals in check.

I've been a tech lead in the past and am currently a tech lead for a 1-man project. I agree with the sentiments here: if you're contributing a significant amount of code then you're probably failing the rest of the team in some way.

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.

How am I supposed to write a spec so detailed that Junior engineers can build it? To be a tech lead you have to do waterfall development?

I think with these multipliers itd be better just understanding the IQs of the people involved. Two of the most influential Tech Leads of our time had ~160 IQs by estimates: Steve Jobs and Bill Gates.

Good content in your guide to your new tech leads, laying out expectations right up front and giving them guidance. Most companies don't have anything like that, in my experience.

The only "work that matters" is growing food and service people. The rest of this up and coming technology bubble is hubris.

I understand how you grow food, but how do you grow service people?

Yes, but we also need soldiers to keep other soldiers from taking the food. And stone keeps and villages with market places to trade food for goods. And better farming techniques to increase our food production. Also, some more advanced machines to allow better food processing and some textiles. We probably need something a little more efficient than water or steam power. And logistics! Definitely need a way to get people and goods from one place to another. At some point, we'll need to organize all this activity better and start to specialize. Maybe there's a better way to track all this stuff than manual ledgers. Wait, we can leverage electricity and simple lever machines (up/down or 0/1 if you will) for tracking this stuff. Perhaps if we connected all these machines together into some kind of a network . . .

If every neighborhood had a lot designed to produce food for every person +1 we wouldn't need so much logistics and lever machines.

Yes, but the wrong one can be 100x the failure. This goes for all leadership positions.

Only comments here discussing the shittiness of '100x' engineer, despite the first paragraph of the article specifically stating that a good Lead is a force multiplier of a team.

Read the article.

I think people are upset with the NNNx stuff people use. My instant reaction to seeing this headline was one of mild disgust - I cant bring myself to read the article.

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.

To be fair, the article starts off with "Hyperbolic click-bait title aside," which goes to show the author knows exactly what he's doing there.

Agreed title and even intro paragraph do this article no justice.

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

Massive oversimplification, but still... In a world where clicks are driven by upvotes and retweets and shares and so forth... Gaining early attention is vital.

Reply on news.ycombinator.com