But the interview is also your ONE chance to see what working there is really like. And toxic startups will not tell you they’re toxic.

They use more modern and “interesting” language.

Once you know what to listen for, you won’t hear those phrases the same way again.

Find out my thoughts by watching this video:

I am posting a new video every week on getting into or succeeding in engineering management. If that’s useful to you, subscribe on YouTube so you don’t miss the next one.

And if you’d like some career advice or help preparing for your next interview, I offer 1:1 coaching.

See you in the next one,
~ Stephane

But, if you want to future-proof your career, you need to stop viewing yourself as a code generator and start focusing on other, more important things.

Success and long-term stability now requires comfort with taking on meaningful responsibility.

Find out my thoughts by watching this video:

I am posting a new video every week on getting into or succeeding in engineering management. If that’s useful to you, subscribe on YouTube so you don’t miss the next one.

And if you’d like some career advice or help preparing for your next interview, I offer 1:1 coaching.

See you in the next one,
~ Stephane

In this week’s video, I share the four things I’d do today if I was a senior engineer looking to move to management (like I did about 10 years ago).

One simple thing you can do is take this question to your manager:

What would you need to see from me before you’d feel comfortable putting me forward for a manager role?

But you need to be ready for the actual conversation after that.

Find out how to do that by watching this video:

I’m working on my next video, and I’d love your help shaping it. I’m torn between these 4 titles:

1. The worst interview I ever had

2. I failed this interview and… I would have def rejected me too!

3. The interview mistake I made that you’re probably making too

4. Everything I did wrong in my worst interview

I will be posting a new video every week on getting into or succeeding in engineering management. If that’s useful to you, subscribe on YouTube so you don’t miss the next one.

And if you’d like some career advice or help preparing for your next interview, I offer 1:1 coaching.

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 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.

If your director has told you to “be more strategic” or “think second-order”, you’re in a tough spot.

This piece is for people who have received this sort of feedback, as well as the managers who might be about to give it.

I strongly believe that this feedback is coming from one of three places. And you need to act differently to find out exactly which one that is in your next 1:1.

Three different problems

Nobody knows what it means to ‘be more strategic’.

It tends to stand for 5 things:

• prioritisation

• root-cause thinking

• second-order thinking

• framing decisions for decision-makers

• connecting work to the business

You need to know which one of those apply to you.

Sometimes it might not even be a skill issue. Think about why the feedback is vague in the first place. Managers overestimate how clear their feedback is. Interstingly, the gap between what they think they said and what the employee heard widens as the message gets more negative.

Another interesting finding is that feedback loses effectiveness as it pulls attention away from the task and towards the self.

Here are the three problems I think this type of feedback covers:

• A skill gap. For example, you see problems and bring options instead of recommendations.

• A context gap. You optimise well for your team’s goals but don’t know what the other teams or the organisation care about.

• A relationship gap. A polite wrapper for something harder to say, such as “you get defensive when I challenge you”.

The same sentence can mean three different things.

This is my working theory. I’ve not seen a study on this, so it’s purely a practitioner’s argument.

The question I recommend asking to see which gap you have and what to do with the answer:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

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

If you have an Engineering Manager interview coming up - watch this video!

I haven’t made a video in 3 years and it’s been on my mind all this time.
I am now happy to commit to a process and workflow that works for me.
First of many more to come!!

It’s so common nowadays to be producing code through agents.

Sometimes engineers working on a big feature go head down and have multiple agents running in parallel until they’re able to have the feature done. Which doesn’t take long. But the output is many PRs that need to be reviewed.

This is code, that once merged it’ll need to be maintained. A friend of mine says that once code is merged it immediately becomes “legacy code” these days.

When that feature will need to be extended it’s a good starting point if it fits the rest of the system well. At times though you’ll find that maybe there’s a new field somewhere that means almost the same thing as an existing one, or a component owns behaviour it shouldn’t.

And these are decisions that in the rush of reviewing and approving PRs might get missed.

