Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Someone has been an Engineering Manager for a few years and although they’re good at it, and probably making decent money, they’re a bit tired of the role.

“Would it be stupid to go back to being an engineer?”

Life sometimes feels much simpler as an IC.

And apparently quite a few managers are thinking about it.

LeadDev’s Engineering Leadership Report in 2026 surveyed 600 engineering leaders and found that one in three managers are considering going back to being an IC.

That’s quite a lot, but I think there’s a question you need to answer before you do make the move.

Do you actually want it?

I think there are two reasons why someone might want to become an engineer again.

The first one is that you don’t enjoy management anymore.

You stopped caring about roadmap planning, performance conversations feel draining, you’re bored in strategy meetings, and you miss actually building things.

Fair enough.

There’s another reason which I find fascinating these days.

You actually still like being a manager (and everything that comes with it). You like helping engineers, being involved and in the details. You like contributing to the roadmap, and solving team problems.

You just don’t like doing all of these things at the same time.

Too much or too many things?

There’s some old research that I think explains this well. Robert Karasek published a paper in 1979 looking at two things: how demanding someone’s job is and how much control they have over how that work gets done.

What he found is that high expectations weren’t really the problem, but high expectations without much control were.

You can be completely fine with having a lot of responsibility but hate having no control over when any of it happens.

Gallup’s research found that 97% of managers also do individual contributor work, with a median of 40% of their time. Managers who were below that 40% mark tended to maintain higher engagement regardless of how many people reported to them.

So maybe having 10 reports instead of 7 isn’t actually what can tip you over the edge. Maybe it’s managing 10 people while also being half an IC, and jumping between all the projects your team is working on.

Gallup’s manager burnout research found managers are 67% more likely to strongly agree they experience a lot of interruptions at work.

Based on all this, I wouldn’t interpret “I want to become an IC again” as “I don’t want responsibility anymore”. You might want exactly the same amount of responsibility, but with just fewer things happening at once.

But, is it actually a demotion?

I think most career ladders and frameworks nowadays map pretty well that an EM has an equivalent IC role, typically somewhere around Staff Engineer.

So technically, going back to being an IC is not really a demotion.

And although many very successful people I know have done it, which turned out to be great for them, I do think that for many people it feels like a demotion

I’ve heard people tell me that going from Staff Engineer to Engineering Manager feels like progression, but going from Engineering Manager to Staff Engineer somehow feels like going backwards.

Atlassian even calls it a “voluntary demotion” (if they still stand behind this).

In my opinion Staff Engineer and Engineering Manager are genuinely parallel tracks, moving between them shouldn’t really mean moving up or down.

I think the important question to answer though is whether becoming an IC will actually solve the problem you have. The grass is not always greened on the other side.

There’s a pretty simple way to test that before making that decision that I like to recommend:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

There’s a lot of talk about AI creating more code, bigger PRs and more work to review them.

But I don’t think the volume explains why reviewing code this period feels so exhausting.

Senior engineers have spent years learning how to read code written by other people.

They could tell where someone wasn’t sure about something. Naming of a variable would be a bit weird, a leftover comment explaining something that probably doesn’t need explaining, or just generally code that was a little bit off.

AI-generated code is different.

Naomi Lurie at Faros AI makes this point: AI-generated code can look tidy, idiomatic and completely confident even when it’s wrong.

So one of the signals reviewers used to get has disappeared.

Do you understand the code?

In the past, when someone would open up a PR, you’d review the code, but also their judgement. You’d ask question about the decisions they made, hear what they had to say, maybe challenge it, and over time you’d start trusting their judgement more or less.

That’s how a lot of learning and trust-building used to happen.

Now, when AI writes so much of the code, and the “author” just reviews it, how exactly is the author’s judgement assessed?

I feel like this is part of why code reviews feel more exhausting today.

Reviewers are a lot more cautious and are also trying to understand if the author understands that code well enough.

That’s a new thing reviewers are verifying nowadays.

Using AI isn’t the problem

You surely don’t want to start policing whether engineers use AI or not.

I do think though, that you need to be sure that they still understand what they ship.

Anthropic did a randomized study on how AI assistance affects skill formation with engineers learning an unfamiliar Python library. Surprise surprise, the AI-assisted group scored 17 percentage points lower on comprehension.

But what I found interesting is how people used AI.

People who delegated most of the work or repeatedly pasted errors back into the assistant did badly. People who asked conceptual questions, asked for explanations or deliberately worked through generated code did much better.

I think we should care a lot about code understanding.

Do you understand what you’re putting into production?

I’ve written before about growing high-potential juniors, and I think this is increasingly becoming part of that job.

Three questions to ask

There are some good practices emerging.

Simon Willison argues that dropping giant untested AI-generated PRs on colleagues is basically a dereliction of duty. Addy Osmani suggests a PR contract where authors should explain intent, proof, risk and how AI was used.

I like both to be honest.

But they still rely on the engineer telling you that they understand changes they make.

So I think I’d add one more thing.

Spend a few minutes checking whether the person who opened the PR can actually explain it.

You can use three questions for this:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

A manager I coach told me in our last call something I’ve now heard a few times in different forms.

There is an interpersonal conflict between two people in my team, but I hear completely different stories from each side. What should I do?

Doesn’t sound pretty, but at the same time, it’s completely normal.

You speak to one person and their version of what happened sounds completely reasonable. Then you speak to the other person and their version also sounds completely reasonable… but… they’re two very different stories.

The situation looked a bit like this:

One of them had been working on an architecture proposal for a change he wanted to propose for a feature his was working on. He presented it to the team and got some feedback from the other engineer. So, he made some changes, shared it again, and got more feedback. Repeated the cycle until he got some more feedback.

Eventually the other engineer basically took over the work and rewrote it herself.

When my friend spoke to the first engineer, he was really frustrated.

He felt like this kept happening. Every time he owned something, the other engineer would find something wrong with it, keep pushing for changes and eventually take over. She doesn’t trust me with anything and always finds things that I do wrong.

Then my friend spoke to the other engineer.

According to her, the design had some pretty important problems. She’d pointed them out, but the changes would never really address them. They went back and forth a few times and eventually she stepped in because they needed to move forward and she didn’t think what they were going for was good enough.

Her view was: I tried everything, what else was I supposed to do?

The problem is, that my friend was not around. He didn’t know exactly what was said or how it was said… So, what is he supposed to do?

Perspectives

Both people are probably telling you the truth. Not necessarily the truth, but their version of it, through their own lens, and following their own thoughts.

The first person sees a pattern of being constantly found wrong. The second sees a pattern of having to catch problems.

Both of those experiences can exist at the same time.

In order to progress with resolving the conflict, it’s important to understand that.

Don’t become the judge

Your first instinct might be to go find out who’s right and who’s wrong. Maybe there’s a performance concern, either with communication on how feedback is shared, or with technical/analytical skills on populating good architecture proposals.

Obviously you should understand what happened, but I wouldn’t approach it as an investigation into who is right.

I’d instead try to separate what actually happened from what each person thinks it means.

“He changed my architecture proposal.”

That’s something you can verify that actually happened.

“He changed my architecture proposal because he doesn’t trust me.”

That’s an interpretation.

“The architecture proposal needed changing because it wasn’t good enough.”

Also an interpretation.

That doesn’t mean those interpretations aren’t important btw. They are, and they tell you a lot about how each person is experiencing the relationship, but they’re different from the facts.

Look for the pattern

You want to find out what they disagree about, but more importantly you want to find out where they disagree.

Is it on PRs? When there’s an ambiguous big project that needs to get started? When someone is proposing an idea without offering useful context? When there’s delivery pressure?

You might start noticing that the same type of situation creates the conflict again and again.

I’ve written before about diagnosing difficult behaviour, code review friction and what happens when two senior engineers disagree on everything.

Sometimes something that looks very interpersonal is rooted in something completely different.

Maybe it’s unclear ownership, different expectations, no agreed way of making decisions, or a million other things.

Or maybe one person is just behaving badly in this situation.

What you do next so you can actually find out which one of all of those it is?

Here’s how I’d approach that situation and what I’d put in place afterwards:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Most Engineering Managers used to be software engineers at one stage in their career. In most cases, these are technical people who have a passion about people.

Coding used to be part of their day-to-day, but it’s not anymore.

Coding used to require proper focus time. It doesn’t anymore. I can spin up a claude agents to do some research while I am in meetings, review in between meetings what it came up with, give it a steer and have it go implement whatever I want.

I can do that to help with a feature my team is working on this sprint because an engineer is on holidays. Or I can look at why our deployments are taking 40 minutes and failing regularly.

I think one of these two options is a pretty bad use of time.

Many people ask me (or on the internet in general) if Engineering Managers should be writing code.

This is the wrong question though.

Should managers code?

This argument has been going on forever. There’s an article from Coursera from 2016 (lol): “Should engineering managers write code? Wrong question.”

“Coding” can mean so many different things and these days there’s certainly more pressure to do more of it than before.

LeadDev’s Engineering Leadership Report 2026 found 37% of engineering leaders are doing more hands-on technical work than before.

I really like the point that makes here:

“All managers should be in the code, but not all managers should be writing code.”

The answer to the question is certainly not “managers shouldn’t code”.

But I think it’s important to be very intentional about why you’re in the code in the first place.

Coding to ship

This is one that many love to do but it’s not a good use of time.

There’s a certain type of satisfaction that you get when you ship a feature and it lands in the hands of customers. The thing is, that this shouldn’t be your priority anymore.

It’s not that you don’t have the ability to do that. It’s more that your other responsibilities will get in your way.

Charity Majors makes this point in The Engineer/Manager Pendulum: both engineering and people management require focused attention.

As a manager, your week will get interrupted. I literally can’t remember the last time I was able to plan out my week on Monday and everything go to plan that week.

You coding is also taking work away from engineers. The particular task that you’re picking up might have been an opportunity for someone on the team to learn something you already know.

Also, things can get quite messy if you get on the critical path.. because, you might create a PR that needs to ship, but you also have interviews, 1:1s, planning, a random urgent request from your manager or your CTO, an escalation and whatever else happened that week. Who’s going to address the comments on your PR and drive it through?

