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

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 leaves a careful comment on a pull request explaining why the approach taken will not work. It is clear the reviewer has put in real time making their comment clear and kind.

2 minutes later, a reply: “Great catch! You’re totally right!”

Obviously no time spent grasping what was written in the first place. You can tell, because the next thing the author pushes ignores everything that you discussed in the standup.

AI slop everywhere

Most of the worry about AI is for AI code slop. The vibe-coded mess, the duplicated blocks, the bug nobody can explain. All these of course exist, and I’ve written about shipping faster while understanding less.

But the thing that’s starting to corrode teams isn’t in the codebase... it’s in the slack threads, in the PR comments.

I keep seeing engineers reply to each other through AI. PR comments written by an agent. Slack answers piped through a model. A thoughtful question met with a wall of generated text that sounds right and says nothing.

I really think that replying to coworkers with AI is a line that we shouldn’t cross. Our artefacts can be AI-assisted, but our interactions with humans should remain human.

Many agree with me that it’s even disrespectful to reply to a human with AI but there’s somewhat of a fear about saying it.

Which means on most teams, the person whose job it is to name this is you.

It’s corrosive, not just rude

“It’s rude” isn’t enough to act on.

Communication used to be symmetric. It cost me effort to write you a real answer, and it cost you effort to read it. That rough balance is what made the exchange worth something to both of us.

AI broke the symmetry. Now someone generates a three-paragraph reply in three seconds, and it costs you ten minutes to read it, check it, and figure out which parts to keep.

There’s a name for this. Alberto Brandolini called it the bullshit asymmetry principle back in 2013: the energy needed to refute something is an order of magnitude bigger than the energy needed to produce it.

The Stack Overflow 2025 survey found that 66% of developers say their single biggest frustration with AI is answers that are “almost right, but not quite.” That’s the expensive kind of wrong. You can’t skim it. You have to sit there and verify every line, because the one that’s off looks exactly like the four that aren’t.

So every AI-mediated reply is a transfer. The sender saves three seconds. The receiver pays for it. Multiply that across a team and you’ve built a machine that manufactures work while looking productive.

At the end of the day, I don’t give a shit what claude says. I am working with you, and I want to be having discussions with you, the human, not your AI (however well you’ve managed to calibrate it).

Trust breaks instantly

Teams run on reciprocity. The sociologist Alvin Gouldner described it as one of the most universal moral norms we have: you return effort and good faith in kind. When I bring you my real thinking and you hand me a machine’s output, you haven’t just been lazy. You’ve broken the norm the relationship was standing on. That’s why it stings in a way a short or blunt reply never did.

And it’s measurable too. A 2025 study in the International Journal of Business Communication tested how people perceive AI-assisted workplace messages. When a message was heavily AI-assisted, the share of people who rated the sender as sincere dropped from 83% to somewhere between 40 and 52%. Perceived professionalism fell from 95% to around 70%. The polish doesn’t buy you credibility. It costs you credibility, the moment people sense it.

This is the same dynamic I wrote about in the message in your team’s over-communication. A three-paragraph answer to a simple question used to tell you something about trust and anxiety. Now you can’t even read the signal, because you can’t tell if it’s a person being defensive or an agent padding for length.

It also breaks the thing Google found mattered most. Their Project Aristotle research ranked psychological safety as the number one factor in effective teams, ahead of everything else. Safety depends on knowing you’re dealing with a real person and their real judgment.

I wrote before that AI is breaking how your team builds trust. This is the channel-level version. One issue is people asking AI instead of asking each other. This is the mirror image: people answering each other with AI instead of actually answering. The conversation hollows out from both ends, and eventually you’ve got agents posting reviews on agents’ pull requests within seconds, with the humans cc’d on a discussion none of them are having.

So what do you actually do about it, without turning into the manager who bans a useful tool?

Here’s the line my thinking lands on, and the four rules that keep the human parts human:

Read more

Subscribe now

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

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

A hiring manager friend of mine asked me a question this week that I haven’t been able to stop thinking about.

“What characteristics have been the strongest predictors of success in your best hires?”

As he was preparing this period for mid-year review discussions, he realised that one of his best performers didn’t do well during their interview. In fact, they absolutely bombed it. The kind of bombing where, if three other strong candidates had been in the pipeline that week, this person would never get an offer. They got hired on a coin-flip of a hiring committee, and then turned into the best hire they had ever made.