Agents are capable of producing good code, but they also make tiny decisions, which over time require us to understand them.

We used to think while coding

Dax, co-founder of OpenCode, said in a conversation with The Pragmatic Engineer that before AI, he spent about 95% of his energy thinking about what to do and 5% doing it.

What does that even mean?

Writing code was already a small part of his work and most of his effort went into deciding what was worth building, how it should work, and whether the result was good. He’s now pushing himself to have the same split (96% thinking and 4% doing).

“Coding” used to involve things like looking at an old function, understanding why it was awkward, and thinking about how to best refactor it. Finding an edge case halfway through implementation. Or discovering that the approach you’d planned didn’t quite work with an existing service.

Agents can take some of that load and allow us to lean on spending more time “doing” than “thinking”. Engineers still need to have a really good picture of the system.

You can have multiple agents running at once, but can you keep a useful mental model of all changes at the same time? And can they be presented in a way the rest of your team can review them properly?

Stay close to the decisions

You don’t really want to have engineers write a design doc before every prompt - that would be ridiculous.

For certain changes though, we need to slow down a bit. A new data model, interface, component, or a change in operational behaviour. These changes can have long term impact if done badly.

Before implementing that kind of change, I’d want the owner of that feature (a human) to be able to explain

• What are we changing, and why does it belong here?

• What must still be true when we’re done?

• Which choice would be painful to reverse later?

It can be as simple as having a mini ADR for it that is shared with the team.

What I tend to recommend to engineers who struggle with multi-tasking is:

• having a substantial task as their main focus

• using an agent to explore options and implement parts of it

• review those parts before proceeding

They can have small tasks run on the side when you already understand them well.

A PR needs someone who can explain it

When reviewing code, I’d look at the shape of the change before getting lost in the implementation.

Are there new dependencies? Do we have a new way to do something that was already possible? What are the failure modes of this change?

Sometimes it’s not unreasonable to ask the author to explain the choices they made.

As I am writing this, I remembered a study from Anthropic from earlier in the year that engineers using AI while learning a new library scored lower on a follow-up quiz compared to ones who didn’t. It was mostly made with junior participants so take it with a pinch of salt (as always). But I would ask whether our engineers are learning enough about what they ship to be able to fix it when it breaks.

Review capacity

Like we said, it’s easy to spin up a new agent while the first one is still running. At some point though, you’ll have to naturally start reviewing the work agents did.

And there are only so many hours in one day.

If engineers start opening many PRs per day (some of which will be slop grenades), can they explain the decisions in all of them? Can other engineers review them? And will useful information from them be shared across the team accordingly?

How many PRs can an engineer review thoroughly in a day while also being able to progress their own tasks? That’s a hard question to answer.

Not all PRs are equal of course. Some bigger than others. Some more dangerous than others.

A large mechanical change can be straightforward. A tiny change to a data model might deserve a long conversation.

So we’re not looking for a number here.

The useful question I think is: “can a reviewer trace the important decisions and failure cases in a reasonable timeframe given to review a given PR?”. If not, the PR needs to split into smaller ones.

As managers, if we only praise whose PR throughput is high and barely notice how much time is spent in PR reviews, we’re missing an important metric to monitor.

Try this

Experiment with this to get a sense yourself. When you see a big feature getting close to being delivered and PRs being up for review for it, ask the owner:

1. What decisions were made that will be hard to undo? (we love two-way doors, one-way doors need to be conscious)

2. What are assumptions made / behaviour we’re relying on? including where it might fail and what will be the outcome

3. What’s the part you’d like most a reviewer to challenge? and why?

This will quickly surface whether the author understands the changes they’re proposing and whether a reviewer has a realistic chance of properly reviewing it.

Agents have taken away a lot of the effort of producing code which is great, but I also think that a lot of the thinking used to happen during that effort too. I strongly believe that we need to make room for it and not just let it slip away.

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 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 mid level engineer is working on a big feature.