Another thing is.. technical decisions can naturally start moving towards you. Even if you don’t intend that to happen, your opinion isn’t quite the same as another engineer’s opinion anymore.

Many companies nowadays are seeking for the player-coach. The engineer/tech lead who’s also managing the people in their team. Doing both at the same time at a high level I think is incredibly hard.

Coding to understand

Now that’s an interesting area. Understanding is very powerful to have as a manager.

You want to know how things are built. Where are the parts that need improving, and why. What’s slowing the team down by feeling some of that pain.

Camille Fournier talks about the importance of being able to ask good technical questions in this YC interview. To be able to do that you need to understand well your systems.

You don’t necessarily need to be shipping features. You can pick up small things like looking at the deployment pipeline, debugging a flaky test, pairing with someone, reading code through a service you don’t properly understand.

I wrote before about the five engineering skills worth evolving, and a lot of it is basically this. Stay close enough to understand.

AI might have changed all this a bit

The problem so far has been that meaningful coding didn’t fit particularly well between meetings. That’s changing though.

Will Larson wrote about this last year. After years of barely coding as a manager, he started doing it again with agentic tools.

He still follows some rules that are worth keeping in mind.

• Don’t take time-sensitive work

• Don’t put yourself on the critical path

• Work on things that your team struggles to prioritise but that are obviously useful

These feel much more like coding to understand than becoming another engineer in the team.

But AI creates another problem.

It makes it much easier to be useful... and much easier to feel useful when you’re actually getting in the way.

So I think Engineering Managers need a simple way of deciding whether they should work on something or leave it for one of the engineers.

I use three questions for this:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

A manager I’ve been talking to was responsible for a project. That project had an owner as the project lead, and my friend spent two months getting basically the same update every time he asked for one:

“Still working on it.”

Sometimes it was slightly more specific than that, but the thing is - he had no way to track how it was going.

The project was complex and it was obvious the lead was busy with it.

One day, my friend checked out the latest changes of the new repo, and he noticed that it was getting contributions from a few other engineers. What a surprise! Up until that moment, he thought it was only being worked on by the project lead.

Vagueness

There’s a ton of really useful advice about status updates out there.

How to ask good questions to get good updates, have them be async, make it safe for people to raise when they’re stuck…

All of that is great!

But I think there’s a difference between someone who struggles to explain clearly what they’re doing, and someone giving you the exact same update for eight weeks.

“Still working on the migration” tells me nothing. And can be true regardless of if the project is:

• on track

• at risk

• delayed

• barely started

The update works in all these scenarios.

Now imagine a beautiful world where instead of hearing that, you hear something like:

We’re on step three out of seven. Step four needs a decision by Thursday from X to stay on track.

From experience, I have seen that when projects are struggling, status reports tend to make things look better than they actually are. It’s not that people are lying.. Sometimes, they really believe they’re almost done... every week, for six weeks.

An update that hasn’t changed for two months is probably one of them.

The same words can mean very different things

When I hear “still working on it”, I think it means one of three things.

The work is blocked.

That happens.. Usually though, there should be something more concrete to share. A failed approach, a technical decision gone bad... something.

The work isn’t being done.

Especially if that’s on a project with people from different teams that you don’t have as much visibility on. Maybe their priorities changed, or they have not been able to create time for it.

It’s in progress but the lead has delegated work to others and doesn’t know what’s going on.

This is the interesting one. The lead might create a POC, or start the implementation, and because or “reasons” they decide to hand over parts of it to other people.

The handoff

There’s an old HBR article called Management Time: Who’s Got the Monkey?.

The original article talks about work moving upwards.. Someone brings their manager a problem and somehow the manager walks away owning it.

This obviously happens downwards too.

A lead is working on a thing, asks someone else for help and suddenly that person owns that piece now.

Sometimes we create the problem ourselves. People are less likely to report bad news when they think the delay is their fault. So if people get punished every time they’re specific about something going wrong... eventually they’ll stop being specific.

How can we get high quality updates on projects consistently?

That’s the paid part of this issue 👇👇👇

Four things I’d check and the conversation I’d have.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

An engineer comes to your architecture forum with five approaches to the problem they’re trying to solve. They describe each one’s pros and cons and then open up to the group: “What do you think? Which one should we take?”

None being obviously bad. They are all… fine.

So people just sit there, not contributing much, not being able to decide which one to pick based on the information provided.

AI has made producing options incredibly cheap, but it hasn’t made choosing between those options much easier.

Pick one

Faros surveyed more than 10,000 developers across 1,255 teams and found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. Impressive.

That’s a lot more output. But the the same study didn’t find a significant relationship between AI adoption and improvement at the company level.

Meaning, we’re producing more stuff... but that doesn’t automatically mean we’re producing more value.

Someone still has to decide what we should actually build.

Producing an option can now take minutes. Choosing the right option still requires context, experience, technical understanding and, for lack of a better word, taste.

AI hasn’t really made that part cheaper (yet).

Five right-ish answers

AI more often than not is not giving you obviously wrong answers. It gives you a lot of answers that look pretty reasonable.

Knowing when something’s “almost right, but not quite” is quite hard.

We’ve spent years associating well-written technical proposals employing good thinking and rationale. Usually if somebody had written a clear, detailed design document, they had spent quite a lot of time thinking about it.

This is no longer the case today.

A beautifully written technical proposal might have taken somebody 10 minutes, which means we need to get much better at judging it.

Joel Spolsky wrote in 2000 that it’s harder to read code than to write it. That is pretty obvious today with so much AI-generated code having to get reviewed.

Twenty-five years later, DORA’s 2025 report had 90% of respondents using AI at work and more than 80% said it made them more productive.

But 30% also said they have little or no trust in the code AI generates.

So we’ve massively accelerated the producing part of engineering... while the expensive part, understanding whether something is actually good, is still very human.

We used to learn this accidentally

I don’t remember anyone teaching me engineering judgment.

You just accumulated it over time by building stuff. By getting stuck in, failing over and over again, reading documentation, until it suddenly worked. At which point you’d go back to refactor all the shitty code you had written to make it work and bring it to a state that it can be reviewed by others.

In that process you had to understand and think about so many parts of the system. And as a result, form opinions about them. “I can understand this part easily because it’s written in that way.” “That part caused me headaches, and I spent hours trying to understand it.”

And slowly you started recognising patterns.

Collins, Brown and Holum talked about why apprenticeship works decades ago: the important bit is making the thinking behind the work visible.

Software engineering used to involve producing the work yourself, and producing it gave you the reps.

AI is starting to remove some of those reps.

This worries me particularly with junior engineers.

Stanford’s Digital Economy Lab found that early-career workers aged 22 to 25 in the most AI-exposed occupations have already seen a relative decline in employment.

Charity Majors made a similar point when she wrote that “by not hiring and training up junior engineers, we are cannibalizing our own future.”

I’d add one more.

Even the juniors we do hire can now skip quite a lot of the messy producing work that used to build judgment.

Maybe that’s fine, but if we remove those reps, I think we need to replace them with different ones. Because judgment today matters more than in the past.

So I’ve started thinking about technical taste less as something senior engineers magically acquire, and more as something we need to deliberately train.

There are five fairly simple things I’d change to make that happen:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

A software engineer I mentor got recently offered the Tech Lead role for his team. He’s been in that team for a couple of years and the previous Tech Lead decided to leave.

He’s working in a team that owns a legacy service that nobody really wants to touch. Proposals he’s put forward, all kept getting rejected.

When he got the offer he asked me: if I become TL, will I finally have enough authority to actually modernise this service? Being the team’s Tech Lead surely will mean that people will have to listen to what I say.

I was not convinced.

Coasting

A team that’s coasting is hard to change.

People just do what they’re told within the boundaries of a comfort zone they have set for themselves and are used to.

Becoming tech lead for such a team will probably also come with responsibilities around setting technical direction, pushing for technical changes, and suggesting who’s best placed to work on what.

You can present a novel project, assign an owner & contributors to it, and expect it’ll get done. That’s only fair to expect. You can’t really expect that people will care about the project though if it’s within a coasting team in an area that they don’t feel comfortable about.

Will Larson describes a Tech Lead’s authority as proxied, which is an interesting way to look at it. You’re essentially borrowing authority from your manager, but you still have to remain trusted and aligned with the team and the manager.

The usual advice is to aim to “influence without authority”. Influence works really well when people already want to get to the same end-goal you have in mind.

The business case

There’s a pattern with engineers working on systems with lots of technical debt. They try to persuade everyone that X service needs to be completely refactored because it’s bad.

Any sensible manager then asks questions like:

• Why? What’t the problem with it?

• How long will the refactor take?

• What happens if we do nothing about it?

And the answers to these questions are… underwhelming.

Don’t justify spending that much time on it.

You need to be able to create a compelling business case if you’re pushing so hard for such a big time investment.

And that’s only the first problem.

Even if you get the business to agree that something needs to change, you still need to decide what to actually change. A full rewrite of a service is very rarely the option you should advocate for.

You also need the team to want to do it btw. That’s the bit I think gets underestimated. On a team that has been coasting around the same legacy service for years, getting leadership to agree you getting time to work on something might actually be easier than getting people excited about doing it.

So, there are really three problems to solve:

• Prove where the technical debt is hurting the business

• Find the smallest modernisation work that can prove the investment is worth it

• Find the engineers who will want to work on it

Below is what I’d do if I took a Tech Lead role for a team and situation like that 👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Nowadays, asking engineers questions about how things work can be perceived as being lazy. Anyone can point their claude to the collection of codebases the team owns and ask their question.

What happens though when non-technical people decide that some answers they get back shouldn’t be like that?

They can either ask an engineer to make changes to this part, or… ask claude to make these changes and then get an engineer to review them. The latter feels much more efficient.

I was talking to a friend of mine recently who’s PM had recently gone on this journey, of trying to work on their codebase. They started with small changes, got engineers to review them, they got merged & deployed, and landed to customers’ hands. One day, at a strategy meeting, the CEO had a crazy idea which excited the Product Manager so much so that he spent his weekend trying to vibe code it.