How is that even possible?

So, I decided to retrospect in my own hiring journey and reflect on what my great hires have had in common. Two things keep coming to mind:

• Low ego, but confident - happy to flag a problem or push back, never defensive when challenged

• Fast self-learners - they picked things up without hand-holding

The question I got is the whole issue. Because once you start pulling on it, you might find something uncomfortable.

The traits that predict your best hires are being punished?

Here’s the position I’ll defend for the rest of this issue: the traits that correlate with your best hires are, structurally, the traits a normal interview filters out.

A standard interview rewards the person who performs well under observation, with a stranger watching, on a clock. That is a real skill. It is also almost completely unrelated to the four traits that actually predict who thrives on your team a year later.

I went and pulled the research, then matched it against the patterns that hiring managers keep reporting. Four traits came up again and again. Each one predicts performance. Each one has a failure mode that makes it read as a weakness in an interview room.

Here are the four:

• Low ego, but confident. Can read as “underwhelming”.

• Fast self-learner, genuinely curious. Outperformed by pedigree and years of experience, which barely predict anything.

• Clear communicator, even when blunt. Loses to candidates who are polished and charismatic but vague.

• Owns their mistakes. Loses to candidates who spin, or who pick a safe, trivial “mistake” and never get challenged on it.

Look at that list and the problem jumps out. The thing that makes each trait valuable on the job is the same thing that makes it invisible, or even negative, in an interview.

The interview is measuring the wrong thing, and we have the data

Before I break down the four traits, I want to convince you that the interview itself is the unreliable instrument here. Because if you don’t believe that, none of the rest lands.

Start with the most damning study. Researchers at NC State and Microsoft ran a controlled experiment on technical interviews. Same problems, two conditions: some engineers solved them on a whiteboard with someone watching and talking, others solved them privately. The watched group scored roughly half as well. Same people, same difficulty. The whiteboard wasn’t measuring their engineering. It was measuring how they hold up with a stranger staring at them, which is a different trait, and not the one you’re hiring for. It also filters out capable introverts.

Then there’s the consistency problem. The team at interviewing.io ran thousands of standardized mock interviews and found the same engineer scores wildly differently from one interview to the next. If your signal swings that much on the same person, you’re not reading a property of the candidate. You’re reading noise.

And the self-assessment data is the part that stings. In that same interviewing.io research, impostor syndrome showed up about twice as often as overconfidence, and the people who underrated themselves were more likely to drop out of the process entirely. Read that again with trait number one in mind. The low-ego, confident engineer (the profile this whole issue is about) is statistically more likely to count themselves out before you even decide.

None of this is new to the people who study hiring. Laszlo Bock, who ran People Operations at Google, has said: “We found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.”

I’ll grant the obvious counterpoint so you don’t have to email it to me: some environments genuinely do reward big egos. Fair. But “thrives in a political knife-fight” is a different hire than “makes your team better”, and most of us are hiring for the second one.

I’ve made the broader version of this argument before, in why your interview process for senior engineers is wrong and in stop interviewing engineers like it’s 2022. This issue is the practical version: the four traits, and how to actually screen for each.

Let me give you the first one in full, then the test that surfaces it.

Trait 1: Low ego, but confident

The trait. Not meek. Not arrogant. The specific combination of someone who will say “I think this design is wrong, and here’s why”, and in the next breath, “oh, you’re right, I hadn’t thought of that”. They hold a position and they update on evidence. Both.

Bradley Owens’ studies on what he calls “expressed humility” found that it predicted job performance above general mental ability and conscientiousness, and that it could even compensate for lower raw intelligence. A 2022 meta-analysis across more than 16,000 people tied humble leadership to higher task performance, more creativity, and more people speaking up. It named “intellectual humility” as one of the things Google actually hired for.

The failure mode in interviews. Candidates will undercount their own contribution, say “the team did it” when it was mostly them, and answer “I don’t know” without flinching. Next to a candidate who narrates every achievement in confident paragraphs, they read as junior, or unsure, or “not leadership material”. They might not be none of those things.

The test. Challenge a real decision they made. Pick something they described, push back on it, and watch which way they go. The arrogant candidate defends their ego. The meek candidate caves instantly. The hire you want does neither - they engage with the actual argument, concede the parts that are right, and hold the parts that aren’t. You’re not testing whether they’re correct. You’re testing what they do when someone smart disagrees with them, because that’s a thing they’ll do every week on your team.