They bring an ADR to present to the team. It looks to be well thought out and they spent quite a bit of time researching all different angles.

During the architecture review session, your senior engineer immediately spots flaws and reasons why it wouldn’t work. So in order to save the team some time, they raise them immediately and essentially send the mid level engineer back to the drawing board.

After some collaboration between the two, they agree on the design.

But you sense your mid level engineer has lost some motivation and excitement.

It’s likely tied to the fact the senior kinda shut their idea down. Of course, you want your experienced engineer to raise concerns, but you also want to hear people’s reasoning before these concerns are raised.

It can be tricky giving this feedback though. I can already hear their point: “Would you rather I let the team make a bad decision?”. The answer is no!

You need their judgment to steer the team, and you also need other people to keep using theirs.

Get specific

You need to do this for constructive feedback. Especially when it’s a bit nuanced like in this scenario.

Was it the interruption that caused the issue? Dismissing someone else’s ideas? Doing so without fully understanding them?

You want to nail the exact thing.

You also want to think about how the conversation is likely to unravel. Will they kick off? Are they argumentative? What is their point of view?

If people are being impacted by one person’s behaviour you need to get to the bottom of it ASAP.

Ultimately the message you want to portray is that they need to give people a chance to finish sharing their thoughts and fully understand an idea before judging it.

In the next sections I am sharing:

• the exact conversation I’d have in the 1:1

• what I’d say if the engineer pushes back

• what I’d do after that conversation

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 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.

You see a PR authored by your PM.. It’s 700 LOC and touching on 3 services. They picked up one of the customer complains and thought they could fix it by just clauding their way into a solution.

Now, someone from your team needs to review it and decide whether it’s safe to merge.. and deploy it? but what if something’s wrong with it? would whoever approves it now be responsible for fixing that?

At Shopify, the company’s internal AI agent, River, exists in Slack, and employees ask it to read code, write code, open pull requests, and query production data. It’s super popular as well! In a recent month 5,938 people used it across 4,450 channels.

About one in eight merged pull requests in Shopify’s main codebase started that way.

Shopify CEO gave that pattern a name

Tobias Lütke calls this a “slop grenade”.

Someone generates something with AI, definitely doesn’t understand it, bearly reads it, and passes it on to a colleague. The time they saved becomes someone else’s work.

When someone that deep into AI-assisted development says AI-generated output that is not well understood is a problem, it’s probably something worth paying attention to.

The problem isn’t the output

A “slop grenade” doesn’t only mean bad AI-generated code.

It’s code that someone created, didn’t properly understand it and then handed to a reviewer to deal with.

If the person who submitted it can’t fully explain the decisions behind it - there’s a real problem.

When that happens, the reviewer needs to do much more than reviewing the code. They have to work out what parts can be trusted in the PR (AI can sound very convincing even when it’s wrong) and potentially also teach the author what their own code does.

Sounds to me like a complete recipe for disaster.

This doesn’t only happen with code

Pull requests and code are only very obvious examples.

The same thing happens when someone generates any type of document really - like an ADR, an RFC, an incident report, meeting notes, acceptance criteria, Slack summaries, a performance review.

In each of these, creating the artefact became easier than it used to be. Reviewing them became harder because reviewers have to decide whether any of it is actual thinking from the author now.

Own it fully!!!!

If you own an artefact, you’re responsible for what it says, whether you wrote all of it yourself or not.

Before you open up a PR (or any document that needs a review) you should understand it well enough to stand behind what’s in it.

If someone questions any part in it, you should be able to explain why you made that decision. You can’t say “AI suggested doing that”.

If there’s a mistake, it’s yours to own and correct. And if you don’t understand part of what your AI produced, the work isn’t ready to be shared with others yet.

Attention is a scarce resource

AI made it much easier to create things. It didn’t make it easier to decide whether those things are of high quality, correct, or ok to ship.

That attention was always limited. The amount of work waiting to be reviewed though, now is growing much faster than the number of people available to review it.

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 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.