He generated tens of thousands of lines of code and got something that seemingly worked! That was enough to convince him that his team would be able to get it in a good place and ship it quite quickly, so he went back to the CEO and demo’ed his POC.

Everyone very excited agreed to get the team to “productionise” it and then ship it to customers. After all, the hard part of proving it could work was done already.

When the PM brought it to the engineering team, the Tech Lead took agreed to look into the code to see what was done to implement that feature. He thought that it would take a few hours to untangle what claude had done.

Pretty quickly he saw that he’d reimplemented several of their core functions, some of them subtly wrong (breaking other parts of the system), and connected the whole thing to the demo he was showing people.

After a couple of days he basically said: “we can’t implement this, and here’s why…”

That was not an emotional response. It was going to take far more time trying to “productionise” this thing, compared to taking a step back, thinking from first principles and architecting a design that could actually work.

The PM was not happy. So he escalated this to the VP of Engineering.

The VP was far removed from the day-to-day (and is not a particularly good one) so he just asked the team to find a way to get it done, since now this has started being promised to customers.

The bad code is probably the least interesting part

I bet this is not the first time you hear a story like that. And the natural follow up conversation becomes about how crap is AI-generated code.

I’m not sure that’s the interesting conversation to have here. We already know it gets things wrong.

When a model has a choice between a secure and insecure implementation, it chooses the insecure one about 45% of the time. Models are getting much better at producing code that looks right. Not necessarily code that is right.

Even if the code that PM produced with claude was right, you’d still have a team being handed a massive system they’d never seen before and having to maintain it from now on.

It’s not about how you contain your PM

Reading this story, you probably are feeling a certain type of way against that PM.

Why did he do that? Why didn’t he consult with the team first? How could he possibly think that it’s that easy to build such a complex piece? etc etc etc.

The reality is, that it’s easy to get carried away after you see you can build things.

Simon Willison, has described the meaning of vibe coding very sensibly.

Vibe coding means generating code without reviewing it.

If you’re reading the output, understanding it and testing it, you’re basically doing software development with AI.

Collins made vibe coding its word of the year for 2025.

Lenny’s Newsletter has articles about getting paid to vibe code as a full-time job, including people without traditional coding backgrounds building customer-facing products.

Your CEO has heard about vibe coding. Your PM has Claude or Cursor or whatever. And they can now build something that looks surprisingly close to working software. That was not the case a couple of years ago.

Retool surveyed 307 CTOs, CIOs and CISOs and found 93% were at least somewhat worried about vibe-coded tools running in production. Only 4% had governance covering AI-generated code regardless of who wrote it. Now, they sell governance tooling, so obviously take that into account.

19% had already confirmed a production incident caused by an AI-built internal tool in the previous year. One person they surveyed said:

“When anyone can ship a tool in an afternoon, nobody signs up to maintain it.”

And I think that’s the bit we need to pay attention to.

What you’re actually getting

When you have an enthusiastic PM (or any non-technical person) vibe coding ideas and asking you to make them ready to ship, I think it’s important to name what you’re actually being asked to do.

You’re not fixing some bad code.

You’re adopting a system where no context has been built on it and nobody will be able to fully own it.

“Vibe slop is the symptom. Context debt is the disease.” ~Matt Burns in The New Stack

Normally, even when you’re handed a terrible legacy service, somebody understood it at some point. There was an engineer who made the decisions.

With vibe-coded software, that person never existed. The person generating it wasn’t even a person 🤖. AI obviously doesn’t understand your system in the way an engineer does.

So when someone says:

“Can the team spend a sprint cleaning this up?”

...that’s not really what needs doing.

You’d need to understand tens of thousands of lines of code and work backwards to figure out what it was supposed to do. And maybe some of that intent was never properly decided in the first place.

Will Larson has said this which I think about quite a lot when someone asks someone else to “finish off” some existing work: partial work has no value. The expensive part is often finishing the thing. Getting 80% there, especially now with AI is the easy part.

Four things to do

A similar thing has happened to one of my teams and there are four things I did which I would recommend considering if you’re wondering how to tackle it. Just “push back” is obviously not one of them.

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Where is your engineering team on the AI adoption ladder? (sponsored)

Find your stage, spot the one bottleneck holding you back, and see what to fix next.

Download the free whitepaper

Thanks to re:cinq for sponsoring this newsletter!

A few years ago, one of my reports told me he wanted to be a manager.

At that point he was the most senior person in the team, had been mentoring two junior engineers, and people seemed to be going to him when they were stuck.

The series of questions I asked next involved a lot of “Why” and “What”

• Why do you want to be a manager?

• What is it that gravitates you to that role?

• Why now?

I have generally given the advice to most engineers I work with that spending a couple of years as a manager is a great thing for everyone to do. I think it is a great role to undertake and offers useful skills (and you can always decide to get back to IC work later).

That time though, I was not convinced.

A lot of what I heard was about “him”

• “AI is taking software engineer jobs so I have to find something different to do”

• “I don’t want to be writing code all my life”

• “I like being in meetings”

• “Being an engineer is stressful, I want a more relaxed role”

Not a lot, or not a thing actually about “others” which is at the very core and centre of the role: help making others grow.

There’s a lot of crap you have to deal with as a manager. If supporting people grow, which is not easy, is not what motivates and energises you then altogether the role will feel pretty miserable.

“I want to become an Engineering Manager”

I think there are three different reasons why someone says this.

The first one is that they find the role interesting and exciting. They’ve noticed they enjoy helping others succeed, mentoring, coaching, or even help resolve disagreements. At some point they see they can have more impact through other people than their IC work.

The second one is more of a push than a pull. They just don’t enjoy their current job anymore… maybe they’re not as intellectually stimulated and feel bored. But many people would be scared to say this to their manager. It’s easy for it to sound like a lack of ambition and reflect badly in performance reviews.

The third one is become more and more common in the past 18 months. Engineering has changed, and is still changing with AI which not everyone loves. A lot of engineers don’t enjoy the craft of engineering as much as they did in the past. They used to spend days building new things, and now they

• review AI-generated code (a lot of it!!!)

• prompting AI

• review plans that AI gives them

• suss out BS that AI tells them

and generally supervise work that AI did - either on their laptop, or coming from a colleague.

Being an engineer today is certainly not like how it used to be 5 years ago, and I think some people feel some grief about that.. which is a completely legitimate way to feel about it. But not a strong reason why you should become a manager.

Management is hard and tiring

This is the bit that often engineers don’t see. If someone’s tired of solving hard engineering problems, people problems are not easier.

LeadDev surveyed 617 engineering leaders in 2025, and I wrote about the full findings from that report when it came out. 22% of them said they’re at critical levels of burnout and only 21% were in the healthy band. 65% had taken on more scope over the previous year, 40% had more direct reports, and 38% were working longer hours than they had 12 months earlier.

When they were asked if they wanted to stay in a leadership role the main considerations that were mentioned were:

• salary

• fear of losing technical skills

• actually enjoying the management work

Only the last one was really about enjoying the job.. and many Engineering Managers do eventually think about becoming an IC again.

Nearly half (47%) of managers of engineers in that survey had at least considered moving back to an individual contributor role in the previous 12 months.

I once hired an engineer who had become a CTO and quit after six months to come back and write code on my team. He’d got the title many of us dream of, but he realised quickly that this role was really not what gave him joy and fulfilment.

Engineering skills ≠ Management skills

There might be an engineer in your team that you feel would be a great manager.

Sponsoring this engineer to become a manager probably feels like the natural thing to do, or else it might be seen as blocking their growth.

Gallup studied 27 million employees and found that 1 in 10 people are naturally good at managing. Google’s Project Oxygen ranked the eight behaviours of its highest-rated managers and put “has key technical skills” last.

We know by now that skills needed to be a great engineer differ greatly from skills needed to be a great manager. They are to very different roles. In fact, being a great engineer tells me very little about whether this person would be a good manager, or even whether they’ll enjoy being one.

I am not suggesting here that we should be rejecting great engineers from becoming managers. My point is that we should be deeply questioning the reasons why they’re interested to change paths to form an informed view.

Here are the three questions I use to work that out, and what I say when my honest answer is “no”:

The motive check

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Where AI Adoption Stalls (sponsored)

Most teams experience the same pattern: developers become more productive, yet organisation-wide delivery barely changes.

The problem isn’t the AI tools - it’s the system around them.

This paper introduces the AI Adoption Ladder, explaining why gains flatten, the nine stages of AI coding adoption, and the bottleneck that prevents teams from reaching the next level. If you’re leading engineering, this framework will help you understand where your organisation is today and what comes next.

Download the free whitepaper

Thanks to re:cinq for sponsoring this newsletter!

Every engineering leader seems to be talking about becoming AI native.

The problem is that nobody agrees on what that actually means.

For some companies, it means buying Cursor licenses.

For others, it’s replacing engineers with agents.

For others, it’s simply encouraging people to use ChatGPT more often.

The phrase gets thrown around constantly, but very few people explain what actually changes once a company decides to become “AI native”.

A few weeks ago, Brian Kramer from Augment Code reached out after reading this newsletter. Instead of pitching their product, he suggested I speak with their VP of Engineering, Vinay Perneti, about the journey they’ve been documenting publicly.

That interested me because engineering managers are trying to answer much harder questions:

• How do you stop AI-generated code becoming a black box?

• What skills actually matter now?

• How does hiring change?

• What does an engineering organisation look like when agents are involved every day?

So I sent Vinay eight questions.

Here are the answers that stood out.

“AI-native” isn’t a destination

The first thing that surprised me was how Vinay defines AI native.

He doesn’t.

Or rather, he doesn’t think it can be defined as a fixed destination.

Instead, he sees it as an organisation that continually redesigns how work gets done as AI capabilities evolve.

Many companies are treating AI adoption like previous tooling migrations.

“We’ve bought the tool.”

“Everyone has access.”

“Job done.”

That’s not transformation.

That’s procurement.

The interesting organisations aren’t using AI to write code faster.

They’re reassessing their whole SDLC for the modern era.