Here’s the test for the other three, and how to assess each one:

Read more

Subscribe now

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

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

Last week I saw a post on Reddit from a Tech Lead who was very concerned.

He’s been working at his company for eight years and doing pretty damn well. Two of them as a tech lead for a small team of juniors. Then his company decided to move him to a different team that was more complex and only had senior engineers.

His expectations remained the same in principle, leading the team - but he was freaking out.

“I have never led senior developers before, so I am going crazy thinking about how I am supposed to lead a team that knows more than me.”

That initial panic is natural and makes sense. But when you realise that a leader’s job is not to be the most knowledgeable person in the team, then the feelings of panic start to dissipate.

On a team of juniors, you can lead effectively by knowing more and teaching it. On a team of seniors, it’s exactly backwards. Leading seniors is actually lighter work than leading juniors.

Leading seniors is a subtraction game

For most of your career, your value was what you added. Your code, your answers, your knowledge of the system. Promotion to lead a junior team rewarded the same thing: you were the person who could unblock anyone because you knew the most.

A team of seniors has different demands. They already know more than you about their corner of the system. If your value is the technical knowledge you add, you have almost nothing to offer on the thing you used to be measured on.

So stop trying to add. Start subtracting.

I love these quotes:

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” ~ Patton

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” ~ Steve Jobs

Your job is not to be the smartest. Your job is to clear the path so the smart people you’ve got can operate effectively.

Your output stops being measured in things produced and starts being measured in things removed.

The cost of adding yourself

Subtraction isn’t a soft, feel-good idea. The thing you’re removing has a price tag.

Gloria Mark’s work at UC Irvine put a number on interruption: after you’re pulled off a task, it takes an average of 23 minutes and 15 seconds to get fully back into it. Now multiply that by a team of senior engineers doing the most cognitively demanding work in your org. Every “quick question”, every status meeting you didn’t need to schedule, is a 23-minute tax on your most expensive people.

Microsoft’s Work Trend Index found weekly meeting time up 153% since 2020, with most knowledge workers reporting they don’t have enough uninterrupted focus time.

70% of the variance in team engagement comes from the manager. You are the single biggest variable in whether your team does its best work or not because you control how much friction reaches them.

The three things worth removing

If your value is subtraction, what exactly are you subtracting? Three things, in order of how much they cost the team.

One: ambiguity. Seniors don’t need you to tell them how to build. They need you to tell them what’s worth building and why. That means turning a vague leadership ask into a crisp problem statement, killing the three competing priorities so one survives, and saying what the team is not doing this quarter. The skill here is making the implicit explicit. This is the work behind the question no one on your team will ask - usually because asking it has been made too expensive.

Two: politics. The instinct is to be a shield: absorb all the organizational nonsense so the team never sees it. Jade Rubick has a warning about that in his “shit shield” piece - pure shielding turns you into a bottleneck and infantilizes senior people who are perfectly capable of navigating the org themselves. You don’t have to absorb politics. You need to translate it. Make the organizational friction visible and navigable, decide which parts the team genuinely shouldn’t spend attention on, and hand them a clear map of the rest. When a senior stakeholder keeps bypassing you to go straight to your engineers, or your PM keeps overcommitting on the team’s behalf, translation is what protects them without making them dependent on you.

Three: your own “how”. You see a senior making a technical call you’d have made differently, and every instinct tell you to step in. Don’t reach for the “how”. This is also where I’ll disagree with the people who say technical credibility doesn’t matter at all. Charity Majors is right that the best engineering leaders stay close to the work - you do need enough technical depth to follow the conversation. But you spend that depth on framing the problem, not dictating the solution. Will Larson’s rule for staff-plus engineers is the one to steal: hand them the problem space, not the answer. The military calls it commander’s intent - the leader owns the what and the why, the people executing own the how. Netflix calls it “context, not control”. On a senior team it’s the only thing that works.

The moment you reach for the “how” with a senior, you break the exact thing you hired them for. I went deep on that failure mode in you hired senior engineers to think, but you keep telling them what to do. And because every senior needs a different amount of context, treating them all the same is not fair - calibrate per person.

So what do you actually do?

Knowing what to subtract is the easy part. Doing it in a brand-new team, in your first 90 days, without either overstepping or disappearing, is the hard part.

So I built a week-by-week plan for the first 90 days that’s built entirely around removing friction, earning trust, and installing an operating rhythm a senior team will actually find valuable.

