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

Subscribe now

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

AI generates code faster than your engineers can review it, and most teams haven’t adjusted for the gap. Here’s how to treat reviewer attention as a constraint you actively manage.

If your team started using AI coding tools heavily this year, you’ve probably seen the same strange pattern I have. The team ships more, tickets move faster, and throughput dashboards look healthier than before. But at the same time, your senior engineers somehow look more tired, even though many of them are spending less time writing code.

A few months ago, one close friend of mine who’s a brilliant engineer told me: “I spend most of my day trying to decide whether I trust things.”

That statement explains a lot of what is happening right now.

For years, writing code and reviewing code moved at roughly the same speed because humans did both. If somebody wanted to submit a huge pull request, they had to spend real effort building it first. AI broke that relationship. One engineer can generate an enormous amount of ok-looking code in a few hours, but the reviewer is still reading it at human speed.

Most teams haven’t adjusted for that change yet. They still treat reviewer attention as something that stretches forever, even though it has become one of the scarcest resources inside many organizations.

A strategic lever for reviewing code

Sponsored by JetBrains

This whole issue is about reviewer attention collapsing when there is a lot of AI-generated code. One thing that shapes how fast that happens is the language your team builds in.

A recent study from JetBrains looked at 320,000 developers and 28 million development cycles over 20 months. Kotlin development cycles were 15–20% shorter than comparable Java ones. More interestingly, Java codebases became 9–17% slower to work in over time, while Kotlin stayed roughly flat.

That matters even more now because we have so much AI-generated code. Human review speed has not scaled.

On JVM teams, Kotlin’s null safety and strong type system catch a huge class of “looks correct, fails later” bugs before a reviewer even sees the pull request. The result isn’t just better safety. It also makes AI-generated code easier to understand, reason about, and validate.

When code is clearer and easier to review, engineers can spend less time verifying implementation details and more time evaluating whether the solution itself is the right one. In an AI-heavy workflow, that translates directly into faster reviews, greater confidence, and more reliable software.

Read the full study

Thanks to JetBrains for sponsoring this newsletter!

Reviews needed suddenly exploded

Teams used to have a natural limit on how much code needed to be reviewed: writing it took time. That alone filtered out a lot of low-quality or half-thought-through work before reviewers ever saw it.

Mitchell Hashimoto described this well when talking about how agentic programming removed the natural effort-based backpressure that used to exist in software development. Generating code became dramatically cheaper, but checking whether that code is correct, maintainable, and safe still takes the same careful human attention it always did.

That asymmetry is the problem.

Jason Wei wrote about the asymmetry of verification in AI systems, and the idea maps perfectly here. Some things are much easier to create than to verify. AI-generated code falls directly into that category.

You can generate a convincing implementation in seconds, but understanding whether it actually makes sense still takes real concentration. Someone still needs to think through edge cases, read the logic carefully, understand the architecture choices, and decide whether this thing will behave strangely in production six months from now.

Open source projects are already seeing louder versions of this problem. OCaml maintainers recently closed a 13,000-line AI-generated pull request because nobody could justify the review effort required. The interesting part was that the discussion was not about code quality. It was about reviewer capacity.

Inside companies, the same thing happens. An AI-generated pull request can look very convincing until somebody spends time reading it. By the time reviewers realize a change is difficult to validate, they are already deep inside the cognitive work.

What overloaded reviewers actually do

Most teams think this is a workload problem. I don’t think it is. I think it’s an attention problem, and those are much harder to notice because overloaded reviewers still look productive from the outside.

The first thing that happens is review quality drops. Not because reviewers become lazy, but because humans adapt to volume. People skim more, trust tests more heavily, and assume somebody else probably already checked things carefully.

One engineer from CodeRabbit described this really well: eventually everyone in the chain starts assuming someone else probably did the deep verification work. A Sonar survey found that while 96% of developers don’t fully trust AI-generated code, fewer than half always verify it before committing it.

The second thing that happens is more dangerous over time. Teams slowly understand their own systems less.

Code review is not only about finding bugs. It’s one of the main ways technical understanding spreads through a team. When engineers review code carefully, they build mental models of how the system behaves, how different components connect, and where complexity is accumulating.