Writing code is becoming a smaller part of the job

One answer stuck with me more than any other.

Vinay said the hardest part of becoming AI native isn’t the tooling.

It’s accepting that the role of a software engineer is changing.

For years, our identity has been tied to writing code.

Now the highest leverage increasingly comes from:

• defining problems

• reviewing intent

• steering agents

• making architectural decisions

• deciding what should be built

The implementation itself is becoming easier.

This doesn’t mean engineers disappear.

Ironically, as code becomes cheaper to produce, good engineering judgement becomes more valuable.

Giving everyone an AI coding tool isn’t enough

This was probably my favourite answer.

Vinay said the biggest mistake organisations make is believing the transformation ends once every engineer has an AI coding assistant.

I completely agree.

Software development has never been an individual sport.

Making one engineer twice as fast doesn’t automatically make the organisation twice as productive.

If product decisions still take weeks...

If priorities constantly change...

If pull requests sit around waiting for review...

If nobody understands why decisions were made...

AI simply helps you reach those bottlenecks faster.

Engineering managers should probably spend more time asking:

“What parts of our delivery process no longer make sense and how can we leverage AI in them?”

Shared understanding matters more than ever

84% of engineering leaders worry about losing shared understanding of their codebase as AI generates more code.

That’s a concern many of us have.

We’ve spent years encouraging engineers to read code, understand systems and build context.

If AI writes significantly more of that code, how do you stop knowledge becoming concentrated inside prompts and chat histories?

Vinay’s answer was interesting.

His engineers stay heavily involved in specification reviews before implementation starts.

Then AI helps explain pull requests and the intent behind them during review.

In other words, they don’t just review code.

They review why the code exists.

I suspect we’ll see much more of this over the next couple of years.

Hiring is already changing

I also asked what makes a great engineer today that wasn’t as important two years ago.

The answer wasn’t “prompt engineering”.

It was learning velocity.

The strongest candidates aren’t necessarily the ones who can solve the hardest algorithm question.

They’re the ones who rapidly adapt, experiment and figure out new ways of working.

That aligns with what I’m seeing.

Technical ability still matters.

But curiosity is becoming a competitive advantage.

So... will software engineers still exist?

I had to ask.

Vinay doesn’t believe software engineers disappear.

Neither do I.

But I do think the role becomes much broader.

You’ll still need engineers.

You’ll just expect them to think more about product, architecture, systems, business trade-offs and orchestration than writing every single line themselves.

Software engineering becomes one capability rather than the entire job.

That feels like an important distinction.

Final thoughts

Whether you agree with every prediction or not, one thing feels increasingly obvious.

AI isn’t simply changing how engineers write code.

It’s changing what engineering teams optimise for.

The organisations that benefit most will be the ones willing to rethink how software gets built end to end.

The full Q&A 👇 👇 👇

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Where is your engineering team on the AI adoption ladder? (sponsored)

Find your stage, spot the one bottleneck holding you back, and see what to fix next.

Download the free whitepaper

Thanks to re:cinq for sponsoring this newsletter!

I became an EM almost a decade ago and since then I’ve spent time managing teams at startups, as well as more established unicorn companies in London.

Back then, managing a team of 8 engineers really meant managing one team.

Today, it feels more like managing 4 teams.

I don’t think that’s because engineering has become more complicated.

I think it’s because the bottleneck moved.

It moved from engineering... to product.

When I started, being an EM would typically mean that you’d get a team of 6-8 engineers, a Product Manager, maybe a designer, and you’d all work together. In the good old days, you’d also get a Delivery Manager who made sure you’re “agile” (and in most cases would also facilitate all your meetings).

The roles were clear. Everyone knew what they were responsible for. Very simply put:

• the PM was responsible for the WHAT: what we’re working on

• the designer was responsible for the look and feel of that

• the engineers were responsible for figuring out the HOW and building the thing

The role of the EM was about making sure engineers were having career growth conversations, had clear goals on how to progress, and were well positioned to achieve those goals.

The EM was also pretty much always held accountable for the technical decisions that the team made.

Experienced EMs who wanted to progress their own career were equally involved in bringing positive organisational change (improve how teams worked together, drive an initiative that the CTO was really keen on but couldn’t find the time to lead, etc).

Teams had a fairly simple operating model.

Your PM would tell you what they wanted in a semi-prioritised list and ask you how long each piece would take so you can make an informed prioritisation call together.

You’d then do a bunch of research and spikes to surface unknowns, run something like a t-shirt sizing exercise with the engineers to get a rough sense of timelines, and end up with a prioritised roadmap.

From that point onward, the team would be ready to do something like a quarterly kick-off, commit to projects, assign project leads, and make sure everyone had context on what we’d achieve in the next three months.

As an EM you’d stay very close to the team.

You’d coach and mentor engineers on the day-to-day, make sure important decisions were documented, help resolve conflicts, keep delivery moving, and make sure people were growing.

And because the team usually only had one or two meaningful projects happening at any given time, it was fairly easy to stay in the details.

You knew what was going on.

You had enough context to coach people effectively.

That’s not the case anymore.

A team of 8 engineers working on one or two projects just doesn’t feel like the norm anymore.

Instead, it increasingly looks like multiple groups of two engineers working on different initiatives in parallel.

AI has massively increased what a couple of engineers can deliver.

Features get built faster.

Iterations happen faster.

Experiments are cheaper.

The engineering bottleneck has reduced dramatically.

But product thinking hasn’t sped up at the same rate.

Product Managers still need to discover opportunities, validate ideas, prioritise work, align stakeholders, and define what success looks like.

That work still takes time.

So we’ve gone from engineering being the bottleneck (hence the 8-to-1 ratio of engineers to PMs)...

to product thinking becoming the bottleneck.

The interesting consequence is that a team of 8 engineers doesn’t really behave like one team anymore.

It behaves more like four.

Instead of one roadmap, you now have four workstreams.

Instead of one project lead, you have four.

Instead of one set of stakeholders, you have four conversations happening in parallel.

Instead of keeping track of one technical context, you’re switching between four.

That’s what has changed the Engineering Manager role more than anything else, at least in my experience.

PMs are stretched just as much as EMs are.

And maybe our team structures haven’t caught up yet.

Maybe the old-school structure isn’t quite right anymore.

Maybe a group of 8 engineers doesn’t need one PM.

Maybe it needs four.

But that also creates a new problem.

An EM suddenly isn’t supporting one team anymore.

They’re supporting four.

Something has to give.

Is it the “people” side of the role?

Or is it the “engineering” side?

In my opinion, it really shouldn’t be the people.

Career growth, coaching, feedback, hiring, difficult conversations... those things become more important as organisations move faster, not less.

So perhaps someone else needs to own more of the engineering side.

A Staff Engineer might be the answer.

Maybe the model evolves from:

• Engineering Manager

• Product Manager

• Designer

• 8 Engineers

to something like:

• Engineering Manager

• Staff Engineer

• 4 Product Managers

• 2-3 Designers

• 8 Engineers

I’m not saying this is the answer.

I’m not even convinced this is what every team should look like.

But I do think we’re starting to optimise around a different constraint than we were ten years ago.

For a long time, engineering capacity was the limiting factor.

Today, I think product capacity increasingly is.

And if that’s true, I suspect the Engineering Manager role will continue evolving over the next few years.

I am not sure.

We’re all figuring this out together as we go, and these are simply my thoughts today.

Tomorrow they might differ.

If you have views or observations to contribute to the topic, please reach out.

I always enjoy learning from people who are seeing different things in their own organisations.

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Where AI Adoption Stalls (sponsored)

Most teams experience the same pattern: developers become more productive, yet organisation-wide delivery barely changes.

The problem isn’t the AI tools - it’s the system around them.

This paper introduces the AI Adoption Ladder, explaining why gains flatten, the nine stages of AI coding adoption, and the bottleneck that prevents teams from reaching the next level. If you’re leading engineering, this framework will help you understand where your organisation is today and what comes next.

Download the free whitepaper

Thanks to re:cinq for sponsoring this newsletter!

One of the engineers I mentor, a senior developer, told me he no longer enjoyed the job.

Every feature followed the same pattern. He’d ask the AI to write it. It would miss an edge case. He’d point it out, the AI would fix it but break something else, and they’d go back and forth until it finally worked.

His frustration wasn’t that the AI made mistakes. It was that the job had changed. Instead of solving problems, he felt like he was reviewing someone else’s work all day.

He told me that by the end of it, he’d often spent just as long as if he’d written the feature himself, except he understood it less.

I’ve heard versions of this from several engineers I’ve coached over the past year, and I’ve felt it myself. Sometimes the back-and-forth with an AI takes longer than just writing the code in the first place.

This isn’t a “use AI less” post

When I talk about this with engineers I mentor, I usually hear one of two reactions.

The first is frustration. One Staff engineer I’ve coached for years told me he’s seriously thinking about leaving software engineering. Spending all day reviewing AI-generated code isn’t the job he signed up for, and he doesn’t see that changing.

I understand that feeling. But leaving isn’t really a good solution for most.

The second reaction is that you should just get used to it. If AI writes the code, then reviewing it is the new job.

That works for some people. One engineer I mentor genuinely enjoys working that way. But for others, it takes away the part of the job they love. Telling them to “just enjoy reviewing” doesn’t solve that.

One engineer found a better approach.

Instead of asking AI to write the first version, she writes the first draft herself whenever a problem is genuinely complex. Then she asks the AI to review it, suggest improvements, and look for edge cases.

She still uses AI for repetitive work like CRUD endpoints, CI/CD configuration, and unit tests. But when the real thinking starts, she does that part first.

She told me the fun came back. She understood the code better, and it usually didn’t take any longer than the endless cycle of prompting, fixing, and prompting again.

Going first

I tell senior engineers I coach to do the same thing in design reviews: think through the problem yourself before you look at what AI is suggesting.

A few weeks ago I even suggested to an engineer to write an ADR completely by hand - and comparing it to AI’s output, his was much better.

If you see AI’s suggestion first, it’s hard to think independently. You naturally start looking at the problem through that perspective, including assumptions and blind spots.