Here’s the first-90-days subtraction playbook, week by week:

Read more

Subscribe now

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

A few weeks ago I looked at my team’s slack channel and realized how quiet it had gotten.

Not quiet in a bad way. No one was stuck, no one was waiting for someone senior to free up to help them. The work was moving. But the steady trickle of “quick question, how do we…” messages that used to fill that channel had mostly dried up, and I knew exactly where it had gone. People were asking AI.

For most of my career, the reason someone interrupts you during the day is knowledge. They’re stuck, you’re the fastest path to unstuck, so they ping you. That interruption has a real cost. It breaks your flow, and it takes a long stretch to rebuild your mental context after you’ve been pulled out of it. We’ve always lived with that cost because the alternative was someone sitting blocked.

AI is changing that. A tool that explains an API, debugs a stack trace, or sketches an approach on demand is a new place to take the questions that used to go to a person. So they go there.

No wonder people asking AI than their teammates

I wrote before about how AI is breaking the way your team builds trust - senior engineers used to earn influence by being the person everyone came to, and that’s eroding. This is the wider version of the same story. The whole shape of how your team members talk to each other is changing.

A new study offers some numbers on it. In From Disruptions to Discussions (IEEE Transactions on Software Engineering, 2026), researchers from UBC and the University of Zurich ran a two-phase study: they followed 30 developers in their real work for up to twelve days, then surveyed 131 more.

Half of those surveyed developers (51%) said they now ask AI for technical help they’d previously have asked a teammate for. More than six in ten said it was easier to ask the AI, because there’s no fear of looking stupid in front of a colleague.

Half the team rerouted their questions — and told researchers it’s because asking a machine beats the risk of looking stupid in front of you.

Amy Edmondson’s work on psychological safety showed that whether people feel safe to ask a question or admit they don’t know something is one of the strongest predictors of whether a team learns. AI is a judgment-free mentor. It never sighs, never makes you feel stupid, never remembers that you asked the same thing last week. No wonder people prefer it for the questions that carry a little shame.

A clean division of labor has appeared

The study found the conversations didn’t vanish. They changed purpose.

Developers took their technical and planning work to the AI: how to implement a feature, how to break down a task, brainstorm options. They kept going to humans for the things the AI can’t know: how the business logic works, what the requirements mean, how something was done here before and why.

So the human conversations that survive are the high-context ones. Clarifying a fuzzy requirement. Reasoning through a decision together. Weighing two approaches when there’s no clean answer. On paper, that’s a great trade. The routine stuff goes to the tool, and people spend their scarce attention on judgment.

The interruptions you’re glad to lose were doing invisible work

Every vendor selling you an AI tool frames the drop in “quick question” pings as a pure win. Fewer interruptions, more flow, faster shipping. The study saw some of that too, though it was uneven - only when AI was deeply embedded in the workflow did teams reliably report fewer interruptions.

But a “quick question” was never only an interruption. It was the delivery mechanism for things that don’t have their own meeting.

When a junior pinged a senior to ask why the retry logic was written that way, they got an answer - and they also got the reasoning, a war story about the outage that caused it, and thirty seconds of relationship. The senior got a signal about where the junior’s understanding had gaps. Both of them got a small reminder that the other person exists. None of that was on the calendar. Space was created for these things off the back of a routine question.

Take the routine question away and you remove the mentorship, the context transfer, the trust, the plain human contact.

You already watched this happen in public

If you want to know where this goes, look at Stack Overflow.

New question volume there is down roughly 76% since ChatGPT launched. (The decline actually started before ChatGPT, around 2021 - AI poured fuel on a fire that was already lit.) The routine programming question migrated from a public human forum to a private AI chat, at scale, in about two years. That migration is basically complete.

Stack Overflow got a public graph of its own collapse. The same migration inside your team leaves no chart at all.

The same migration is happening inside your team right now, in your own team’s slack channel and your own DMs. The difference is that Stack Overflow could see it - they have dashboards, traffic graphs, a public number. You don’t. Your internal Q&A is having its own silent collapse and there is no chart that shows it to you.

The risk is that a load-bearing part of how your team learned and bonded is disappearing, and the disappearance is invisible by default.

The AI gives one answer. A team gives you several.

There’s one more thing the developers in the study kept wanting humans for.