Saturated reviewers stop building those models because they no longer have enough time to deeply understand what they’re reading.

Simon Willison calls this cognitive debt: code can technically work while nobody deeply understands why it works. That debt usually appears during incidents, when someone gets paged and discovers the implementation behaves strangely under production load, but nobody can fully explain the assumptions behind it.

I wrote before about how fast-moving teams can slowly lose understanding of their own systems. AI makes that dynamic much sharper because code generation scales faster than comprehension does.

Fast shipping can hide shallow understanding.

The final effect is organizational. Your strongest engineers increasingly become invisible infrastructure for the rest of the company. They spend huge amounts of time reviewing AI-generated pull requests, catching subtle problems, preserving consistency, and preventing incidents, but very little of that work shows up properly in promotion conversations.

The engineer protecting the system often ends up looking less productive than the engineer rapidly generating visible output.

That made sense when writing code itself was the expensive part. It makes much less sense now.

Treat reviewer attention like a budget

There are people arguing that line-by-line code review itself is becoming unrealistic. Ankit Jain made this argument in a widely shared essay, saying that once output scales high enough, manual review eventually loses.

I think there’s truth in that argument. But I don’t think the answer is “stop reviewing”. I think the answer is becoming much more intentional about where reviewer attention gets spent.

The biggest mistake teams make right now is pretending reviewer capacity is infinite when it clearly isn’t.

The first thing I’d recommend is making the concentration visible. For a couple of weeks, tag pull requests that are heavily AI-generated and look at who ends up reviewing them. Most teams quickly discover the same pattern: one or two senior engineers absorb most of the difficult verification work.

That concentration is the bottleneck.

The 2025 DORA report moved away from universal benchmarks for exactly this reason. Different teams have different constraints. You need to understand yours before you try fixing it.

The second thing is putting explicit limits on review load. At some point, people stop reviewing carefully because they simply cannot sustain that level of concentration every day.

Limit how many high-risk AI-generated pull requests one reviewer handles in a sprint. Create dedicated review blocks instead of constant interruptions.

The third thing is reviewing based on risk. Charity Majors talks about durable versus disposable code, and I think that distinction becomes very useful here. Authentication systems deserve deep understanding. A temporary internal migration script probably doesn’t.

The mistake is pretending every pull request deserves identical attention while reviewer capacity is already stretched thin.

The fourth thing is pushing more verification responsibility back toward the author. If somebody uses AI heavily to generate code, they should also carry more responsibility for proving the implementation works before review even starts. Good tests, clear reasoning, reproducible validation, and evidence the implementation behaves correctly matter much more now than they used to.

Reviewing AI-generated code is becoming a real senior engineering responsibility, but promotion systems barely acknowledge it. I wrote before about how some of the work holding teams together stays invisible, and verification work absolutely belongs in that category now.

If you don’t explicitly reward it, your strongest reviewers will eventually realize the smart career move is to stop reviewing carefully.

Where this leaves engineering leaders

The verification tax isn’t some future problem. Many teams are already paying it.

The reason it catches organizations off guard is that dashboards still show good news while reviewer capacity is collapsing underneath them. Throughput increases, but understanding spreads more slowly, review quality drops under pressure, and senior engineers spend larger parts of their week validating work they didn’t write and often can’t easily trust.

You do not need a massive reorganization to respond to this. Most teams probably just need to see where review load concentrates, put limits on what any one person absorbs, and start treating verification work as real engineering leverage instead of invisible maintenance work.

The real bottleneck in many organizations is no longer code generation speed. It’s reviewing that code that they’ll have to maintain.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

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

How can I lead a critical project when senior leaders are in conflict? (Andi Roberts)

tl;dr: When senior leaders disagree, the real problem is usually unclear governance rather than difficult personalities. Instead of acting as a mediator, leaders should create clear decision rights, formal escalation paths, and visible accountability. Stop absorbing dysfunction and make organisational risks impossible to ignore.

Get to the Core of the Thing ()

tl;dr: Many strategic discussions get stuck debating abstract choices like “go wide or go deep” instead of focusing on what customers actually need. The real question is always: what specific feature or capability will make customers buy and stay? Great decisions come from customer insight, not clever frameworks.

The Ask (Michael Lopp)