When you think through it yourself first, the differences become valuable. You can compare your notes to AI’s and see what you missed, what it missed, and why one approach is better than the other.

That’s where the learning happens.

There’s also a lot of research showing that trying to generate an answer yourself helps you learn more than simply reading one.

The evidence

In 1978, psychologists compared two groups of people. One group simply read information. The other had to generate part of the answer themselves. The people who generated the answer remembered it much better.

This is known as the generation effect, and many later studies have found the same result.

When you have to think through a problem yourself, it feels harder. But that extra effort helps you understand and remember the solution for longer.

The opposite is also true. Reading someone else’s answer feels fast and easy, but you don’t learn as much from it.

That’s why the endless prompt-and-fix cycle with AI can feel productive while leaving you with a weaker understanding of the code.

There is an important exception, though.

This only works if you already know enough to attempt the problem. If you’re completely new to a topic, or you’re under so much time pressure that you can’t think it through first, forcing yourself to write the solution isn’t helpful.

Back in 1985, computer scientist Peter Naur argued that the most valuable part of programming isn’t the code itself. It’s the understanding the programmer builds while creating it. The code is just the result.

That idea feels especially relevant today. AI can generate code very quickly, but it can’t build your understanding for you.

The goal should always be to make sure you’re still doing the thinking that helps you understand the system. That’s the part of the job that makes you a better engineer.

So what does that look like in practice? Here’s the approach I’d recommend to any senior engineer today:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Ask any engineering manager how they grow their best junior and you’ll get a list of mentoring tips: pairing sessions, thoughtful code review comments, a career chat every quarter. All genuinely useful but none of them involve the one lever that actually predicts whether that junior becomes great: what they get assigned.

A senior engineer can teach your best junior everything they know about software design, trade-offs, and how to navigate the org. They can be a fantastic mentor. What they can’t do, no matter how good a mentor they are, is decide that junior spends the next quarter owning something bigger. That decision sits with whoever controls assignments. On most teams, that’s you.

Mentoring

Mentoring has a real impact on people’s careers.

A long-term study at Sun Microsystems found that employees with mentors were five times more likely to be promoted than those without one. Around 25% also received a pay rise, compared with just 5% of employees who weren’t mentored. Another study of 120 junior engineers found that 94% of mentored engineers were still with the company after 18 months, compared with 81% of those without structured mentoring.

A team that keeps its best junior engineers avoids months of hiring, onboarding, and lost momentum.

Research from the Center for Creative Leadership also found that around 70% of leadership growth comes from challenging on-the-job experience, not courses or formal training.

The biggest opportunities for growth come from owning real work, making decisions, and learning through experience. And that’s something only a manager can provide. A mentor can offer advice and guidance. But only a manager can give someone the stretch projects and responsibility that turn potential into real growth.

So the question isn’t whether investing in high-potential juniors is worth it. The real question is whether you’re giving them the opportunities that help them grow.

The three categories of investment

It’s important to understand why “just mentor them more” isn’t enough.

Mentoring and managing are different. If you treat them as the same thing, you can spend months helping someone without actually changing what they do day to day.

Growing a junior engineer usually comes down to three things:

Technical mentoring

Teaching them how to design systems, make trade-offs, and think beyond writing code. This is what helps someone become trusted with bigger technical problems.

Career coaching

Helping them navigate the workplace, build influence, and figure out the kind of engineer they want to become, not just how to complete their next ticket.

Stretch projects

Giving them work that’s just beyond their current level, with support along the way. Research shows these assignments work best when they last a few months and come with real backing from their manager.

The first two can be done by almost any experienced engineer. The third is different. Only a manager decides who gets which projects. Only a manager can give someone the opportunities that actually grow their skills and responsibilities.

That’s the difference between teaching someone and helping them grow. Many engineering managers do the first, but forget about the second.

What happens when nobody gives them real ownership

If someone gets mentoring but never gets meaningful responsibility, their growth eventually slows down.

This pattern often lasts for years. Even if their manager changes, the habits stay the same because they’ve learned, over time, that they’re there to execute, not to own.

You start to see the same behaviours:

• They avoid changing code they didn’t write.

• They stop asking why things work and focus only on getting the task done.

• They wait for someone else to make the important decisions.

And then... when real ownership is finally offered, they often hesitate.

After years of never being trusted with important work, many people stop seeing themselves as someone who should own it.

This is why giving juniors ownership matters. Someone is teaching them what their role is, whether that’s intentional or not.

If you give them real responsibility, they’ll learn to think like owners. If you never do, they’ll learn to wait for permission.

So how do you actually help someone grow?

In the rest of this article, I’ll cover three practical techniques:

1. How to choose stretch projects that teach ownership, not just execution.

2. A simple three-step process that helps juniors make better decisions on their own.

3. How senior engineers without management responsibility can still create these opportunities, and how to get a reluctant manager on board.

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Gloria Mark, a professor at UC Irvine has spent two decades measuring attention at work. She found it takes about 23 minutes and 15 seconds to fully return to a task after a meaningful interruption. A joint study by Qatalog and Cornell found that even switching between two apps costs about 9.5 minutes of lost momentum.

The person generating the bulk of a team’s interruptions usually isn’t a badly-timed meeting invite, or a noisy slack channel. It’s the manager. Every “quick question” or “can you jump on a call” is 23 minutes of someone else’s focus, spent by you.

I used to read that stat and think it was an argument for eliminating interruptions, but it’s not that. The habits that made me efficient as a senior engineer, the ones I still see recommended to new engineering managers everywhere, assume that if you protect enough deep work, the rest sorts itself out. Does it though?

What I follow as an Engineering Manager is a smaller set of habits, rebuilt for a job that’s fundamentally about other people’s context switching. Four of them changed how I run my week.

1. The decision log

As a senior engineer, I wrote everything somewhere. Every gnarly bug, every architecture decision, every “why did we do it this way” started as a messy doc and ended up as a design doc or a jira ticket. It worked, because the audience for that writing was future-me and the two or three engineers touching that system.

That same habit applies for engineering managers. Why you didn’t promote someone this cycle. Why you descoped a feature under deadline pressure. How you plan people’s progression and the steps they need to follow to get where they want to be. All of that benefits from being documented.

You need to have a decision log for your judgment calls. One line, added the day you make the call: what you decided, why, and what you’d need to see to change your mind.

The first time this paid off for me was a headcount decision I’d made and half-forgotten. Six months later, my skip-level manager asked why I hadn’t backfilled a role. I had the actual reasoning in front of me in 10 seconds. That’s the whole point... the log isn’t for your team. It’s so you’re never rebuilding your own reasoning from memory, under pressure, in front of the person questioning it.

2. The near-miss review

When there’s an incident it’s good practice to do a post incident review. How about when we just about avoid one?

I love having postmortems that cover the outage that almost happened, not just the one that did. That can also be applied it to the other parts of your job. The meeting where you almost said the wrong thing to someone. The 1:1 where you nearly let a fixable performance issue slide because confronting it felt harder than avoiding it. The moment you caught yourself about to side with the loudest person in a room instead of the person who was right.

Those near misses are available to you for review and almost nobody reviews them because there’s no known ceremony for it.

You can create one for yourself quite simply. Just book in your calendar fifteen minutes every week, with one set of questions. Where did I almost mishandle something this week, and what made me catch it in time? Was it luck, or a signal I got right, and can I get that signal earlier next time?

I started keeping mine next to my decision log, and a pattern that showed up quickly was that most of my near misses happened in the same 20 minutes before a 1:1 I’d been avoiding. Knowing that changed how early I now flag a conversation I’m dreading, instead of letting the avoidance itself become the risk.

That’s two of the four. The other two are the ones that cap the interruptions I opened this issue with, including the exact rule I follow to prevent myself from sending “got a sec?” type of meetings:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

I can tell you someone’s level before they finish their first answer.

Not because I’ve read their resume closely, and not because I’ve quizzed them on architecture. I can tell from the first ninety seconds of a behavioral answer, before they’ve even gotten to the result, whether I’m talking to a mid-level engineer or a Staff one.

This is how interviews work, and once you see it, you can’t unsee it.

Your level gets decided very early

Two engineers can describe the exact same project, with the exact same outcome, and walk out of an interview leveled two grades apart.

One says: “We had a service that kept falling over, so we spent a sprint fixing the flakiest parts. It went well, things are more stable now.”

The other says: “I noticed our checkout service was failing intermittently, tracked it to a shared connection pool three teams were touching without realizing it, and decided we needed a two-week freeze on that service to get a fix in. Two teams pushed back. I walked them through the incident data and we agreed on a smaller, scoped fix instead.”

Same project. But an interviewer hears two completely different candidates. The first sounds like someone who was part of the team. The second sounds like someone who ran the effort.

Sometimes I stop taking notes on outcomes by the time the candidate gets to them, because the outcome rarely tells me anything I didn’t already decide two sentences earlier.

I’m listening for:

• Scope of ambiguity. Did you get handed a ticket, or did you have to figure out what the actual problem even was?

• Who you influenced. One teammate is a data point. Three teams with conflicting priorities is a different job entirely.

• Whether your influence stopped at your team. The signal is what happened with people who didn’t have to listen to you.

• Whether you name the trade-off. “We decided to do X” tells me nothing. “We chose X over Y because Y would’ve meant a slower rollback if it broke” tells me you understood the bet you were making.

• Whether you noticed the problem or were told about it. Passive discovery is fine for a junior engineer. Active discovery, before anyone assigned it to you is what’s expected of senior+.

None of this requires more experience than you have probably. Most candidates that are under-levelled have plenty of the right experience. They just never learned to say it that way.

I wrote more about what this looks like from the hiring side in Your interview process for senior engineers is wrong.

The frameworks aren’t the problem

Everyone tells you to use STAR. Fewer people tell you what it’s actually for.

STAR, or CARL, or whichever four-letter acronym you’ve bookmarked, is not something you build in real time while a stranger watches you think. It’s a filter you apply beforehand, to decide which three or four stories from your career are worth having ready.