Your team metrics might be looking great. Compared to previous periods you see more code being shipped, faster time to first PR review, faster PR cycle time, and less incidents. Every metric you were told to watch is moving in the right direction.

Now, have a look at your roadmap… The features your team was supposed to deliver this quarter are landing on roughly the same schedule they always did.

What’s going on? Surely all the metrics you see should be moving the needle on your deliver somehow!

The individual productivity gains

Mert Demirer, Leon Musolff, and Liyuan Yang looked at GitHub activity against AI-usage telemetry for more than 500,000 developers, tracking three generations of tools:

• autocomplete

• interactive coding agents

• autonomous coding agents

Their NBER paper found that developers using all three generations of AI coding tools produced 240% more commits.

But the increase was much smaller further along the development process: they worked on 80% more projects and produced only 30% more releases.

Researchers call this a weak-link problem. AI speeds up one stage that was not the constraint, and leaves every human-dependent stage (reviews, integration, release) taking just as long as they did.

Microsoft found the same thing.. Sudhakar Sadasivuni, a principal group engineering manager at Microsoft, said: “We quickly identified that improving the individual productivity of a developer was not resulting in a boost to team productivity. That was our hard lesson.”

A separate analysis of 623 million code changes, from GitClear, points at the same gap. As AI-generated code volume rose, cross-file reuse and refactoring fell, and long-term maintenance work dropped by nearly three-quarters compared to 2022 levels.

This is not really a surprise

I’ve made a version of this argument before about performance reviews: the team is the only honest unit you can measure, because individual numbers can move in the opposite direction from what the team delivers. Obviously metrics like counting PRs, or commits fall into the same trap.

SDLC still has to move through several stages: planning, coding, review, integration and release. Making one stage faster doesn’t automatically speed up the rest.

If your review stage was already the slowest stage, AI actually may make the problem worse. More code is now arriving, but the team’s capacity to review it hasn’t changed.

The good news is that you can find and fix these bottlenecks.

Since writing code is no longer the slowest part for most, what is? Here’s how to find out, and what to do about it:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 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.

Resignations seem to arrive very often in the same way.

The person leaving is usually still doing well, has strong feedback from peers, and they might even be working on one of the hardest things the team is doing.

Nothing really suggests there’s a problem.

Then they tell (or slack) you: “Can we have a quick chat today?”

And you know already that doesn’t sound good and what follow is that they’re exhausted, or that they’re leaving.

And this isn’t that unusual.

One study of 1,085 US employees found that 18.8% were highly engaged and highly burned out at the same time. And that group was the most likely to want to leave.

Their output won’t tell you

This is the first mistake I think managers make.

We wait for performance to drop.

I stumbled on this term performance protection from psychologist Robert Hockey from 1997.

It basically means, under enough pressure, people protect the main task by putting more effort into it.

For an engineer, the main task might be shipping the feature they’re working on, and they can keep doing that for quite a while without showing signs of burnout.

The SPACE framework authors noticed something similar with remote work. Some productivity measures, including commits and speed to merge PRs, actually increased while some developers were approaching burnout.

Even DORA says their metrics can’t tell you whether low deployment frequency comes from technical debt, bureaucracy or burnout.

So, even when some output related metrics change, you still don’t really know what they mean. By the time the obvious performance drop comes, you are probably already quite late.

It’s not just being tired

We talk about burnout like someone has a battery.

Working too much drains it, whereas holidays recharges it.

One study followed 3,209 Swedish workers over six years. Initially, things like high workload, low control and low reward were all linked to burnout.

But two years later, only low reward was the condition that remained linked.

I wouldn’t read too much into one study, but it points at something I think managers often miss.

People can work really hard when they feel trusted, appreciated and like their work actually matters.

The same amount of work feels very different when none of those things are true.

Sometimes the problem isn’t how much you’re asking someone to do.

It’s what they feel they’re getting back.

You might find out immediately

