In praise of “normal” engineers

> The smallest unit of software ownership and delivery is the engineering team.

I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years.

It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.

In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)

I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes.

> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress.

But I have to wonder: if "any asshole" can build orgs like that, why don't they? I know of only a handful of orgs that actually manage to build strong teams of really strong engineers, and they're almost exclusively either trading firms or specialized/research-oriented teams. What's stopping everyone else?

I guess this comes down to the initial point in the article: what do we even mean by "productivity"? (Or, the word I'd prefer: "effectiveness"?) There are lots of orgs where only experienced folks can succeed because they're the best at working around and tolerating disfunction. I've seen performance review processes that—intentionally or unintentionally—selected not for some general technical strength/taste/etc, but for the willingness, ability and stamina to put up with management dysfunction. But, to me, that is very much not what I have in mind when I think "top engineer".

There are large parts of this I really like, but it's hard to overstate just how much I disagree with the idea that "The only meaningful measure of productivity is impact to the business". The natural result of this view is a focus on quantifiable changes and short term thinking. The greatest value of experienced engineers is in avoiding landmines that will destroy a project or even a company. It's difficult to quantify things that never happen, or communicate the value in avoiding them in terms that don't sound wildly hyperbolic.

I’ve been lucky enough to work on a number of teams in my career that are full of brilliant high performing people who are also kind, empathetic, and focused working together to deliver something to customers. These days I’m lucky enough to lead a team like that.

Counter to the article, in my experience these are the hardest teams to manage well because organizations typically aren’t set up to deal with them. Larger companies tend to lean into standardization and making things accessible to average engineers in ways that make high performing teams less effective and often demotivated.

I think this is an overly cynical approach that assumes that you can’t invest and grow people into exceptional engineers. In my experience you can if you are willing to invest in it, and the long term benefit of having more high performing engineers who aren’t being restricted from doing good work outweighs the cost of training and growing people.

Some good points, bad logic. The fact that you can't effectively measure something doesn't mean that something doesn't exist.

Individual productivity exists.

Maybe it's easier to measure groups' productivity? Probably.

"Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many extra productive people anyway.

The old problem: judging the work of an expert is very difficult if you lack comparable expertise. I can give you advice, but I can't make you smart to accept it. How could you tell if I'm a genius or an overconfident asshole?

> The best engineering orgs are the ones where normal engineers can do great work

I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.

> Make it easy to do the right thing and hard to do the wrong thing.

This is basically the mantra of every platform team I've worked on. Your goal is to make the easy and obvious solution to engineers' problems the "right" one for the sustainability of software and reliability of services.

Make it easy to ship things that are reliable and manage distributed state well and can scale well and engineers will build better muscle memory for building software in that shape and your whole org will benefit.

This will never stop being true.

At my company, I always prefer hiring average engineers with great attitude. Too many high-credential people with bad attitude were placed on high pedestals due to their perception-creating skills, and became immune to questioning. Once they bag that sweet perception from the boss, they also start bully around. Bosses would usually dismiss any data that goes against their perceptions. Mostly because going by perception is lot easier than looking into the data.

> Are you using golang, python, COBOL, lisp, perl, React, or brainfuck?

For years now I had this feeling that people confuse React with the entire frontend ecosystem, but dismissed it thinking that surely they're aware that there's a whole world of non-React frontend out there?

> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs. It is a HUGE competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum.

This hits close to home for me recently. I don't profess to be a 10x engineer, but I found myself on a team with a few people with much less experience and competence than I am normally accustomed to. I started getting every single ticket with any kind of complexity, because I could get it done, and some people on my team couldn't. I could have continued this way, contributing a massive percentage of the output and claimed to be superior to everyone - but the reality is, for me anyway, this is exhausting (and feels really unfair). Plus I am a little lazy (as I believe all good sysadmins/sre's/ops guys are). I want my team to help me. So what I did was work extra for a few weeks and wrote a ton of abstractions over the most complex stuff we do (I dont write software, I write IAC, I'm aware this is a common pattern in software engineering) so that the less knowledgeable engineers could do the work I'd been doing much of. It freed my time up to work on more interesting problems. This was the first time in my career I had to do this without anyone already ordering me to.

I've been on teams where there was someone like me and everyone else was running around behind them frantically trying to keep up or cleaning up the inevitable tech debt that accumulates. It's miserable and really inefficient.

There are plenty of good "normal" engineers whose abilities top out at following direction from management, implementing a spec (albeit really well), adding to an existing architecture etc. I'd wager the vast majority of the industry falls into this category. Yes, it's very important for an org to ensure that these kinds of engineers are successful, because they are the workhorses of your company and without them nothing will get done.

Ultimately though you can't have a workforce just of these engineers. Someone has to lead. Someone has to tell management what to build. Someone has to invent new tech from scratch.

"10x engineer" is a bullshit LinkedIn thoughtfluencer term that has unfortunately caught on, but everyone who has worked in the industry for more than a day knows that there is a hierarchy in the tech org, and the ones on top are more valuable than the rest.

> Build sociotechnical systems with “normal people” in mind

From the perspective of the composition of software engineering teams: Most of us have to make due with the average, we strive to find the above average and avoid the mediocre, but mostly we are teams composed of "normal" people. The article has some good advice for making the best out of a group of normal people. It particularly relevant because it's unlikely that you'll see anything else.

It's a good article, but does it go without saying that when one says "engineers", it's about "software engineers"?

One reason I clicked on this one is that I was hoping to learn stuff about engineers beyond just software.

But it's a good read nevertheless. Thanks for that!

> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress.

Yeah, it's obviously not true.

If it were true then the market salaries of coaches and trainers in professional sports would be really low. And they aren't.

> The smallest unit of software ownership and delivery is the engineering team. It doesn’t matter how fast an individual engineer can write software, what matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.

Yes, and there are often teams of one. I am currently in such a team. Even though I work on a different problem than other "teams", I think it's reasonably easy to eyeball the relative productivity (not in my favour, in my current circumstances; though, to the credit of my superiors, they're being very patient with me).

> someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are normal

Yep. I’ve been here for a career or so with moments of brilliance and marathons of mediocrity, but consistent kindness (I hope).

> When your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc — when this is just table stakes, standard operating procedure — you’re better equipped to roll with it when life happens.

Resilience doesn’t come from having a “diverse” team on its own. What a shallow take.

True resilience comes from mature teams with strong processes, clarity of roles, and the ability to adapt and recover effectively.

Companies largely have terrible training and books of knowledge which leads to normal engineers not being able to do anything in an efficient manner. Unless they happen to ask a senior a specific tip (which seniors often take for granted and take no initiative to share) important knowledge could get lost forever

You spent all this time talking when you could have been coding.

This is all well and good, but it all hinges on your manager not being an insane maniac. All of those systems are great with the right manager, but if your manager is a KPI chaser / VP position seeker you are cooked.

I have had managers that were essentially like a sergeant, serving engineers as a phalanx against the business so we can go fast.

I have also had a manager who was so obsessed on showing off how much better of a dev he was than everyone else on the team, that he was largely hated and all talent on that team moved away if they could. I moved, and had a much better time in data science.

I largely agree that killer onboarding, and a clear path to deploy are big wins for normalizing your dev culture to new hires. The measurement tech is always a double edged sword.

Discussion on the previous IEEE Spectrum 'version' a few months ago:

https://news.ycombinator.com/item?id=43356995

This is how you maintain/nurture a mature service/product.

It also works when building something new with a captive audience (banking, insurance, etc.)

Everything doesn’t need to be world-class. Sometimes long term development stability/resiliency is what matters.

The article was commissioned by refactoring.fm, which, naturally, features Refactoring AI!

Unsurprisingly the article comes to the conclusion that anyone can be trained, that 10x engineers are overrated, etc. The AI promotion strategy seems to be improving: AI is not mentioned in the article, but individual learning and meritocracy are dutifully devalued to fit the narrative.

Great products are not build by normal engineers.

They are built by Linus Torvalds, Steve Wozniak, Larry/Sergey, Greg Brockman.

I saw a post like this some time earlier this year and my first reaction is the same…