tl;dr: In senior leadership, every meeting exists because someone wants something - even if it’s not obvious at first. Great leaders learn to identify the hidden “ask” behind conversations and understand why they were invited. Much of leadership is recognizing patterns, building relationships early, and trusting experience-driven intuition to uncover what really matters.

Using AI to write better code more slowly (Nolan Lawson)

tl;dr: AI is most valuable when it’s used as a reviewer, not just a code generator. The author uses multiple AI models to find bugs, validate issues, and challenge assumptions, often improving code quality rather than increasing speed. Use AI to help you understand code more deeply, not just produce more of it.

EQ is not just about what you say. It’s your body language too. ()

tl;dr: People communicate through body language as much as through words, often without realizing it. Understanding your unconscious “tells”, controlling your signals, and staying physically calm can improve trust, executive presence, and psychological safety. Strong communication is about aligning your body language with your intent.

The last six months in LLMs in five minutes (Simon Willison)

tl;dr: The biggest AI shift over the last six months wasn’t new models - it was coding agents becoming genuinely useful for everyday software development. At the same time, smaller open-source models improved dramatically, making powerful AI available on consumer hardware. AI coding tools have crossed a threshold from interesting experiments to practical daily tools.

Most popular from last time

AI productivity debate

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

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

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

In the second half of 2025, candidates using unauthorized AI in coding interviews jumped from 15% to 35%. In technical roles specifically, it hit 48%. And 61% of those cheaters passed to the next stage.

Six in ten people who cheated successfully progressed.

If your reaction is “we need better proctoring”, I think that’s the wrong instinct. You’d be racing against invisible screen overlays that the candidate’s grandmother could install in five minutes.

The companies that have actually fixed this didn’t fix detection. They redesigned their interview completely.

This is what’s happening today. I’ll give you a simple “keep, kill, add” that works for companies like Google, Canva, Shopify, Meta, and Anthropic.

The wrong instinct (both versions of it)

Engineering leaders have two instincts.

Instinct 1: Ban it. There is software that create invisible overlays which reads the interviewer’s audio and feed the candidate a responses in under two seconds. And although you might think you’ll easily catch it, you might be optimising for the candidates who are best at cheating.

Instinct 2: Allow it on your existing interview questions. Google ran the experiment for you, and the lesson, is that if all you do is allow AI on your existing problems, you’ve changed nothing.

Where the serious companies actually landed

Look at who has moved publicly and where they ended up.

Google is piloting an AI assistant (Gemini) inside the coding round itself. The format is a three-panel layout: file explorer, code editor, AI chat. The AI can’t edit files. The round focuses on reading, debugging, and optimising existing code, not writing from scratch. (Exponent) The signal: the future is “review and verify”, not “produce”.

Canva killed its “CS Fundamentals” round in June 2025 and replaced it with an AI-Assisted Coding round. Candidates are expected to use Copilot, Cursor, or Claude. (summary) The new questions are “complex, ambiguous, realistic”, which is the opposite of one-shot prompts.

Shopify lets candidates bring their own AI tools. The interviews require integrating AI-generated snippets into unfamiliar codebases. (Hello Interview) Reading and grafting code matters more than writing it.

Meta runs an AI-Enabled Coding Round with a rubric of problem solving, code quality, verification, and communication. (Hello Interview) Communication is back on the scorecard.

Anthropic reversed an early ban. AI is allowed for the application and prep, but forbidden during the live round. (Fortune) Even AI companies decided that uncontrolled AI in live interviews is a signal problem.

Nobody serious is doing “business as usual”. The actual split is between allow with structure (Google, Canva, Shopify, Meta) and block during live, allow around it (Anthropic).

Keep / Kill / Add.

At the recruiter screen, keep the 15-minute phone call. Kill the “do you use AI tools?” question, because everyone says yes. Add one specific prompt instead: “Walk me through the last time AI got something wrong for you. What did you do?”

For the CV and portfolio, keep the GitHub link and prior impact. Kill LeetCode contest scores and hackathon badges. Add one required line in the application: a 200-word “how I work with AI” statement.

At the first technical round, keep a live, conversational format. Kill the 45-minute algorithm puzzle. Add a 45-minute read-and-fix round on a real, messy file from your codebase.