Most candidates skip that step. They get in their interviews with a general sense of “things I’ve done” and try to shape a structured answer while someone is taking notes on how long they’re taking to get to the point. That’s where the rambling comes from.. you’re doing outline and delivery at the same time, out loud, for the first time, in the interview of the company you really want to join.

If you ramble for six minutes on a question you actually know the answer to, we can agree that it’s a rehearsal problem, not a knowledge gap.

A written answer isn’t a spoken one

So some candidates do the sensible thing. They sit down, they write out their STAR stories in a doc, they polish the language, they read it back a few times.

And then they get into the interview and it falls apart anyway, because writing and speaking are two different skills that happen to use the same words.

A written story doesn’t interrupt you, doesn’t ask “wait, why did you choose that over the alternative?” halfway through, and doesn’t force you to improvise an answer to a follow-up you didn’t prep for while keeping your tone steady.

This is also why Stop interviewing like a mid-level engineer keeps coming up in conversations I have with my mentees who are technically strong and still get rejected. Their gap usually is that their judgment has never been pressure-tested out loud before their interviews.

You can’t hear your own blind spot

You cannot self-assess your own narration.

You already know what you meant and that’s exactly the problem. When you read your own STAR doc back to yourself, your brain fills in all the context you didn’t say out loud, because you were there. You’ll never catch yourself saying “we decided” when you meant “I decided”, because in your head, you already know it was you.

An interviewer doesn’t have that context. They only have your words. Which means the only way to find out what your story actually sounds like from the outside is to say it out loud, to someone who wasn’t there, who’s willing to interrupt you and push back the way a real interviewer will.

Most people don’t do this until their actual interview. The first time they hear their own story land is also the only time it counts.

You need to rehearse with friction built in. Say the story out loud. Get interrupted the way a Bar Raiser or a Staff-level panel actually will. Then find out, in a language more specific than “that felt fine”, exactly where the story read as scope you own versus scope you were near.

That’s the entire premise behind the mock interview coach I built into em-tools.io/interview-prep. It’s not a chatbot that tells you “good answer, nice use of leadership”. You have an actual voice conversation, it follows up the way a real interviewer follows up, and it scores you across the exact signals above, including scope and complexity, specificity, and how much of the story was you versus “the team”. You get a model answer next to your own, so you can see precisely where the same accomplishment could have read one level higher.

It’s free to run your first few questions through it. If a story you thought was strong comes back scored as vague on scope or thin on trade-offs, that’s the version of that feedback you actually want before your interview.

Try a free mock interview with one story you’re planning to use in your next loop.

What’s next for you probably isn’t more prep. It’s finding out, before it costs you a level, what your best story actually sounds like from an interviewer’s perspective.

See you in the next one,
~ Stephane

P.S. If you’re looking for Engineering Manager roles, this is the exact system I have used to get multiple EM offers after only 2.5 years into being an engineer.

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

The best career advice I ever got from a manager had nothing to do with software engineering.

This was years ago, not long after I’d moved into engineering management. I’d spent weeks focusing on delivering good work, assuming that if I did my job well enough, people would naturally notice. During one of our catch-ups, my manager challenged that way of thinking.

He told me something along the lines of:

Being right isn’t the goal. Doing great work isn’t the goal either. Those things are just the baseline. The real game is making sure the right people understand the value of what you’re doing, that your ideas actually land, and that you’re part of the conversations where decisions get made.

At the time, it felt a bit cynical.

Now I think it was one of the most practical pieces of career advice I’ve ever received.

And after talking to hundreds experienced engineers and engineering leaders over time, I’ve realised I’m far from the only person who’s come to that conclusion.

Ask anyone who’s been doing this for a while

The interesting thing is that this wasn’t just one manager’s opinion.

I’ve since seen the same advice come up again and again from experienced engineers and engineering leaders.

If you ask people with 15 or 20 years in the industry what the best career advice they ever received was, you’d expect a lot of technical answers. Maybe something about writing cleaner code, designing better systems, or becoming a stronger engineer.

Instead, the advice is usually about people.

Whether you like it or not, influence is part of your job.

You’ll start hearing the same advice as you become more senior:

• How people receive your ideas matters just as much as the ideas themselves.

• You can be doing great work and still not be visible enough.

• Being right isn’t enough if nobody is listening.

This might not be the advice you want to hear, but it’s the advice the most experienced people keep giving.

Why this advice is so hard to accept

I think the reason so many people struggle with this advice is because it feels unfair.

As engineers, we’re taught that good work should speak for itself.

Write clean code. Build useful things. Solve difficult problems. If you do those well enough, people will notice.

Unfortunately, that’s only part of the story.

As you become more senior, your job becomes less about writing code and more about helping good ideas succeed. That means communicating clearly, building trust, influencing decisions, and making sure the people around you understand the value of the work.

It’s explaining your thinking clearly. Sharing progress before someone wonders what’s happening. Building relationships before you need them. Speaking up when you have something valuable to contribute.

None of those things take away from doing good work.

They help good work have a bigger impact.

Surely the answer is just to do great work

I used to think exactly the same.

The problem is that I’ve seen too many examples where it wasn’t enough.

I’ve seen incredibly talented engineers get overlooked because hardly anyone outside their team knew what they were doing. I’ve seen technically excellent projects get cancelled because the people making the decision never really understood their value.

As an individual contributor, you can often focus almost entirely on delivering results because your manager is doing a lot of this work for you. They’re explaining your team’s impact, fighting for resources, sharing successes, and making sure leadership understands why your work matters.

Once you become a manager, that responsibility becomes yours. Nobody is telling your story for you anymore. You’re now telling the story for your team. That’s something that many first-time engineering managers struggle with. They keep trying to succeed using the skills that made them a great engineer, when the role is asking for something different.

Doing the work is still important, but helping other people understand the value of that work becomes part of your job too.

The advice for engineering managers

As an individual contributor, you naturally think about your own visibility. As a manager, you should be thinking about your team’s visibility.

One of your responsibilities is making sure the people outside your team understand the value your engineers are creating.

That means talking about their successes. Explaining why their work matters. Making sure good work doesn’t go unnoticed simply because the people doing it aren’t interested in promoting themselves.

The other part of the job is protecting your team from unnecessary politics. Your engineers shouldn’t have to spend their time navigating organisational disagreements, chasing stakeholders for alignment, or constantly justifying every decision. That’s actually your job.

You need to absorb as much of it as possible so your team can focus on building great software.

Here are three practical ways I’ve found that help:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

A senior engineer I coach told me recently:

“I know what I need to do. I’m technically strong. I just need to improve my soft skills.”

He genuinely believed he’d figured it out.

He’s been an engineer for around eight years. People trust him. When there’s a difficult problem, he’s usually the one everyone goes to. Yet he’d been saying this exact thing to himself for the past couple of years while watching people he considered less capable get promoted ahead of him.

The thing is, this isn’t unusual.

I’ve heard variations of this from so many senior engineers. It sounds like someone who’s correctly diagnosed the problem and just needs to put in the work.

The problem is... they’ve diagnosed the wrong thing.

That’s not to say soft skills don’t matter. They absolutely do.

But that sentence contains two assumptions that can send people in the wrong direction. They spend years trying to fix one area while the real reason they’re not progressing never changes.

I want to unpack both of those assumptions, because I think you’ll recognise someone in this story.

Maybe it’s someone on your team. Or maybe it’s you.

The first mistake: comparing yourself to a version of reality that doesn’t exist

Before we even get to “soft skills”, let’s talk about the feeling underneath that sentence.

The feeling of being behind.

An engineer gets to their early thirties. They’ve been doing this for seven or eight years. They’re good at what they do. But then someone younger than them becomes Staff. Someone on LinkedIn announces they’re now a Director. Recruiters that used to reach out for more senior roles now stop even replying.

Slowly, they convince themselves they’re behind.

Behind who?

That’s the question I always ask.

Most of the time, the answer is someone they’ve never actually worked with. Someone whose career they’ve pieced together from LinkedIn posts, job titles and a few assumptions.

The reality is much simpler.

There isn’t some universal career timeline you’re supposed to be following.

In fact, fewer than one in ten engineers ever become Staff. That’s not because everyone else failed. It’s because that’s how engineering organisations are designed. The higher you go, the fewer positions there are. Most engineers finish their careers as Senior Engineers, and that’s completely normal. I wrote about this in a previous article: senior is the destination for most engineers, not a stepping stone everyone is expected to move past.

So when someone tells me they feel behind, I don’t try to reassure them. Instead, I ask them who they’re comparing themselves to. Because almost every time, it’s comparison that’s creating the feeling, not reality. Take away the comparison, and suddenly there isn’t anything to be behind on.

That’s the first mistake.

The second one is much more interesting. And I think it’s the one that actually keeps people stuck.

The second mistake: you’ve defined “technical” too narrowly

“I’m technically strong. I just need to improve my soft skills.”

There’s a hidden assumption in there.

It assumes your technical development is finished. That you’ve reached the point where there’s nothing left to improve technically, and now the only thing standing between you and the next promotion is communication, influencing and stakeholder management.

I don’t think that’s true at all.

Technical skills don’t stop mattering once you become a Senior Engineer.

The skills that get you from junior to senior are things like writing clean code, designing systems and solving difficult technical problems. The skills that get you from senior to staff are different.

Now you’re deciding which problems are worth solving. You’re making architectural trade-offs. You’re spotting complexity before it gets built. You’re thinking about the long-term health of systems instead of just the feature in front of you.

It’s still technical. It just doesn’t involve writing as much code.

That’s why I always find it interesting when someone tells me they’re “already good technically”. Good at what? Good at the skills that got you to Senior? Probably.

But are you developing the technical skills that Staff Engineers are expected to have? Those are different skills entirely. I think this is where a lot of engineers accidentally get stuck. They take a technical problem, label it as a soft skills problem, and then spend years trying to solve it from the wrong angle.

What I see as a manager

As a manager, I can often tell that someone isn’t going to get promoted months before they realise it themselves. And it’s almost never because of their technical ability.

The problem usually shows up somewhere much smaller. It can be a meeting, a design review, or a discussion about priorities.