Normal? Seriously?

The article attempts to address this in an incredibly clumsy way by saying, well, everyone is normal in some way! It totally misses the mark and basically pays lip service to the issue after it set the stage, switching over to bigger picture diversity.

Benefit of the doubt, the intention is to say ‘average’. The people in the middle of the bell curve.

‘Normal’ suggests that, outside of that range, you are abnormal if you are terrible and abnormal if you’re talented above or below the median.

There’s a non-zero overlap between abnormal and neurodivergent, both ways.

Given the number of occurrences of ‘10x engineer’ they should have gone with that and not ‘normal’.

I tend to think that much of the difference between great and mediocre engineers comes down to mindset. The great engineers I've encountered have a commitment to making everything they touch better. They are adaptable and persevere. They believe they will either succeed at the task at hand or conclusively determine that it isn't possible given the current constraints. They recognize that failure will happen and do not get discouraged by it and instead see it as an opportunity to growth. When they encounter an issue caused by systemic problems, they will try to fix it systemically. They will not ship the first draft and will take a little it of extra time to get things right, which slows the initial release slightly but more than pays for itself with a dramatically lower maintenance burden.

This type of engineer is often misunderstood and underappreciated by management. Management is often motivated by immediate short term goals. Instead of cherishing the work of the engineers who build the foundational systems that will enable the long term success of the org, they complain about them missing arbitrary short term goals and accuse them of doing engineering for engineering sake instead of real work.

Management will celebrate the coder who whips up a buggy, but cool, feature in a week and will look the other way at the fact that the feature will always be a little bit broken because of its shoddy construction and instead will allocate some lesser engineers to maintain it. If instead the feature had been built correctly from the start, it may have been launched a bit later, but the overall cost will be much lower. Moreover, the poor engineers who are forced to maintain it (and let's be honest, the people who quickly churn out shoddy but shiny work almost never have to maintain it themselves) will not only be wasting their time, they will be actively internalizing the anti-patterns present in the code. This both inhibits their growth and understanding of good design principles and teaches them the bad lesson that crap is good and unless they have a uniquely strong character or good mentors, they will tend to either become demoralized (hurting their productivity and value to the company) or they will internalize the incentive to get out of maintenance work and build shoddy features of their own to pass down to the next poor soul.

The truly great engineer is the one who breaks this cycle by building extendable systems that are correct by design and takes accountability for everything they ship. They raise up the entire org both by their work and example. In the long run, they will be far more productive and positively impactful than the sloppy cowboy coder.

Unfortunately, the industry writ large celebrates and incentivizes cowboy coding so doing the right thing is very much against the grain. Indeed, the people who rise up the org chart tend to be the cowboys so they cannot even see the value of the other way and will often actively antagonize or undermine those who do the right thing (and threaten their dominant position in the org).

I’ve thought a lot about this my whole life. How do you build a good team? People simply don’t like each other so the natural sorting that happens is that teams hire for who they like and likes them in return (or at least in mating terms, will certainly appear as likable as can be). By definition, this can never be the most optimal team.

There may have to be a different way to think about this. How can you have things that hate each other but still run an amazing operation? The best operation I can think of is a zoo. You have your tigers over here, and your penguins over there. The operation as a whole is amazing.

A company of just tigers will destroy everything and a company of just penguins need too much caretaking.

Most armed forces are not a “team”, they are an operation. If you constantly try to fit an operation into a team framework, that’s when you’ll try to turn penguins into tigers (how do you turn someone into a 100x engineer?). Or worse, you tell a tiger to chill out and relax with the penguins (you’re asking for trouble). If you need a 100x engineer, make sure the engineer is a thousand miles away and gets paid like it and far away from the normal engineers lest they start believing the tiger cage is suitable for penguins or vice versa. It’s a big operation, no teams.

If you MUST build a team, then just be yourself. You probably are building something small dogs like, so hire a few street dogs and you won’t even need to worry about zoo-scale decisions and operations. You won’t need to go through the mistake of jamming 4 different species into the same enclosure to finally learn how things live separately but together.

Fuck this. All engineers are normal engineers. Everyone can be an engineer.