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. Mayb…

Read more

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

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.

Someone on your team keeps complaing, nitpicks every code review, or stays quiet in meetings but then complains to you in 1:1s.

Maybe they’re being “difficult”.. There is a chance though that it’s the environment around them.

Most advice on how to deal with “difficult” engineers revolves around having hard conversations with them. These conversations help for sure, but if you have to be having them often, you might be treating the symptom instead of the cause.

A lot of “difficult” behaviour comes from how the team is set up, what gets rewarded, and what gets tolerated.

This a…

Read more

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.

Becoming a Business Leader, Not Just a Technical One ()

tl;dr: Many senior engineering leaders stop growing because they focus only on technology and not enough on the business side of the company. To become a strong executive or CTO, you need to understand things like customers, money, strategy, sales, and business trade-offs - not just architecture and engineering. Great technical leaders eventually need to become business leaders too.

Designing the AI-native engineering organization ()

tl;dr: AI is changing how engineering teams work, especially by making coding faster and shifting more time toward planning, decision-making, and reviewing work. Companies like Microsoft, Atlassian, and 1Password are using smaller teams, shorter planning cycles, and more AI-assisted workflows instead of completely restructuring their organizations. Future engineers will be valued less for just writing code and more for product thinking, decision-making, adaptability, and taking initiative.

How to one-on-one (Ben Balter)

tl;dr: Good 1:1s should focus on things that need real conversation, like career growth, feedback, coaching, difficult situations, and building trust - not status updates. Great 1:1s happen when both people prepare beforehand, keep a shared agenda, ask thoughtful questions, and protect the meeting from cancellations. 1:1s are one of the most important tools managers have to build strong relationships and help people grow.

You Can’t Fake Belonging ()

tl;dr: Feeling like you belong at work is one of the biggest drivers of happiness, performance, motivation, and retention. People who feel excluded or disconnected don’t just become less productive - over time, they can lose confidence, disengage emotionally, and stop feeling connected to the team or company. Managers play a huge role in creating belonging through trust, attention, inclusion, and genuine human connection.

Fun Feedback Exercises & Activities to Do With Your Team (Kim Scott)

tl;dr: Teams get much better at feedback when they practice it in simple, interactive, and even funny ways instead of treating it as a stressful formal process. Exercises like role plays, peer feedback, and debate games help people learn how to give honest feedback clearly while still showing respect and care.

Most popular from last time

How To Be Direct And Strategic

It is my birthday today, if you’re reading this I hope you have an amazing Sunday and thank you for spending a small part of it with me.

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.

Most engineering rubrics measure what was delivered, not what happened in the background for the systems to keep working – here is what to add to yours so the engineers keeping the lights on get the credit they deserve.

You have probably had this conversation. Calibration season, two engineers at the same level. One built a new service that landed in front of customers and got named in the all-hands. The other spent the cycle on a database migration that prevented an outage nobody ever saw, plus the mentoring and documentation that kept a junior team functional while the t…

Read more

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.

How to hire people who are better than you (Jason Cohen)

tl;dr: You have to hire people who know more than you in domains you can’t evaluate, so stop trying to assess their expertise and instead watch for specific tells - do you leave the conversation wanting to implement half their ideas, are you already learning from them in the interview itself, and would it scare you if they joined a competitor?

How To Be Direct And Strategic ()

tl;dr: Reframes “strategic communication” for engineers who confuse directness with bluntness. Three-question prep before any high-stakes conversation: what does this person already believe, what emotion will this trigger, and what needs to be said first.

Measure Less to Learn More (Discord) - Jake Mainwaring

tl;dr: Discord reduced their experiment metrics from ~50 to ~15 and got ~45% better at detecting real, meaningful effects, because tracking too many metrics makes statistical corrections stricter and hides what actually matters. Too many metrics come at a cost - every extra, overlapping metric makes it harder to detect real improvements.

The Critical Shift In What Differentiates Great Leaders ()

tl;dr: Analysis, synthesis, pattern recognition are getting commoditized by AI, so the leadership differentiators going forward are heart (reading and managing the emotional state of a room) and gut (ethical judgment in novel situations where the data doesn’t decide for you).

Speak in the affirmative: “Do this” versus “Don’t do that” ()

tl;dr: Flip negative phrasings to positive ones because “don’t do X” forces the listener to mentally model X and then invert it, which adds friction, sounds reprimanding, and worst of all gives airtime to exactly the behavior you don’t want.

Most popular from last time

AI Impact Report: Q1 2026

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.

Having a strong engineer who owns a critical system feels like an advantage, but it hurts their career and your team’s resilience.

Most teams I’ve inherited has had one. The engineer who knows the payment system end to end, or the legacy ingestion pipeline, or the gnarly auth flow nobody else has touched in three years. They answer every question about it on Slack within minutes. They’re on every related incident. When a stakeholder asks how long a change will take, you ask them, because nobody else can give you a useful answer.