The take-home stays gone. Keep nothing. Kill the take-home, all of it.

At the onsite coding round, keep one pair-programming session. Add a live AI-assisted round, where you score them on direction, not output.

At the onsite system-design round, keep the whiteboard. Kill “design Twitter from scratch”. Add a 45-minute “review this architecture and tell me what’s wrong” round.

For the onsite behavioural round, keep your real values prompts. Add: “Tell me about a time you chose not to use AI on something. Why?”

A few of those are spicy. The take-home being killed is the spiciest. If you want to know why, ask yourself: when a candidate hands their take-home to Claude and the result is good, what did you actually measure?

The five signals that survive

If you only redesign one thing, redesign your scorecard. The signals every serious company is now scoring converge on five dimensions:

1. Problem decomposition. Before they touch a keyboard, do they clarify scope, edge cases, and constraints? Or do they jump straight to prompting?

2. Control over the AI. Are they directing the model, or being led by it? Strong candidates write targeted prompts, reject unhelpful suggestions, and choose when not to use AI at all.

3. Verification habits. Do they read the diff line by line, run the code, write a test, catch the hallucinations? Or accept the first plausible output and move on?

4. Architectural judgment. Can they reason about blast radius, cost, scale, trade-offs? This is the hardest thing to fake with AI in 90 seconds, which makes it the most valuable thing to test.

5. Communication. Can they narrate while juggling the AI? Can they hold a conversation with you while typing? Or do they go silent and emerge with a finished blob?

The signals you stop scoring matter too. Clean variable names. Speed to first plausible answer. Syntactic elegance. AI does all of those for free now.

I wrote more about this shift in Stop interviewing like a mid-level engineer and Why you can’t hire great senior engineers. Both rest on the same idea: you’re hiring for judgment, not output.

The junior pipeline

The LeadDev AI Impact Report 2025 found that 18% of engineering leaders expect to hire fewer juniors in the next 12 months. 54% think AI will reduce junior hiring long-term. 38% say AI has already reduced mentoring.

If you redesign your loop only around “judgment and verification”, you’ve designed juniors out of it.

You can consider:

Separate the junior loop. Same five signals, applied at a junior level. Junior verification looks like “did you actually read the code?”, not “can you spot a subtle architectural flaw?”. Make them clear a junior bar that still maps to the real signals.

Score learning velocity explicitly. Add a 20-minute round where you teach the candidate something new on the call and watch how they use it. This is the round AI can’t help with.

I’ve made this case in different shapes in 11 Interview questions I ask every engineer and The new engineering manager hiring bar.

A 90-day rollout plan

You don’t need executive sponsorship for this. You need a few months to put it in place.

Weeks 1 to 2: Audit. Pull the last 20 hires through your current loop. For each one ask: did the loop actually surface the five signals? Where did it miss? Where did it overweight noise?

Weeks 3 to 4: Redesign the pairing stage. Take your existing questions and replace them with read-and-fix problems pulled from your real codebase.

Weeks 5 to 6: Retrain interviewers. New questions with old interviewer instincts produce old outcomes. Two 90-minute sessions: one on scoring AI usage, one on running the new format.

Weeks 7 to 8: Calibrate. Run the new loop on three internal “candidates”, engineers from another team. Score them, compare scores across interviewers, and adjust the rubric where you diverge.

Weeks 9 to 12: Ship and measure. Run the redesigned loop. Track: offer-to-acceptance rate, 90-day performance correlation, time-to-decision.

What this looks like in 2027

Here’s where I think we’re headed.

In eighteen months, the live coding interview is no longer a coding interview. It’s a collaboration interview. You and the candidate sit in front of a real problem, both with AI tools, and the candidate’s job is to drive while you watch. The whiteboard system-design round becomes the most predictive round in the loop, because it’s the one AI can’t take over.

Take-home tasks are completely gone. Algorithm puzzles are gone. Behavioural rounds get harder, not easier. The candidates who win are the ones who can hold a conversation, hold a system in their head, and hold the AI accountable.

Most leaders will arrive there in 2027 because they were forced to. The leaders who arrive in 2026 will be the ones who hired the best people for an entire year.