The AI hands back a single, confident, consolidated answer. A colleague gives you a different answer than the colleague next to them, and the disagreement is the point. The friction between two senior engineers who see a problem differently is where the good decision usually comes from. A model that smooths everything into one tidy response removes that friction.

This is why none of this means “AI is making teams worse”. AI is an amplifier. It magnifies what’s already there - a team with strong habits around context, mentorship, and healthy disagreement gets sharper, a team that was already running on shallow understanding and isolated work gets more shallow and more isolated, faster.

Which one you get is not up to the tool. It’s up to you.

So the job changes. The routine Q&A is gone to the machine and it’s not coming back. What’s left for you to manage is the human layer the questions used to carry for free - and now you have to carry it on purpose.

Here’s how I’m doing that with my team, broken into the four steps:

Read more

Subscribe now

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

Two engineers I know tried the same AI coding tool the same month. Same model, same version, same company even.

One of them told me it pretty much one-shotted her feature. The other told me it was overhyped garbage that kept wrecking his codebase and he’d gone back to writing his feature by hand.

I believed both of them. Because the tool was never the variable.

The first engineer had spent a weekend setting it up - a context file at the root of the repo, a few notes per service about how that part of the system worked, the test command scoped so the agent didn’t run the whole suite on every change. The second one had installed it, pointed it at a million-line monorepo, and asked it to “fix the auth bug”. They were bound to get different results.

That gap is the whole story of AI coding right now. And most engineering managers are looking at the wrong half of it.

The model is not the thing you’re buying

When I built a SaaS with Claude Code, the lesson that stuck with me had nothing to do with how smart the model I was using was. It was how much the result depended on everything around the model - the context I gave it, the way I’d structured the work, the guardrails I set.

There’s a name for this now. Martin Fowler’s team at Thoughtworks calls it harness engineering: the idea that the scaffolding around a coding agent - the context files, the tooling, the way it searches and tests - shapes its output as much as the model itself. Anthropic makes the same point in their own writing on working in large codebases, where they say that the harness matters as much as the model.

That should change how you think.

Your team is going to judge these tools the way the second engineer did. They’ll try them on a real task, in a real codebase, with minimal setup. It’ll produce something mediocre at best. They’ll conclude the tool is overhyped and might stop using it if they were sceptical to begin with. The verdict will feel like it’s about the model. It will actually be about the absence of a harness.

The data backs this up from the other direction. The METR study found experienced developers were about 19% slower using AI on their own mature codebases - while believing they were 20% faster. The 2025 DORA report found AI amplifies whatever your team already is: it speeds up a healthy system and speeds up a broken one. In both cases the model wasn’t the deciding factor. The setup around it was.

That makes it your job, not your platform team’s

If the harness is what determines the result, then the harness needs an owner. And on most teams, nobody owns it.

Addy Osmani, who leads engineering on Chrome at Google, wrote a piece with a title that should be on a poster in every EM’s head: “Your AI coding agents need a manager”. His argument is that AI coding at scale stops being a prompting problem and becomes a management problem. The skills that make someone a good tech lead - setting context, defining the work clearly, reviewing output, knowing when to step in - are exactly the skills that make AI coding work.

The thing standing between your team and real gains from these tools is not a better model. It’s a management responsibility that currently has no owner on your team.

The instinct, when something needs adopting, is to mandate it. LeadDev did a whole piece on how AI coding mandates are driving developers to the brink. Push hard enough and you won’t get adoption - you’ll get resentment.

Owning the harness means someone makes the setup good enough that using the tool is the path of least resistance.

What good setup is actually protecting you from

This is the part that turns it from a tooling chore into a real management priority. Better code out of the agent is the obvious payoff. The bigger one is that the harness is your first line of defense against the three problems AI creates on a team.

Review capacity. This is the big one. When writing code gets cheap, reviewing it doesn’t. Faros AI looked at data from more than 10,000 developers and found that after AI adoption, pull request volume nearly doubled and review time climbed by 91%. I wrote before about how fast PRs can hide shallow understanding - AI pours fuel on exactly that fire. A senior engineer cannot meaningfully review a thousand lines that took five minutes to generate. The bottleneck has moved from coding to reviews from your most experienced people, and they’re the ones you can least afford to burn out.

Your juniors. AI is very good at the small, well-defined tickets that used to be how junior engineers learned the system. If the agent eats those, what’s left for a junior to grow on? This is a real problem, and good setup is part of the answer - the harness can be tuned to leave room for people to learn, not just to ship.