It feels like a strength. I think that it isn…

Read more

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.

Red-Teaming Your Strategy ()

tl;dr: A Southwest flight landed at the wrong airport because the pilots stopped checking. The same thing happens in leadership: teams move from data to intuition too quickly and confuse confidence with correctness. The fix: build systems that force you to keep verifying, especially when you feel most certain.

High Amplitude Disagreeableness

tl;dr: Startup people don’t disagree more often than others - they just disagree harder when it matters, and this post reframes that as a measurable trait (amplitude vs. frequency) rather than a personality flaw to manage around.

My AI Workflow Without Losing My Skills (Marc G Gauthier)

tl;dr: Mix vibe-coding, manual coding, and AI-assisted coding. The rule of thumb is reviewing 100% of AI code and writing roughly 50% manually, with agents reserved for “Omega Messes” (well-isolated, heavily testable chunks).

AI-Assisted Engineering Q1 2026 Impact Report ()

tl;dr: Two structural shifts: engineering managers using AI daily are now shipping 4x more code than six months ago (player-coach is back), and junior engineers have just overtaken Staff+ engineers in weekly time saved (4.9 vs 4.8 hours).

Why can’t they just...? Revisited (Lara Hogan)

tl;dr: A reissue of Hogan’s 2017 piece, updated with AI mandates as the running example - the question “why can’t they just X” almost never has the answer the asker assumes (it’s rarely lack of awareness, urgency, or willingness).

Most popular from last time

15 principles for managing up

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.

The engineering manager role today isn’t the same as it was when most of us started. The expectations have changed in a few specific ways. If you’re preparing for an interview or designing a hiring loop, it’s worth understanding what changed.

Four things stand out.

System design rounds now expect the breadth and depth of a staff engineer. Behavioural interviews assume you’ve already rehearsed every common question. Hiring loops often stretch across four to six weeks. And AI fluency has become a near-universal topic.

Each of these signals what companies are really looking for…

Read more

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.

What Agent Orchestration Actually Changes: The Hidden Costs Behind Shared Understanding (Viktor Cessan)

tl;dr: Most of what managers do is “negentropy” - preventing shared understanding from degrading in three specific ways (state, semantic, verification). Agent orchestration is a phase shift that decouples output from coordination cost, not just a productivity bump.

The Economics of Software Teams: Why Most Engineering Organizations Are Flying Blind (Viktor Cessan)

tl;dr: A team of eight costs ~€87k/month. Break-even isn’t the right bar - a 50% initiative success rate means you need 3–5x cost in value to be financially viable, and almost nobody on the team knows these numbers.

15 Principles for Managing Up ()

tl;dr: A dense, tactical playbook with concrete before/after scripts for each principle. Lead with the punchline, show your thought process with conviction levels, bring solutions not complaints, proactively assert what to do rather than ask.

Mechanical Sympathy (Vicki Boykis)

tl;dr: The best engineers are also good product designers because both skills come from “mechanical sympathy” - an intuition for the grain of the system, built up over a human lifetime of context, that coding agents fundamentally lack. Agents fix code that already works, rewrite tests to assert wrong outputs instead of fixing the underlying bug, skip modern tooling defaults (uv, vectorized ops), and erode under iterative refinement - none of which are fatal alone, but collectively produce software that feels “hard” to develop.

Developer Ramp-Up Time Continues to Accelerate with AI ()

tl;dr: DX’s quarterly data shows Time to 10th PR dropped to 33 days in the latest cut (from 39 in Q4 2025, and 91 pre-AI), with the biggest driver being orgs now guiding new hires to use AI for codebase Q&A and draft changes rather than leaving it optional. Justin flags the honest limitation himself that 10th PR tells you nothing about code quality, rework rate, or whether you’ve just shifted the burden onto senior reviewers.

Most popular from last time

Why Your Engineering Team Is Slow

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.

Most engineering managers carry around a ghost team. It is the team they worked on five or ten years ago where everything clicked: no ego, blameless retros, decisions made in ten minutes that would now take three meetings. They have spent every job since trying to get back there. And every time, it does not quite work.

The reason has nothing to do with the new people being worse, or the company being too big. It is that the kanban board, the lack of standups, the open Slack channels were outputs of trust, not inputs. Copy the outputs onto a team that has not earned the tru…

Read more

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.

Why Your Engineering Team Is Slow (Ally Piechowski)

tl;dr: Introduces “codebase drag” and gives you a 5-signal scoring rubric (apology estimates, deploy fear, “don’t touch that” files, the coverage lie, time to first commit) to diagnose it. Worth reading if you’ve ever had to justify a refactor sprint to your product manager - it gives you a vocabulary and a number to put in front of them instead of vague “tech debt” hand-waving.

Encoding Team Standards (Rahul Garg)