I used to think people hid burnout because they were scared to tell their manager.

Apparently, not necessarily.

A Dutch study of 332 workers found 73.2% had told their manager about a mental health issue. From those who didn’t, the most common reason was simply wanting to handle it themselves.

And I think this is particularly easy to miss with engineers.

They’re used to figuring things out themselves.

Time off helps but doesn’t fix this.

A 2023 meta-analysis of 13 vacation studies found well-being improves after taking time off.

But the improvement was basically gone after the first week of being back at work.

Another study I found tracking burnout reported people back around baseline within four weeks.

Obviously holidays are not useless.

Leiter and Maslach have a great analogy:

“when the canary keels over, we acknowledge that the environment is hazardous — we don’t tell the canary that it should take a long weekend.”

I think we as managers need to keep that in mind.

Look beyond their output

Leaddev surveyed 617 engineering leaders last year.

Only 21% described themselves as healthy. 22% said they were critically burned out.

And there’s a line from Dominika Rogala’s presentation at LDX3 that has stayed with me:

“Burnout isn’t an individual failure. It’s a system problem.”

So don’t wait for your engineers to suddenly start missing deadlines. That might happen eventually. But the earlier signs might have nothing to do with their output.

A good opening to this conversation to ask in your next one-on-one:

What have you stopped doing over the last three months that you used to enjoy?

And give them some time to actually think about it.

See you in the next one,
~ Stephane

Subscribe now

Paid subscribers get 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 know has not written actual code in a few years.

Recently, over a weekend he built an internal service-health dashboard with the help of AI, which he demoed to his team on Monday.

It just so happened, that this was the third system in that organisation solving the same problem. Plus, nobody in the team had seen the code for it or was asked what was wrong with the tools they already had.

The team said it looked good, so they inherited it.

I don’t want to talk about “should managers code?”

This is not what this post is about. I’ve written about it before.

The issue here isn’t that a manager wrote some code, or created a new service.. it’s that a consequential decision about the team’s systems was made, and the team was not consulted.

This has been measured

There’s no peer-reviewed research on managers using AI to bypass their teams’ judgement. And I haven’t found a survey that measures this consultation step either.

But in IEEE Transactions on Software Engineering this year, Salomon and colleagues found that 51% of developers now ask AI for help they would previously have asked a teammate for.

6 out of 10 said that’s because there’s no fear of looking stupid when using AI. (I wrote about that research here: 51% of devs stopped asking their teammates.)

I think something similar now is happening with managers. And the cost of that is much higher than when it happens to engineers.

“AI exposes bad managers”

That’s the cliché everyone says. I don’t think it’s quite right though.

Building software used to have a pretty meaningful cost.

If you hadn’t coded in years, building something as simple as an internal tool might have meant:

• learning some new frameworks

• spending a few weekends on it

• researching and talking to people about how to deploy it

At some point you’d probably have asked the team for help.

There’s an old economics idea that an effort cost acts as a sorting mechanism: some things simply aren’t worth doing once you have to pay the cost.

AI has massively reduced that cost.

So I’m not sure AI exposes bad managers.

I think it removes some of the constraints that used to stop managers from doing certain things in the first place.

You could always build something without talking to your team. It was just expensive enough that, somewhere along the way, you probably had to involve them.

Now you can do it over a weekend.

It’s easier to just do it yourself

The temptation is to just do it yourself.

Talking to five people about a problem takes time. You need to explain it, hear different opinions, probably have a few meetings, then agree what to do.

Pointing an agent to a few repos, asking it to do so research and to build something can take an afternoon.

And, to be fair, it feels really good.

It can bring back that dopamine high of seeing something from nothing come to life again. You can have an idea in the morning and in the evening have something that looks like it works.

I think the problem is that there’s a pretty big difference between showing your team an idea and showing them something you’ve built.

Your role is still being people’s manager.

Camille Fournier has a quote I keep top of mind:

“The more senior you become, the harder it is for people to feel comfortable disagreeing with you openly.”

Now imagine disagreeing when your manager hasn’t brought you an idea, but a working new system.

That’s a much harder thing to say no to.

Your team has to maintain it

There’s also what happens after you build the thing.

Bird and colleagues studied ownership and defects across Windows Vista and Windows 7 in Don’t touch my code!.

One of their conclusions was that changes made by people with limited experience in that part of the codebase deserved more attention.

Which I think is a pretty good description of the manager in my opening story (and for many managers generally to be honest).

The problem is not that the thing you built might have a bug to be resolved, it’s that in some time that dashboard might become important enough that people use it and other things depend on it BUT the manager who built it has moved onto other things.

Who’s responsible for maintaining it? The team.

And now, they own something they never really chose to build (or where involved in how to build it).

The question isn’t whether managers should be allowed to build things. Of course they should.

But if you’re going to build something your team will eventually own, I think there are a few things you need to ask yourself first.

For me, there are six.

The six questions

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 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 was asked to estimate how long a project would take.

He talked to some engineers and figured Team A would need to do 3-4 weeks worth of work. Then he talked to the rest of the teams that were involved. 4 weeks for Team B, 4 weeks for Team C, 4 weeks for Team D, and 4 weeks for team E.

20 weeks in total.

The thing is… all teams needed to make the same changes to the same API!! Three or four weeks of work in total.

Dave Anderson, who ran engineering at Amazon, tells this story about a manager he calls Lawrence.

Lawrence had inflated his headcount ask by roughly 5x and had no idea.

“Lawrence was never on top of the details. He delegated all technical decisions to his team, to the point that he didn’t understand the critical decisions he was approving.”

How technical is technical enough?

This question is a bit tricky.. The problem is that “technical” means absolutely everything and nothing.

Will Larson makes this point:

“’Being technical’ has lost whatever definition it once had and has completed its devolution from demarcation to slur.”

There’s something to that.

What’s the last time you thought someone wasn’t “technical enough”? What is it exactly that they couldn’t do?

• Understand the system architecture?

• Challenge an estimate?

• Help during an incident?

• Have a healthy debate in an architecture review?

The research is a bit confusing

Google’s Project Oxygen looked at what separated their highest-rated managers and technical skills came last out of eight areas.

Laszlo Bock, who was running People Operations, said:

“It turns out that that’s absolutely the least important thing.”

Then you have research from Artz, Goodall and Oswald which found that a boss’s technical competence was the strongest predictor of worker job satisfaction.

So... which one is it? I think probably both can be true.

Google was comparing managers inside Google, where people have a pretty high technical bar. Technical ability wasn’t necessarily what differentiated the best managers because most engineers already had that.

Also.. “least important of eight things that correlate with being great” isn’t quite the same as “unimportant”.

You should certainly NOT be the best engineer

You’re not there to make every architectural decision. If you’re constantly making those yourself, you’re also taking opportunities away from the senior engineers in your team.

Sean Goedecke says:

“I have never once wished that my manager was picking up tickets and shipping code alongside me.”

You absolutely don’t need to know more than your engineers. In fact, you only need enough understanding to know when something doesn’t quite add up.

There is more pressure for managers to be hands-on though. LeadDev’s Engineering Leadership Report 2026 found that 37% of engineering leaders are doing more hands-on technical work.

It also expires

Being great on the technical side five years ago doesn’t automatically make you technical enough today.

There’s a deterioration at roughly 3-5 years.

Maybe we should not really be asking “How technical should I be?”, but instead:

When was I last close enough to the work to catch something?

If you can’t remember... maybe you want to give give this area some attention.

The good thing is that fixing it doesn’t mean learning another programming language or spending your weekends doing LeetCode.

I use a much simpler test.

The test

For me, the bar is roughly this:

👇👇👇 (access with a paid subscription)

Read more

Subscribe now

Paid subscribers get 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 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 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 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 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 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 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 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 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