Trust. The Stack Overflow developer survey found that while 84% of developers now use AI tools, but trust in their accuracy fell to 29%. Two-thirds say the answers are “almost right, but not quite” - which is the most expensive kind of wrong, because it costs time to find. I’ve written about how AI is changing the way teams build trust. The harness is where you decide what the tool is allowed to do unsupervised and what it isn’t.

None of these three problems will magically get solved by a smarter model. All three are shaped by whether someone owns the setup.

And here’s the cost of not owning it. The team that skips the harness doesn’t get the upside of AI and avoid the downside. They get the worst of both worlds: more code than before, less understanding than before, seniors drowning in reviews, juniors with nothing to learn on, and a tool everyone blames for the mess.

The teams that own the harness get the opposite. The agent does the work that should be cheap, the humans spend their attention on the work that shouldn’t be, and the setup is what draws that line.

The question is who on your team owns the harness, what good setup actually looks like, and how you roll it out.

Here’s the playbook I’d use, the setup I’d own, and who I’d put in charge of it:

The playbook

Below is what “owning the harness” actually means in practice - the four layers of setup that matter, who owns them, the maintenance cadence it needs, and the how to roll it out without getting resentment back.

Read more

Subscribe now

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

I’ve been to a lot of tech conferences. Most of them you leave with a bag of stickers and a mild sense of time wasted. LDX3 is different, and after two days at the O2 last week I remembered why – it’s one of the few events where the corridor conversations between talks are as good as the talks themselves.

This year had 2,800 attendees. I went to as many sessions as I could fit across both days, took notes throughout, and had conversations with a lot of people who are dealing with the same problems I am. What follows is the signal I’m taking back - not a session-by-session breakdown, but the themes that kept surfacing across different speakers from different companies. When something comes up five times in two days from people who don’t know each other, it’s worth paying attention to.

The engineering manager role is being squeezed

I have been already feeling what Scott Carey’s talk on day two was about to describe. Carey is editor in chief at LeadDev, and he opened with data that landed hard:

• engineering management scope is increasing

• direct report counts are going up

• working hours are longer

• one in three managers are actively considering going back to individual contributor work

The driver, he argued, isn’t only AI. Budget that previously funded headcount is now going to GPUs. The same manager is covering more with fewer people under them. He named the result: the rise of the “player-manager” - leaders expected to both manage and contribute technically.

When Carey said that line about one in three managers considering going back to IC work, I heard people around me exhale. That was not an audience reacting to a surprising statistic. That was an audience recognising their own situation described, probably for the first time in public.

Dominika Rogala, founder of Good Job Coffee (and Former VP of Engineering), gave a talk that added a layer to that. Mid-level managers report the highest burnout rates of any role in tech. And when managers burn out, they tend to pull their teams toward burnout with them. Her framing:

Burnout isn’t an individual failure. It’s a system problem. We shape the environment our teams work in, and the environment shapes the outcome.

I’ve written before about why being an EM today has never been harder. What LDX3 added wasn’t a new diagnosis - it was confirmation that this isn’t just my experience, or yours. It’s the condition of the role right now.

AI is amplifying existing friction

Nicole Forsgren, lead author of Accelerate & Sr. Engineering Director at Google, gave one of the best talk of the conference. I’ve read her work before, so I went in with high expectations.

Her central argument: before AI coding tools, your engineering systems had friction everywhere – slow builds, unclear ownership, knowledge that lived in one person’s head. But natural speed limits meant that friction wasn’t the bottleneck. Now that AI has dramatically accelerated how fast engineers can produce code, the friction that was always there has become the thing slowing everything down.

She mapped it into three types.

• Velocity friction: slow builds, manual approval gates, deployment processes that take 15 minutes.

• Cognitive friction: unclear criteria, constant context-switching, nobody quite sure what “done” means.

• Knowledge friction: engineers who can’t find architectural intent, don’t understand adjacent systems, have to ask a senior every time they touch something outside their usual area.

That last one is the one I haven’t been able to stop thinking about since. AI can generate the code. It cannot generate the context. And in most teams, the context lives in someone’s head - which means it’s not really accessible at all.

Rick Clegg, Developer Experience Lead at Wise, showed what fixing this can look like in practice. His team built tightly scoped AI tools baked into their engineering workflows - a code flow visualiser that generates diagrams showing how code actually runs, and a PR review assistant that explains changes in plain language. His goal wasn’t to make engineers faster. It was to make the system legible to anyone who needs to work in it. The speed follows from that.