The engineer leaves thinking it went well because they made good points, were technically right, but they miss something important. Being right isn’t the same as getting people to follow you. And promotion committees care far more about the second one.

One of the things I hear all the time is:

“I’m just not naturally good with people.”

Or:

“I’ve never been good at reading the room.”

I don’t buy that. Reading the room isn’t something you’re born with. It’s a skill.

Like any other skill, you can break it down, practise it, get feedback on it and improve it over time. The problem is that most engineers never treat it like a skill. They treat it like a personality trait.

So instead of asking:

“How do I get better at soft skills?”

Ask something much more useful.

Where, specifically, do I keep falling short?

Because once you can answer that, you have something you can actually improve.

Below are three places I see engineers get stuck over and over again, and how to work out which one applies to you:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

One of the engineers I’m coaching asked me something this week that I suspect a lot of senior engineers are wondering.

“Do you think I’m stuck?”

It wasn’t an angry question. He genuinely wanted to know.

He’s been a Senior Engineer for four years. He was one of the first people to join his team and has become the engineer everyone relies on. When something complicated comes up, people naturally look to him. He’s respected across the team, mentors other engineers without being asked, and has earned the trust that every manager hopes their senior engineers will build.

By almost every measure, he’s doing an exceptional job.

The problem is that there’s already a Staff Engineer above him.

So when he asked whether he was stuck, this wasn’t really a question about his performance. It was a question about the very existance (or lack thereof) of the opportunity.

And I think this is where a lot of managers accidentally damage trust. The easy response is to reach for the carrot.

“You’re close.”
“Let’s build a promotion case.”
“Give it another year.”

I’ve said versions of those things myself. But looking back, I think they’re often the wrong answer. Not because the engineer isn’t capable. Because sometimes there simply isn’t another role to promote them into.

When we pretend otherwise, we create expectations we can’t control. Every promotion cycle that comes and goes without the promised outcome chips away at trust a little more. Eventually, even your best engineer starts wondering whether you really meant what you said.

The difficult conversation isn’t telling someone they’re not ready.

It’s telling someone they are ready, but the organisation isn’t.

Once I realised that, I completely changed how I approached these conversations.

I stopped trying to convince people that the next title was just around the corner.

Instead, I started helping them think much more broadly about what growth could look like.

Ironically, those conversations led to more trust, better engagement, and - more often than not, better retention.

But before we talk about what managers should do differently, we need to understand why this situation exists in the first place.

Because despite how it feels... your best senior engineer probably isn’t stuck at all.

Why so many senior engineers end up asking this question

If you’ve managed engineers for long enough, you’ve probably noticed that quite quickly junior engineers become mid-level engineers, mid-level engineers become senior engineers, and then... everything seems to slow down.

Some seniors eventually become Staff Engineers, but most don’t.

It’s easy to look at that and conclude the promotion system is broken. I don’t think it is.

Most senior engineers I talk to feel some type of frustration about their lack of progression.

“I’ve been senior for years.”
“There doesn’t seem to be anywhere to go.”
“I keep getting told to wait.”
“The people above me never leave.”

If you’re an engineering manager, there’s a good chance one of your own engineers is thinking exactly the same thing.

The mistake many of us make is how we explain what’s happening. We call it a promotion bottleneck.

That sounds reasonable.
But I don’t think it’s the right mental model.

It isn’t a bottleneck.

It’s a pyramid.

A bottleneck suggests that something has gone wrong. That promotions should be flowing but have somehow become blocked. Engineering organisations aren’t designed like that.

They’re designed to get narrower as you move up.

A growing organisation might have dozens of junior and mid-level engineers, twenty senior engineers, five Staff Engineers, and one Principal.

That’s not a flaw. That’s simply the shape of the organisation.

As engineers become more senior, the role changes. It stops being about delivering your own work and becomes increasingly about helping dozens (or sometimes hundreds) of other engineers deliver theirs. That naturally means fewer positions exist.

Senior Engineer is a career level rather than simply another step towards Staff. Most engineers who reach senior will spend a significant part of their career there, because that’s exactly how engineering organisations are built.

Your engineer probably isn’t stuck.

They’ve simply reached the point where promotions stop being about individual performance and start depending on whether the organisation actually needs another person at the next level.

Staff isn’t “Senior++”

I think this is where a lot of promotion conversations go wrong. We talk about Staff Engineer as if it’s simply the next rung on the ladder.

Be a better Senior Engineer.
Have a bigger impact.
Write better code.
Eventually you’ll become Staff.

That’s not actually what happens. Staff isn’t Senior Engineer, but more. It’s a different job.

That’s an important distinction, because most engineers spend years trying to become a better senior when what they really need to understand is whether they even want the role above it.

When I ask engineering managers what they expect from a great Senior Engineer, I usually hear things like:

• Delivers complex technical work.

• Makes good engineering decisions.

• Mentors other engineers.

• Raises the quality of the team.

• Owns difficult projects.

Now ask the same question about a great Staff Engineer and the answers change completely. Instead of talking about code, people start talking about influence.

• Cross-team alignment.

• Technical strategy.

• Helping multiple teams move faster.

• Creating clarity when nobody owns the problem.

Much less time is spent building things yourself.
Much more time is spent helping other people build the right things.

That’s why I love the opening line from The Staff Engineer’s Path.

“You’re not a manager, but you are a leader.”

The role isn’t becoming a better individual contributor. It’s increasing your leverage. Sometimes that means writing code. Often it means making sure twenty other engineers don’t have to. That’s also why Staff roles appear much later as organisations grow. A company with twenty engineers doesn’t usually need someone thinking across five teams. There aren’t five teams.

As organisations get larger, coordination becomes more valuable than individual output, and that’s when Staff Engineers start to appear.

The role exists because the organisation needs it. Not because someone has been a Senior Engineer for long enough.

I think that’s one of the hardest truths for ambitious engineers to accept.

Being ready for Staff doesn’t automatically create a Staff position.

The business has to need one.

And another part I think managers overlook:

Not every Senior Engineer actually wants that job.

Some absolutely do. They love influencing across teams. They enjoy shaping technical direction. They thrive in ambiguity. Others don’t. They enjoy building software. They like being close to the code. They don’t want more meetings, more organisational politics, or more time persuading people than programming.

Management isn’t a promotion - it’s a change of profession. I think the same idea applies here. Becoming a Staff Engineer isn’t simply moving up. It’s choosing a different kind of work.

That’s why I think one of the most useful questions a manager can ask is:

Do you actually want the Staff job... or do you just want the Staff title?

Those are very different conversations.

The carrot is often what does the damage

Once you accept that Staff roles are limited, another question naturally follows.

So why do so many managers still promise them? I don’t think it’s because managers are dishonest. I think it’s because we’re uncomfortable disappointing people. Imagine one of your strongest engineers tells you they want to become Staff. You know they’re capable and you’d love to promote them. But you also know there isn’t going to be another Staff position any time soon. That’s an awkward conversation.

So instead, we reach for something that feels kinder.

“You’re really close.”
“Let’s work towards it over the next year.”
“Keep doing what you’re doing.”

Most of us have probably said something like that. The problem is that these promises usually aren’t ours to make. Whether someone gets promoted rarely depends only on how good they are. It also depends on whether the organisation actually needs another person operating at that level. Those are two very different things. When we blur them together, we create expectations that we can’t control.

At first, the engineer will be motivated. They will take on more responsibility. They will become even more valuable. Then the next promotion cycle arrives and nothing happens. So we have another conversation.

“You’re still on track.”
“Let’s build an even stronger case.”
“Maybe next cycle.”

Without realising it, we’ve turned career growth into a moving finish line. Every time that finish line moves, trust gets a little weaker. Eventually, the engineer stops hearing encouragement. They hear uncertainty. Or worse... they start wondering whether we’ve been telling them what they wanted to hear rather than what they needed to hear. Ironically, the conversation we thought would help retention often becomes the reason people leave. Not because they didn’t get promoted. Because they stopped believing us.

I’ve become convinced that engineers can handle difficult news far better than vague promises. If there isn’t likely to be a Staff opening in the foreseeable future, just say so.

That doesn’t end the career conversation. It starts a much better one. Because once the false promise disappears, you can finally focus on the question that actually matters.

How does this person continue growing, even if their title doesn’t change?

In my experience, that’s where the most valuable management conversations begin. And it’s also where I think most managers need a different playbook.

So what should you do instead?

Over the last few years, I’ve settled on four conversations that have consistently led to better outcomes. None of them require an open Staff position. None of them rely on vague promises.

So here’s the first one:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

Infrastructure is easy to ignore... until production goes down

Sponsored by Palark

Not every engineering team needs a dedicated SRE organisation. But every team benefits from knowing experienced engineers are available when something breaks. Palark’s DevOps Insurance offers on-demand support for production incidents through a simple monthly subscription.

See how it works

Thanks to Palark for sponsoring this newsletter!

Everyone keeps asking the same question.

Does AI actually make developers more productive?

I don’t think that’s the right question.

Over the past year, two of the biggest studies on AI coding reached almost completely opposite conclusions.

GitHub found developers completed a programming task 55% faster when using AI.
Then an independent research lab, METR, studied experienced open-source developers working on real tasks inside codebases they already knew.

Those developers expected AI to make them roughly 20% faster.

Instead... they finished 19% slower.

So who’s right? I think both are.

They were simply measuring two very different environments.

GitHub’s study looked at a relatively clean programming task: building an HTTP server from scratch.
METR looked at something far messier: experienced engineers making changes inside large, existing codebases where every decision has consequences.

Those are completely different kinds of work.

One rewards speed. The other rewards judgment.

And that’s the part I think many teams miss.

AI amplifies your standards

You’ve probably heard someone say that AI is an amplifier.

They’re right.

The problem is that statement isn’t very useful.

It’s a bit like saying, “Exercise makes you healthier.” But it doesn’t tell you what to actually do.

Here’s the version I think engineering managers should care about:

AI amplifies whatever standards already exist inside your team.

If your team has clear engineering practices, AI helps people move faster without losing quality.
If your standards are vague, inconsistent or simply live inside people’s heads, AI helps everyone make bigger mistakes more efficiently.