The one thing to take away: Your interview loop has a redesign deadline, and it’s not “when you have time”. Pick the keep/kill/add row that’s hurting you most and change one thing this month.

P.S. If you want to see how this connects to onboarding (because a bad redesigned loop still misses the next Soham), I wrote about that here: Would your onboarding process catch a Soham?. The interview is the front door. Onboarding is the test of whether the door worked.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

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

Barely Treading Water (Michael Lopp)

tl;dr: Even though the company looked successful from the outside, he was personally overwhelmed and slowly failing at prioritizing, delegating, and managing expectations. A trusted colleague confronted him: leaders fail too, and the solution is to honestly admit it, ruthlessly prioritize, delegate more work, and say no to things the team realistically cannot do.

From Metrics to Meaning ()

tl;dr: Metrics alone rarely inspire action because numbers without context do not create meaning. Great leaders turn data into stories by explaining what the team believed, what the metric actually revealed, and what action or change is now needed.

AI Productivity Debate ()

tl;dr: How senior engineering and research leaders think AI is changing software engineering, from coding and code review to hiring and team structure. The overall view is that AI will not replace engineers, but it will change the work engineers do, shifting more focus toward reviewing, guiding, prioritizing, and managing AI-generated output.

Distilling Leadership Wisdom ()

tl;dr: How you can use AI to “distill” the thinking of leaders you admire by feeding interviews, podcasts, and writing into a custom AI role you can talk to anytime. Instead of copying their opinions, the goal is to use their mental models and questions to challenge your own thinking and make better decisions.

Software’s Centaur Era (Richard Marmorstein)

tl;dr: Even if AI becomes better at writing code, software engineers will still matter as long as humans working with AI outperform AI working alone. It compares the current moment to chess “centaurs”, where the strongest results came from humans and AI collaborating together rather than either operating independently.

Learning Software Architecture (Alex Kladov)

tl;dr: Software architecture is mostly learned through building real systems and dealing with real constraints, not through theory alone. The quality and structure of software are heavily shaped by incentives, team structure, and organizational pressures, not just technical skill.

Most popular from last time

The slop cannons in your engineering org

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

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

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

When a standup or retro stops working, the instinct is to change or cut it. This article looks at why that rarely helps, and how to diagnose the underlying condition a ceremony might be exposing.

Most engineering managers have sat through a standup that was clearly a waste of time. Nobody raised their actual blockers, updates sounded performative, and the meeting somehow felt both rushed and pointless at the same time.

The natural reaction is to assume the meeting itself is broken.

So the team experiments. Maybe the standup becomes async. Maybe it moves to twice a week. Maybe the retro gets shortened. Maybe somebody decides the team has “too many ceremonies” and starts deleting them.

I’ve done versions of all of that before.

Most of the time, it did not solve the actual problem. It just moved the problem somewhere less visible.

A malfunctioning ceremony is usually not the disease. It’s the symptom. The standup, retro, or planning session is exposing a condition underneath the team, and changing the format often only changes where you notice the condition.

If your team avoids surfacing blockers in standup, they’ll usually avoid surfacing them in Slack too. If ownership feels unclear during planning, ownership is probably unclear in the actual work. If nobody disagrees openly during retro, removing the retro does not suddenly create trust.

You haven’t fixed the underlying condition. You’ve mostly hidden the readout.

Ceremonies are not only coordination tools. One of their biggest values is that they make the state of a team visible. A good standup tells you whether ownership is clear. A good retro tells you whether people feel safe disagreeing. A good planning session tells you whether the team actually understands its priorities.

When you remove a ceremony without understanding what it’s exposing, you often lose visibility of the problem itself.

A ceremony reflects the condition of the team

A few years ago, I inherited a team with a standup everybody disliked. It was way too long, nobody seemed engaged, and half the meeting was people struggling to remember what they did yesterday. So I did what felt sensible at the time and replaced the meeting with written Slack updates.

At first, it looked like a huge improvement. Engineers got time back, nobody had to context-switch first thing in the morning, and the updates looked cleaner and more efficient.

Then the written updates became shorter. Then vaguer. “Still working on it” “Making progress” “Almost done”. One engineer stayed blocked on an auth migration for over a week because nobody, including me, registered that “still working on it” had turned into “I’m stuck” but was scared to say it.