tl;dr: Argues that AI coding instructions should be treated like CI configs or lint rules (versioned, reviewed, repo-resident artifacts) not Slack tips or tribal knowledge in seniors’ heads. The core insight is that AI-assisted development turns inconsistency between juniors and seniors into a systems problem you can actually solve: extract what the senior instinctively prompts for (architectural constraints, threat model, refactoring philosophy) and encode it as executable instructions with role/context/categorized-standards/output-format anatomy.

The Alarm That Went Silent ()

tl;dr: Teams optimize for the metrics they can see, while risk builds in areas that are harder to measure: team burnout, frustrated customers who haven’t churned yet, fragile systems, weakening culture, or slower decisions caused by too much process. Even more importantly, teams rarely stop to ask a harder question: how would we know if our metrics stopped telling the truth?

Say the Thing You Want (Matheus Lima)

tl;dr: Why engineers (and engineering managers) sit on what they want in 1:1s and how that tanks careers - managers have seven other reports and incomplete information, so an unspoken desire has zero surface area for anyone to help with. People confuse wanting something with working toward it, and saying it out loud to another person is what actually gives the goal weight and changes your behavior.

On the Socially Acceptable Use of AI in Business (Dave Kellogg)

tl;dr: Use AI however you want, but you are responsible for the result. Rejecting an idea just because AI helped create it misses the point. What matters is whether the idea is good. The real problem is presenting AI output as your own thinking when you haven’t read it carefully, challenged it, and corrected it. AI can help you work faster, but you still need to understand the work. If you let AI do the thinking for you, the mental skill you’re supposed to build will slowly weaken.

Most popular from last time

How Do You Know If You’re a Good Leader?

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.

You’ve got a Senior Engineer or Tech Lead who used to be the gravitational centre of your team. When things broke, they fixed them. When nobody could figure out why the service was choking, they found the problem. When architectural decisions needed to be made, people looked at them.

Now they come to you frustrated. “Nobody listens to me anymore.” Or worse, they don’t come to you at all - they just disengage.

What happened is subtle. The mechanism that senior engineers used to build trust (being the person who solves the problems nobody else can) has been undercut. Not elim…

Read more

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.

What Kinds of New Debt Are Teams Accumulating with AI? ()

tl;dr: Technical debt (code), cognitive debt (team understanding), and intent debt (missing rationale/design docs). AI may actually reduce technical debt while accelerating the other two, because the friction of writing code by hand is what builds understanding.

Software Engineering Splits in Three (Matteo Collina)

tl;dr: AI doesn’t just change how software gets built - it’s causing the industry to fracture into three genuinely different tiers with diverging skill requirements. Tier 1 (tech companies) needs senior reviewers of AI output, Tier 2 (enterprises) needs platform guardrails plus fractional senior expertise, and Tier 3 (small business) creates a “software plumber” role. Also raises an important question: if juniors no longer learn through working on tickets, where do your future senior engineers come from?

What About Juniors? (Marc Brooker)

tl;dr: Marc makes a compelling case that the junior engineer path needs to fundamentally shift - less time in the craft-of-coding apprenticeship, more early exposure to customers, economics, business constraints, and real ownership. The core argument is that engineering is about optimal solutions under competing constraints (people, money, tech), and juniors need to engage with that full picture much earlier than before. His advice to managers: give juniors a project to own, a customer to talk to, a deadline to hit, and a pager to carry.

Nobody Is Coming to Save Your Career ()

tl;dr: An Amazon Principal Engineer says: your manager isn’t your career coach (they’re too busy), your timeline is your responsibility (not the system’s), and your company’s incentives actively benefit from your comfortable stagnation. This is more of a “career wake-up call” than anything else, but the specific tactics are solid. Worth sharing with senior ICs on your team who seem stuck but haven’t initiated the conversation.

How Do You Know If You’re a Good Leader? ()

tl;dr: Uses Lincoln’s private self-doubt journal as a frame to argue that introspection isn’t imposter syndrome - it’s a leadership discipline. The practical core is a three-angle self-evaluation model (how your boss, peers, and team each experience you) and a useful reframe on feedback: if it’s correct, act on it; if you disagree, you still own the perception.

I’m an Introvert. This Is How I Get Myself to Speak Up. ()

tl;dr: Decide to speak before the meeting starts (not during), speak early to avoid getting scooped, use writing as a visibility strategy, and prep go-to phrases to buy yourself time. If you have quiet high-performers, try the accountability-buddy approach - DM them in meetings with a low-pressure nudge to chime in.

Most popular from last time

How We Hire Engineers When AI Writes Our Code

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

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

You’ve seen the dashboard. Your team’s PR throughput is up thirty percent. Tickets close faster. On paper, your team looks more productive than ever. The “AI era” has arrived, and the metrics seem to prove the investment was worth it.

But talking to your senior engineers, the vibe you feel is different. They’re exhausted. They feel like they’re drowning in a sea of what several practitioners call “slop”. While the “typing” part of the job has been compressed, the cognitive load of shipping a single feature has actually intensified.

We are currently living through a m…

Read more