That’s why two companies can use exactly the same AI model and end up with completely different results.

A few months ago I wrote that the biggest problem with AI coding wasn’t the model itself - it was that nobody owned everything around it.

Who’s responsible for the prompts? The context? The rules? The review process? The answer, in many teams, is nobody.

This article is the natural follow-up.

Because once someone owns the standards, the next question becomes:

What should those standards actually be?

After reading Google’s latest paper on the AI-driven software development lifecycle, along with several other pieces of recent research, I kept coming back to the same five principles.

And they’re the five standards I wish every team followed.

The important thing isn’t that they’re my standards.

It’s that your team has standards everyone can point to.

Standard 1

Decide whether you’re building a prototype or production software before you prompt the AI

One of the biggest mistakes I see isn’t teams choosing the wrong approach.

It’s never choosing one at all.

There’s a huge spectrum in how people use AI.

At one end is what people now call vibe coding. You describe what you want. The AI writes something. You paste the error back in. Repeat until it works. For a weekend project that’s completely fine. Move fast, experiment, throw it away if you need to.

At the other end is production software. The code needs to be tested, reviewed, understood. Something that someone else can safely maintain six months from now. Neither approach is wrong.

The mistake is never deciding which one you’re doing.

That’s how a quick experiment slowly turns into a production system. One feature gets added. Then another. Someone fixes a bug. Someone else builds on top of it. Before anyone notices, yesterday’s prototype has become tomorrow’s platform. Nobody planned for it.

It just... happened.

A good example is what happened at Replit last summer.

The company’s founder had explicitly declared a code freeze.

Despite that, an AI agent executed destructive commands against a production database, affecting data belonging to more than a thousand companies. It then generated roughly 4,000 fake users in an attempt to hide the problem before eventually concluding that recovery wasn’t possible. The founder restored everything manually.

Later, the agent summarised the incident with one sentence:

“This was a catastrophic failure on my part.”

It’s tempting to read that story and conclude the AI was the problem. I don’t think it was. The real problem was that the boundary between experimentation and production wasn’t enforced.

The agent treated a live production system like a sandbox because nobody had clearly told it otherwise.

The rule

Before anyone opens an AI coding assistant, answer one question.

Is this a prototype or is this production software?

Write the answer in the ticket.
Write it in the PR.
Say it during planning.

Anything that ships to production gets the full engineering process. Specifications, tests, code review, monitoring, and so on. Prototypes don’t need all of that.

One sentence at the beginning of the task determines every decision that follows.

That’s a surprisingly cheap way to avoid some very expensive mistakes.

Standard 2

A human should decide what “good” looks like before the AI writes code

Most people think the value of AI comes from writing code faster.

I don’t.
I think the real value comes from implementing well-defined ideas faster.

Those are very different things.

One of the most interesting pieces of AI coding research I’ve read recently looked at a system called TDFlow.

When the AI was given human-written tests before it started coding, it solved 94.3% of tasks on SWE-Bench Verified.

When it had to write the tests itself first its performance dropped to 68%.

The difference was the quality of the specification.

That sounds like an argument for Test-Driven Development. And it kind of is.

But there’s an even more important lesson here.

If the same AI writes the requirements...
...writes the tests...
...and writes the implementation...

Who’s checking whether it actually understood the problem? Nobody.

The AI isn’t validating the requirements.

It’s validating its own interpretation of the requirements.

Imagine asking someone to sit an exam... and also letting them write the marking scheme.

You might get a very high score. That doesn’t mean the answers are correct. It just means the questions matched the answers. AI can fall into exactly the same issue.

If it misunderstands what you wanted, it happily writes code that solves the wrong problem... and then writes tests proving the wrong problem has been solved correctly.

It gets worse by the way.

Researchers at Anthropic documented a coding model that learned to simply call sys.exit(0) instead of actually fixing failing tests.

The AI isn’t trying to cheat, it’s just trying to optimise for the goal you gave it. Sometimes the shortest path to “all tests passing” isn’t fixing the bug, it’s removing the thing complaining about the bug.

That’s exactly why humans still need to define success.

The rule

Humans own the specification. Humans own the acceptance criteria. Humans own the tests.

Only then does the AI start writing code.

The AI’s job is to satisfy your definition of “correct”. It should never be allowed to invent that definition itself. Once you make that distinction, AI becomes dramatically more useful, because you’ve stopped asking it to judge its own homework.

Here’s the rest of the standards:

Read more

Subscribe now

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

🚀 Practice behavioral interviews with an AI coach that challenges your answers and scores you across 8 hiring dimensions.

A few weeks ago I was part of a discussion between experienced engineering managers.

One person shared something that really stuck with me. His company had started measuring every engineer with individual productivity metrics. A few months later, the engineers everyone relied on became less helpful. They stopped jumping into tricky debugging sessions. They stopped mentoring junior engineers and helping others unless they absolutely had to.

Not because they cared less. but because every minute spent helping someone else made their own numbers look worse.

Once people realized what was being measured, they changed what they spent their time on.

They simply optimized for what was being measured.

The engineer who stopped helping was rational.

He was the best mentor on the team and the person who knew the codebase best, so naturally he spent most of his day pairing and unblocking other people. The problem is that only one person gets to make the commit. He quickly realised that he was not getting the recognition for the work he was doing. So he stopped.

He went heads-down on his own tickets, his numbers recovered, and the team lost the one person who made everyone else faster. By the time anyone connected the dots, he was already interviewing elsewhere.

Individual productivity metrics measure what one person produces, and the most valuable engineering work is the work that helps other people produce.

I’ve written before about how your team’s throughput is lying to you and what actually happens when you try measuring developer productivity. This is the sharper version of both. The problem is not just tracking misleading numbers.

Your stupid metrics go up

This is why leaders miss it until it’s too late.

When you introduce individual output metrics, the numbers usually improve in the first quarter. Of course they do. Your engineers stop “wasting” time on work that doesn’t count, and they pour those hours into their own visible output. PR counts rise. Tickets close faster. The chart goes up and to the right.

So leadership reads it as proof that these metric have a positive impact.

What these metrics can’t show is that the rising line and the collapsing collaboration are the same event. The output goes up because the helping went down. You’re not necessarily watching a team get more productive. You might be watching it cannibalize the invisible work that kept it healthy.

By the time the damage is legible, it shows up as things a dashboard doesn’t track. A senior leaves. An incident that should’ve taken an hour takes a whole day because nobody does root cause analysis anymore. Onboarding doubles because no one puts time into mentor.

When the bus factor catches up with you

Sponsored by Palark

The failure mode this whole issue describes - the one person who knew the system leaves, and the next incident drags on for a day - is exactly the gap Palark just built a product for.

Maintaining infrastructure and need extra hands to handle urgent incidents? DevOps insurance is a new B2B offering that delivers 24/7 peace of mind at low fees.

Palark, a holistic DevOps and SRE agency from Germany, just launched an affordable support service that works like a fire brigade for your cloud or server infra.

Similar to health or car insurance, DevOps insurance offers subscription plans with reasonable monthly fees and prompt assistance in case of infrastructure emergencies. It’s a perfect fit for:

• small teams with no dedicated SRE or a bus factor in operations

• cutting costs when infra “just works”

• unexpected failures in complicated cloud/server services

Learn more

Thanks to Palark for sponsoring this newsletter!

The behaviors die in a predictable order

Collaborative work doesn’t collapse all at once. It dies in sequence.

Rank each behavior by a simple ratio: how much it helps the team, divided by how much personal credit it earns. The work with high team value and near-zero personal credit dies first, because it’s the easiest sacrifice to justify when you’re being measured as an individual.

First to go: unblocking a colleague. It’s pure altruism. There’s no artifact, no commit with your name, or any relevant metric. The moment your time is being counted, the rational move is to stop helping and let people figure it out themselves. This is the same dynamic behind why 51% of devs stopped asking their teammates and ask AI instead. When asking costs the asker and helping costs the helper, both sides retreat.

Second: root cause analysis. Fixing a bug counts. Understanding why it happened does not. Deep investigation tends to surface more bugs that you’re now on the hook for. With ticket-closing metrics you have “little incentive to do more than the bare minimum to close tickets”.

Third: substantive code review. Real review takes time you can’t log against a story or a defect, so it reads as slacking. So review degrades into rubber-stamp approvals. It gets worse when the metric is dumber than that. At one large company, engineers were judged partly on iterations per review, and averaging more than two round-trips per change marked you as “sloppy” and put you on the chopping block. Thorough review became a firing risk. I’ve written about how to budget your team’s code review capacity, but no budget survives a metric that punishes the reviewer for caring.

Fourth: mentoring and pairing. This one is social and people feel bad abandoning it. But every hour you spend teaching is an hour subtracted from your own visible numbers. Eventually even the generous engineers stop. “Who has time to mentor junior colleagues when you gotta bump your LoC count for the quarter?”

Then the vacuum fills with gaming. People cherry-pick the easy tickets, split one change into five tiny PRs, inflate tasks, and write verbose code to look good on the stupid metrics.

This is structural

The objection I always hear at this point is “we’ll just be careful about which metrics we pick”. That doesn’t work, and there’s 50 years of research saying why.

Most people know Goodhart’s Law: when a measure becomes a target, it stops being a good measure. The version that matters here is what the researchers call the adversarial variant. Once people know the proxy is the target, gaming isn’t a risk you might avoid with a smarter metric. It’s a guarantee. There’s no individual metric careful enough to survive being tied to someone’s review.

I prefer Campbell’s Law, from 1976, because it names a second failure. The metric gets corrupted and the underlying work degrades. Campbell’s own example was an employment office: measure it on cases handled, and staff cherry-pick the easy placements while abandoning the people who most need help. Swap “cases” for “tickets” and you’ve described your engineering org.

Kent Beck in his response to McKinsey: “If you choose to create incentives around measures, know that you will never again receive accurate data.” The tighter you couple the metric to consequences, the less true your data becomes.

All that being said, the question naturally becomes what to measure instead.

Here’s what I personally track at the team versus the individual level:

Read more