The standup had not been the problem.

The standup had been the thing showing me there was a problem.

Once I removed it, the issue did not disappear. I just stopped seeing it clearly enough to react early.

That distinction matters a lot because managers often treat ceremonies like levers. If the standup feels bad, change the standup. If retro feels awkward, redesign retro. But ceremonies usually do not create team health. They expose the current state of the system underneath them.

Will Larson has a good point about organizational change that maps directly onto this. Teams pay a real cost every time you change how they operate. If you kill standup, replace it with async updates, then reintroduce meetings three months later because the async version failed, you’ve paid the change cost multiple times without ever addressing the underlying issue.

Most problems inside organizations come from the system itself rather than the individuals inside it.

When a ceremony consistently breaks down, the cause is usually structural. Maybe ownership is unclear. Maybe the team is too large. Maybe priorities change constantly. Maybe people don’t feel safe admitting they’re stuck. Maybe the work itself is so tangled that coordination naturally becomes painful.

Changing the meeting format rarely fixes those conditions.

I wrote before about systems thinking for engineering managers. Instead of asking “how do I improve this meeting” ask “what does this meeting keep telling me about the team?”

That question usually leads somewhere much more useful.

What broken ceremonies usually signal

Once you start looking at ceremonies this way, certain patterns become hard to unsee.

One of the most common is the standup where nobody surfaces a real blocker. Everybody says they’re “fine” but work is obviously moving slower than it should. Deadlines slip, problems appear late, and people seem to discover dependencies at the last possible moment.

Most of the time, that’s not a meeting-format issue.

Admitting you’re stuck feels socially expensive, so people avoid doing it publicly. A 2025 study in the European Journal of Work and Organizational Psychology found that standups strongly relate to psychological safety, and through that to team performance. A standup where nobody admits blockers usually does not mean the team is healthy. It usually means the team does not feel safe exposing uncertainty.

Another common pattern is when everybody talks to the engineering or product manager instead of to each other. The meeting turns into a model where every update routes through one person. Engineers wait for the manager’s reaction before moving on, and discussions rarely happen naturally between teammates.

That usually means that the team sees the manager as the center of coordination instead of the work itself being the center.

The ceremony is exposing the shape of the organization.

Another useful signal is the meeting that constantly spills into “let’s take that offline”. Once or twice is normal, but if that happens a lot it means that people no longer match the dependency graph of the work. Maybe the team became too large. Maybe it’s really two teams pretending to be one. Maybe ownership boundaries stopped making sense but nobody revisited them.

The important point is that none of those conditions gets fixed simply by changing the meeting itself.

Low trust does not disappear because standup moved to Slack.

Unclear ownership does not disappear because updates became async.

A badly shaped team does not become healthy because retros now happen every other Friday instead of weekly.

The meeting is just exposing the condition.

This is the same pattern I see in defensive communication inside teams. When somebody answers a simple question with three paragraphs of explanation, the length is not the actual problem. The communication style is signalling something underneath it.

Ceremonies work the same way. Read the signal, not only the surface behavior.

Sometimes the meeting genuinely is bad

That said, I do think managers can overcomplicate this idea too.

Sometimes the ceremony genuinely is just poorly designed.

A standup scheduled at 9 a.m. for a team split across London and San Francisco is failing because the timing is terrible, not because there’s some deep trust issue hiding underneath it. A retro with twenty-five people in it might simply be too large to function properly. A planning session without an agenda will usually feel chaotic because the structure itself is chaotic.

Those are real mechanical problems and they should be fixed.

The important thing is distinguishing between a mechanical issue and a structural one. If the problem disappears once you fix the timing, attendee list, or format, then great. Don’t invent deeper organizational meaning that isn’t there.

But if the same patterns keep reappearing after multiple ceremony redesigns, there’s a good chance the ceremony is exposing something more fundamental about how the team operates.

There’s also an important nuance here. The DORA research behind Accelerate argues that changing how teams work can shape culture itself. In other words, behavior can influence mindset, not only reflect it.

I think that’s true.

A well-designed ceremony absolutely can improve communication patterns over time. But the teams that successfully changed their rituals usually changed the surrounding system too. Teams that successfully move toward async work usually strengthen documentation quality, ownership clarity, and written communication expectations at the same time.