Hiring is changing

The most surprising conversation of the conference came from Danit Nativ Navon, a Senior Engineering Manager at Meta. I went into her talk not knowing what to expect and came out rearranging how I think about our own hiring process.

Her team’s problem: candidates are using AI tools during interviews, sometimes with hidden screen overlays that stay invisible even when screen-sharing. Going back to in-person wasn’t a realistic fix at Meta’s scale. So they went back to first principles and rebuilt the whole thing.

They built a tool that gives candidates a full codebase, an AI assistant they’re allowed to use freely, and the interviewers assess them on things that don’t change regardless of the tool:

• how they explore a problem before diving in

• the quality and maintainability of the code they produce

• how they validate and question the AI’s output rather than just accepting it

• two layers of communication explicitly

  • how candidates talk to their interviewer (verbal)

  • how they write prompts to the AI (written)

They ran 9,000 interviews using this format before going fully live in April 2026.

The criteria for what makes a good hire didn’t change at all. The way you gather evidence for those criteria changed completely though.

What to actually do with all of this

The three themes above describe what’s happening. This next part is about what to do about it.

• On the EM squeeze: what to ask from your manager

• On friction: how to audit your team’s specific type

• On hiring: three things to check in your current process

On the EM squeeze: what to ask from your manager

Read more

Subscribe now

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

Kotlin: built for productivity

JetBrains studied 28 million development cycles across 320,000 developers and found that Kotlin development cycles were consistently 15–20% shorter than comparable Java cycles.

Kotlin was designed around a simple idea: spend less time on ceremonies and more time building. Features like null safety, data classes, smart casts, and concise syntax remove a surprising amount of everyday friction.

The result is a language that lets developers focus more on solving problems and less on satisfying the compiler.

Sponsored by JetBrains.

AI enthusiasts are in a race against time, AI skeptics are in a race against entropy ()

tl;dr: Exploration of the growing divide between AI enthusiasts and AI skeptics inside engineering teams. Both sides have valid concerns: enthusiasts fear falling behind competitors, while skeptics worry about reliability, maintainability, and long-term system health. Focus on shared reality, honest feedback loops, and treating AI adoption as an engineering problem rather than an ideological debate.

Modern Engineering Values (Christoph Nakazawa)

tl;dr: AI has fundamentally changed software development by making code generation cheap and abundant. As a result, engineering value increasingly comes from ownership, judgment, guardrails, feedback loops, and understanding the business context rather than manually writing code. The future belongs to engineers who can direct AI effectively while maintaining quality and accountability.

Building Software Is Learning ()

tl;dr: Building new software is fundamentally a learning process, not an execution process. Since nobody fully understands what a new feature should look like upfront, the goal is to shorten feedback loops through prototypes, demos, small releases, and early validation. Teams that learn faster build better products faster.

Make It Memorable ()

tl;dr: Goals, values, and strategies only matter if people can remember them when making day-to-day decisions. Companies often create too many priorities, making them impossible to use in practice. The best leaders simplify relentlessly so employees can easily recall and apply goals and values without needing a slide deck.

Fast is better than slow (Patrick Dubroy)

tl;dr: Speed is a competitive advantage because it increases learning, feedback, and decision-making quality. Reduce delays, seek feedback earlier, avoid perfectionism, stop over-engineering, and focus only on what’s required. Moving faster isn’t about working longer hours - it’s about eliminating unnecessary friction.

The Software Engineering Books I keep recommending ()

tl;dr: A curated list of software engineering books grouped by problem area. The main message is that the best book depends on what you’re struggling with right now - coding, architecture, distributed systems, testing, AI engineering, delivery, or career growth. Reading remains a competitive advantage, especially in an AI-driven world where engineers need enough knowledge to guide and challenge AI effectively.

Weird projects I shipped with AI (Sean Goedecke)

tl;dr: AI hasn’t created a flood of startups, but it has dramatically lowered the barrier to building small, useful projects. The author shares several examples that likely wouldn’t have been built without AI assistance. AI removes enough friction to make many niche ideas worth pursuing.

Most popular from last time

The last six months in LLMs in five minutes

If you enjoy articles like these, you might also like some of my most popular posts:

What did you read recently that you would like to share?

Leave a comment