The format change works because the environment around it changed too.

Deleting a ceremony to avoid discomfort is very different from redesigning a ceremony to improve how the team operates.

So when a ceremony starts feeling dysfunctional, the sequence I usually follow is fairly simple. First, describe the exact behavior you’re seeing instead of saying “the meeting feels bad”. Then check whether there’s a simple mechanical fix. If not, ask what condition underneath the meeting could realistically be creating the behavior. Only after that do I think about redesigning the format itself.

And when the format does change, it should apply pressure to the real issue underneath it rather than simply hiding the symptom.

If everybody reports upward to the manager, don’t just tell people to “collaborate more”. Change the meeting structure so the discussion follows the work itself instead of the individuals. If people avoid admitting blockers, the real work probably lives outside the ceremony entirely, in your 1:1s, in how you respond when somebody admits uncertainty, and in whether the team has learned that exposing problems is safe.

Those changes take much longer than redesigning a standup.

But they’re usually the thing that actually matters.

The discomfort is useful

The reason broken ceremonies feel so frustrating is because they expose things teams would often rather hide.

A standup where nobody admits they’re blocked reveals a lack of trust. A retro where nobody disagrees reveals low psychological safety. A planning session where priorities constantly change reveals instability higher up the organization.

That discomfort is useful information.

So before you stop a ceremony entirely, it’s worth asking yourself what visibility disappears with it. If the answer is “nothing, the format itself is just mechanically bad” then change it without guilt.

But if the answer is “I’ll stop seeing that the team doesn’t really trust each other” then the ceremony was never the thing that needed fixing.

It was the thing trying to show you what to fix.

If you enjoyed this article, consider subscribing to get:

• ✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers

• 🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

Subscribe now

You might also like some of my most popular posts:

See you in the next one,
~ Stephane

To accelerate your growth see:

• Get Hired as an EM (CV & job search to actually get interviews)

• AI Behavioral Interview Coach (the best prep for your interviews)

• 1:1 Coaching (work with me)

Subscribe now

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

The slop cannons in your engineering org ()

tl;dr: Some engineers are using AI tools in a careless way, generating lots of code and designs without fully understanding what they’re shipping. This creates more bugs, messy pull requests, and teams that feel productive while actually slowing down or lowering quality. AI is powerful, but it only helps if people still think critically, review their work properly, and truly understand the systems they’re building.

A Lesson From the Cockpit (Subbu Allamaraju)

tl;dr: While automation can improve productivity, it can also slowly weaken people’s skills and understanding if they rely on it too much. The post explains that industries like aviation learned they still need humans to regularly practice without automation so they can handle difficult situations when systems fail. Software engineering needs to do the same with AI: use it as a tool, but make sure engineers still deeply understand systems, practice without AI sometimes, and avoid becoming overly dependent on automation.

The AI-native developer ()

tl;dr: AI is changing software engineering, with developers gradually moving from being skeptical of AI to using it as a core part of their workflow. The best developers are no longer just writing code themselves, they are learning how to guide, review, and coordinate AI systems effectively, but this also creates risks like weaker technical skills, over-dependence on AI, and less understanding of the code being shipped. The future of engineering will depend on whether companies reward deep thinking, judgment, and quality, or simply reward speed and output.

Three AI principles every exec leader needs to understand (Anna Shipman)

tl;dr: Executives and company leaders can no longer treat AI as “just a tech problem” that only engineers need to understand. AI is unpredictable and makes mistakes, AI can become very expensive over time, and real competitive advantage comes from how companies integrate AI into their workflows - not from simply using the same AI tools as everyone else. Leaders need enough AI understanding to ask good questions, manage risk properly, and make smart long-term business decisions instead of blindly chasing AI hype.

Can one bad apple ruin your team? ()

tl;dr: One consistently negative person can seriously damage a team’s energy, morale, and performance, even if the rest of the team is talented. Research shows that moods and behaviors spread quickly in groups, meaning a “bad apple” can make others more negative, disengaged, or unmotivated - while a calm and positive person can sometimes reverse the effect. Team culture is shaped not just by processes or strategy, but by the emotional influence people have on each other every day.

Most popular from last time

Designing the AI-native engineering organization

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