Executive Engineering Newsletter

Your incident response wasn't built for AI | Exec Engineering #207

Yassine Kachchani — Thu, 27 Aug 2026 18:14:17 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Your incident response wasn’t built for AI (Adora Nwodo / LeadDev)

Classic incident response assumes you can reproduce a failure, that it shows up as an error, and that on-call has a lever to fix it. Ship an AI feature and all three stop being true at once. It returns a confident wrong answer with a 200 OK, so your dashboards stay green throughout. And since the same input can quietly give a different output, those could-not-reproduce tickets you keep closing are really live bugs. Nwodo looks into what your team can actually own here.

The Subtraction Instinct (Mike Fisher)

Software teams add by default because the incentives are lopsided. Adding gets you a launch and a promotion line, while removing just earns you an enemy the moment anything breaks. Mike Fisher backs this with a Nature study showing people barely think of removing, even when it’s free and works better. So the real work is making subtraction someone’s actual job, and rewarding a good cut the way you reward a good launch.

Quality of Hire: A Short History of a Metric We Still Can’t Agree On (Gerry Crispin / CXR)

Gerry Crispin helped write the ISO standard for quality of hire, and even he says almost nobody measures it the same way twice. There’s no agreed formula, and that’s deliberate. A good sales hire and a good exec just aren’t measured on the same things, so the standard hands you a structure and leaves you to define the rest for your own roles. It’s a clear-eyed history of why the metric stays so slippery, worth a read if you’re trying to prove your hiring actually works.

The Elephant in the Brownfield (Subbu Allamaraju)

Every company announcing it’s going AI-native hits the same wall, and Subbu Allamaraju says that wall is identity rather than technology. Big orgs are built from lanes and sign-offs that tell people who they are at work, and AI adoption runs straight into it. He references a study of 951 companies where the “technology worked” but the “value didn’t arrive.” You can’t push AI through that wall. The only real lever is raising people’s willingness to work a different way.

Stealing Blame (Aviv Ben-Yosef)

Stealing blame is the harder half of leadership. You publicly own your part when something breaks, even if it wasn’t really your mess. Aviv Ben-Yosef argues that it earns you honesty, because people speak up once they know you’ve got their back. Read it before the next thing goes sideways on your team.

Why Is Everyone In Tech So Sad? (Aaron Horwath / Noema)

Your best engineers are quietly fantasizing about goat farms and pottery. As AI takes over more of the work, people are asking whether their job ever really mattered, and even the senior, well-paid ones feel it. The uncomfortable part for a leader is that comp won’t fix this. What holds people is work whose impact they can actually see.

Culture doesn’t execute strategy--people do (Elizabeth Loutfi-Hipchen / Chief Learning Officer)

Your most talented team will still stall if every real decision has to climb three approvers before it counts. The author reminds us that your real culture shows in who gets to make a call without asking permission, more than in any values on the wall. So when a strong team keeps stalling, look at the approval chain before you touch the roster.

About Exec Engineering

I’m Yassine 👋 I spend a big chunk of my time digging into engineering leadership, talent, and craft, plus how AI impacts all three. I share the most valuable resources I come across in this newsletter every Thursday, all curated by hand.

How I Decide Whether to Split a Team | Exec Engineering #206

Yassine Kachchani — Thu, 20 Aug 2026 13:01:21 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

How I Decide Whether to Split a Team (Csaba Okrona / Leadership Garden)

When a new strategy shows up carrying a stack of bets, the reflex is to split the team by the number of bets, a sub-team for each one. Csaba Okrona says the number of bets is the wrong variable to divide on. What actually gates the split is how many leaders you have ready to run the new teams. Because while hiring an engineer takes a quarter at most, finding a lead who carries your codebase, your domain, and a real read on your people takes far more than that. It is the clearest guide I have read to a call most people still make on gut feel.

The Case for Hiring Junior Engineers (Luca Rossi / Refactoring)

A team is a system, and juniors are how you invest in it. They cost less and hire faster than the seniors everyone is fighting over, they force a mixed team to make its process explicit, and the strong ones grow into the very seniors you will be scrambling for a year or two from now. Freeze that pipeline to go senior-only and you just push the bill down the road. A refreshing read against all the hire-seniors-only-because-AI noise right now.

TBM 437: Tokens, Hours, Points, and Other Curious Proxies (John Cutler / The Beautiful Mess)

Every board suddenly wants a number for what its AI tokens are buying (Return on Tokens). It is the same trap leaders hit with tracked hours and with story points, and it breaks the same way every time. Whatever is easy to count becomes the thing you manage, while the value it was meant to buy slides off the table. Tokens are the easiest thing yet to count, which is what makes them dangerous. If you have to defend the AI spend, measure the whole path to a real outcome, because the easy number will lie to you.

How to Steady a Team You Cannot Save (Louise Deason / Technically Feasible)

In an org that is visibly falling apart, it’s tempting to shield your team and promise them it will all be okay. It is also the fastest way to lose them. They already see the leaders leaving and the good people resigning, so the moment you say everything is fine, they move you into the group of people they can no longer take at their word. The harder, better move is to admit you don’t know, or decline to answer, but never to tell them something you both know is false.

Why High Performers Need Mentors More as Their Careers Advance (Dave Anderson / Scarlet Ink)

Getting a mentor is usually framed as something for when you’re stuck. The real use is to borrow judgment you haven’t earned yet. That is why your best people need it more as they rise: the higher they climb, the more their problems get harder to even recognize, let alone solve. And unfortunately, that is exactly the kind of help they tend to talk themselves out of asking for.

Nobody Is Coming To Tell You To Go (Aviv Ben-Yosef)

Executive coach Aviv Ben-Yosef has a simple test for leaders who can’t tell whether it’s time to quit. Picture waving a wand so that tomorrow you’re out of the role, with no fallout. Would you take it? He says almost nobody answers yes outright, but if you find yourself hesitating instead of brushing it off, you’re probably more checked out than you want to admit, and that is your cue to accept it and go. And often what you’re blaming on AI burnout or FOMO is really a fixable problem in disguise. Sometimes leaving is right, and just as often it’s a cop-out.

R.I.P. Your Backlog (Michael Lopp / Rands in Repose)

Your backlog is where the boring but necessary work goes to die, because people only ever pull the interesting tickets off it. Agents don’t have that hangup, they’ll grind through the dull stuff nobody was ever going to get to. The real question now is what’s sitting in your someday pile that suddenly makes sense to do, once boring gets cheap.

Landing the plane (James Stanier / The Engineering Manager)

Most of the real risk in a project hides in its last ten percent, the slow grind after the exciting work is done, when the finish line somehow keeps drifting further away. That is where good projects quietly die. As James Stanier puts it, “95% done is the most expensive state a project can be in.” You have paid for the whole thing and shipped nothing. He treats finishing as its own skill, one that teams rarely value, and shows how to actually land the plane.

Headed for the Exit: the Great Engineering Leader Career Break (Gergely Orosz / The Pragmatic Engineer)

The top engineering seat is turning into a cleanup job. A founder, high on what AI lets them ship, drops a 60,000-line pull request into the product. Now the CTO has to make it safe without becoming the one who says it can’t be trusted. When the work is covering for code nobody can vouch for and craft stops counting, the seat loses its point. That is why they leave. Gergely Orosz talked with nearly twenty leaders on or weighing a break, and six in ten said they are on their way out too, several with nothing lined up.

About Exec Engineering

Yes you can measure engineering | Exec Engineering #205

Thu, 13 Aug 2026 13:01:57 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Yes you can measure engineering (Jade Rubick)

Ask most engineering leaders if you can measure their team and you’ll get a shrug, because any simple number gets gamed the week it hits a dashboard. Jade Rubick thinks you can. He came up with a metric he calls ValueSum, which scores each thing you ship by how much it moved customers, then adds those scores up. Piling on low-value work barely moves it, so it’s much harder to game, and it also shows whether your AI tooling is lifting real value or just more volume.

Zugunruhe: Why your best people get restless, and what to do when they start facing the window (Mike Fisher)

When your best engineer turns restless, the easy read is disloyalty. Mike Fisher borrows a word from biology for what’s actually happening. Zugunruhe is the restlessness migrating birds feel when the seasons turn, an urge wired into them no matter how good the cage is. Most leaders either throw money and a title at it or say nothing and hope it passes, and both lose the person. The fix is actually asking where someone really wants to go, even if the answer is somewhere else. Do that well and you become the leader the best people keep coming back to.

Engineering managers are back in the codebase (Chantal Kapani / LeadDev)

The player-coach prediction just turned into hard data. Hands-on work among engineering managers jumped from 20% to 35% in a single year, and it’s happening at every level, from tech leads up to CTOs. The real question is how far back in you should go before you turn into just another engineer on the team.

Trust is Built One Bag of Clementines at a Time (Deb Liu)

A tight, loyal team can feel like high trust from the inside. Deb Liu’s warning is that it often isn’t. When a group circles the wagons and trusts only its own people, that loyalty is really low trust in miniature, pushed down from the whole company to your one corner of it. Real trust gets built the slow way, in the small moments where you did exactly what you said you would. She names the few things every high-trust group shares, worth a read before you take your team’s loyalty at face value.

The Big Management Lie: Overpromising (Stay SaaSy)

Here’s a lie that kind, capable managers tell without noticing: they promise a promotion they can’t really guarantee, and to an optimist it barely feels like lying. The promise buys a day of good feeling, and if it falls through, their morale craters to a lasting one out of ten that takes years to recover from. The author’s answer is to caveat every forward-looking promise like a paranoid lawyer, which is stricter than how most managers are used to talking.

Comprehension as an Architectural Characteristic: A System That Is Not Understood Cannot Evolve Safely (Jacobus Meintjes and Narayana Ren / InfoQ)

Writing code used to hand you understanding for free. You couldn’t ship it without first working out how it behaved. LLMs removed that effort and took the comprehension with it, so you can get code that clears every test while nobody really understands it. This piece argues you now have to build that understanding on purpose, before the code is generated. The piece names the early signs that your team’s grip on the system is slipping, and how to spot it before it blows up in production.

Happy Teams Build Better Software (Angel Cervera Claudio)

After nearly thirty years building distributed teams, Angel Cervera Claudio makes the case that a happy team has almost nothing to do with perks. What actually keeps good engineers steady is clarity. Ambitious goals don’t wear people down. Unexplained change does, and so does a company that can’t say where it’s going. He spells out what real clarity looks like day to day, and why it holds a team together when the perks can’t.

Middle management roles are also a trap (Will Larson / Irrational Exuberance)

Balancing pressures and keeping the process running gets you promoted into middle management. But those same skills can quietly stall you at the top. A great executive runs on deep domain expertise and driving execution instead, and you sharpen those faster as a hands-on line manager than in the middle. Worse, the filters that reward good middle managers often screen out the people with the best shot at the exec seat. So if that seat is the goal, protect the years closest to the real work.

About Exec Engineering

Should we still design code for humans? | Exec Engineering #204

Yassine Kachchani — Thu, 30 Jul 2026 14:51:19 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Should we still design code for humans? (Valentina Servile / Thoughtworks)

Good design still matters even when agents write every line of code. Agents learned from human-written code, so they trip over the same messy systems we do. The bad-design tax just moved from your team’s hours to your token bill, it didn’t disappear. Which means, maybe for the first time, you can put a real dollar figure on tech debt. Valentina Servile’s case for why someone still has to stay close to the code, even when agents do the typing, is one of the sharpest I have seen on this.

Valentina Servile / Thoughtworks, “Should we still design code for humans?”

The Best Prioritization Is No Prioritization (Stay SaaSy)

I am vocal about strict prioritization, so this one got under my skin. Stay SaaSy makes the contrarian case that the best prioritization is almost none at all, and it is hard to brush off. Scoring frameworks like RICE are more vibes than science, and you can rarely prove your call was the right one anyway. So instead of grading every option, you design the work so most of those hard calls disappear. I am not sold, but it has me rethinking how much of my own prioritizing is really just theater. If you live in planning meetings, this one is worth sitting with.

How building software is changing at Anthropic (Gergely Orosz / The Pragmatic Engineer)

The most AI-pilled engineers on earth still work in two-pizza teams and still write real plans for their hard projects. That is the surprising part of Gergely Orosz’s reported look inside Anthropic. Going all-in on AI kept the fundamentals intact, but it quietly moved where the hard part of the job now sits. The same quiet shift is probably already underway on your own team, and most leaders will not notice until it has already slowed them down.

The rise of the forward-deployed engineer (FDE) (Kari McMahon / LeadDev)

The “Forward-Deployed Engineer” is suddenly the hottest title in tech. Postings are up more than 729% in a year, even while the rest of the software market keeps cutting jobs. But the label is spreading faster than the real thing, and plenty of firms now pin it on anyone who is customer-facing and a bit technical. What actually sets the real role apart is narrow and specific, and most firms racing to add the title have no idea which version they are building.

Two Bars, Spreading Apart (Subbu Allamaraju)

Subbu Allamaraju, a veteran engineer and former VP of Engineering at BILL who has put the engineer hat back on, spent the past few months building with an AI harness and came back with an uncomfortable read on careers. As the cost of building drops toward zero, the bar to get in drops with it and the bottom crowds up, while the bar for excellent work climbs out of reach. The comfortable middle, where most careers have quietly sat, is what thins out. He is blunt about what still separates the people who stay at the top, and he does not soften it.

Subbu Allamaraju, “Two Bars, Spreading Apart”

(By the way, I interviewed Subbu for my Dialog series a while back, on leading through the shift to AI. The full conversation still holds up.)

TBM 433: The Border Collie Faustian Bargain (John Cutler / The Beautiful Mess)

You can usually spot when leadership’s strategy is not really a strategy, long before anyone else in the room. John Cutler’s uncomfortable point is that this same clarity is what slowly pulls you in. To keep your influence, you stop pushing back on the confusing strategy and start selling it to your own team, until you are defending it to them better than the leaders who wrote it. He maps the quiet, reasonable steps that get you there. Read it before you take the first one, because you rarely feel yourself taking it.

Designing For Healthy Conflict in An Engineering Team (James Samuel / Effective Software Leads)

Every time you step in to settle a fight between two engineers, you quietly teach the team that the hard calls belong to you. So the better you referee, the more they wait for you to do it. James Samuel’s fix is to make yourself less necessary. He lays out a three-level system for getting there, and the idea that stuck with me is catching the small tensions early, while they are still easy to defuse and long before they turn into the kind of fight you have to break up.

The Dark Arts of the Meeting Room (Jeff / JoT)

Some people are never to blame when things go wrong and somehow always central when things go right. Jeff’s field guide names their tricks, like committing to “improving quality” without ever saying what quality means, or announcing that incidents are up 50% while leaving out that they went from two to three. Once you can name the tricks, you cannot unsee them. The essay closes with the plain questions that quietly disarm every one.

About Exec Engineering

Engineering managers are paying the price of rising expectations | Exec Engineering #203

Yassine Kachchani — Thu, 23 Jul 2026 13:00:09 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Engineering managers are paying the price of rising expectations (Diego Quiroga / LeadDev)

If you manage engineers, the list of expectations keeps growing. Ship faster with AI, stay close to the code, coach people, influence other teams, think more strategically. Each ask is fair on its own, and that is the trap, because your attention is finite and they are all expanding at once. Something is already getting dropped every week whether you admit it or not. Diego Quiroga’s move is to make that trade out loud, so your team and your own boss have something real to push on.

A Framework for New Managers Starting a New Role (James Samuel / Effective Software Leads)

The instinct in a new manager job is to prove the hire fast, so you weigh in and start making calls in week one. But what actually decides how it goes is invisible. Every company runs on an unwritten system, how decisions really get made and which behaviors quietly get rewarded, and none of it is in the handbook. Learning that system, James Samuel argues, beats any visible week-one win. Act against it by accident and you stall before you have really started.

The cost of saying yes has changed (Dalia Abuadas / The GitHub Blog)

The priciest part of a small feature used to be writing the code. Now it is often the meeting about whether to write it at all. Dalia Abuadas has a better move for that stuck debate. When an agent can draft the code in the time the team spends arguing over whether to bother, stop guessing and look at the real diff. You find out in thirty minutes what used to take two days. Her one caution is about ownership. Code being cheap to generate does not make a change cheap. It is only cheap when a person can confidently review it and stand behind what it does.

What I’d Tell My Team About Competition (Stay SaaSy)

You will hear, usually from rich people who joined a monopoly like Google late, that competition does not matter and that even watching your rivals is a little weak. Outside of a monopoly, that is bad advice. In B2B you win deals one at a time, house to house, and your win rate is the whole game. A rising one funds the next hire; a falling one starts the slide toward layoffs. This is a blunt script for a leader who needs a team to take its rivals seriously again, with no shame about it.

The competence illusion: Inoculating ourselves against the quiet cost of AI (Matt Donovan / Chief Learning Officer)

AI can leave you turning out sharp, expert-looking work while the skill underneath never really forms, so the competence you feel disappears the moment the tool does. Matt Donovan, who has spent 25 years in learning and development, felt exactly that deep in a research project with Claude, catching himself thinking, “I really understand this material now.” Then he stopped. Did he actually understand it, or just what the tool had organized for him? He calls it a new, fifth stage of competence. His guard is to do your own first pass, before any model gets to shape what you think.

You Didn’t Hire a Slow Team (Aviv Ben-Yosef)

The headline is the whole point. When a product team feels slow, Aviv Ben-Yosef says the cause is rarely talent. It is that nobody set the appetite, the worth of the outcome and the line where good enough stops. Name that, and the work becomes finishable.

TBM 431: The Denominator That Matters (John Cutler / The Beautiful Mess)

Whether an AI mandate actually takes hold comes down to something most leaders skip, a social contract. That is the plain promise that the gains from working faster will not be used against the people who created them. John Cutler’s point is that without that promise, resistance becomes the rational move. People are protecting themselves, and often reading the shaky evidence more accurately than whoever is pushing the tool on them. Get the contract wrong and no amount of training or skill on top will save the rollout.

About Exec Engineering

How to hire engineers for strong judgment and taste | Exec Engineering #202

Yassine Kachchani — Thu, 16 Jul 2026 13:04:09 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

How to hire engineers for strong judgment and taste (Sage Lazzaro / LeadDev)

Agents now write most of the code. So hiring on whether someone can write it themselves tests the wrong thing. What matters is judgment. Can a candidate look at what an agent built and tell whether it is any good, and explain the calls they made? Sage Lazzaro talked to leaders tearing up their interview process to screen for that. The red flag they kept naming is the candidate who cannot explain their own decisions. Worth a read if you are restructuring your engineering team to be AI-native.

Code Yellow, Code Red (James Stanier / The Engineering Manager)

Every leader has called something the top priority and watched nothing change. The phrase is too vague, so other teams just argue theirs matters more. James Stanier’s fix, borrowed from Google, is to give the emergency a shared name, a Code Yellow. Once everyone knows what one means, you stop debating whether it deserves attention and just move. The shared word does more than the war rooms it sets off. He covers when to call one, and when it is a Code Red instead.

Ownership (Thorsten Ball / Register Spill)

Most teams use the word ownership without ever saying what it means. Thorsten Ball wrote the definition worth handing to your team. Owning a problem means carrying it end to end, from the first sign of trouble to the point where, in his words, “we don’t have to think about it again.” That gives you a real bar to hold people to, instead of a nice value nobody can measure. He wrote it for his own small team, and it travels well past them.

Adapting to AI: Leadership (Colin Breck)

The routine, box-ticking side of management is the first thing AI will take over, and it may well do it better than you. Colin Breck’s point is that this leaves the human side of leading as the part that actually sets you apart. That means knowing your people and showing them what great work looks like. A calm, non-hype take on where a leader should spend their time now.

Tech jobs market in 2026, part 3: hiring managers & job seekers (Gergely Orosz / The Pragmatic Engineer)

Gergely Orosz talked to more than 50 hiring managers and job seekers. The picture they paint is just plain weird. Good engineers get ghosted while managers swear there is no talent out there. AI-polished resumes have wrecked any trust in the inbox, so the two sides cannot find each other.

TBM 428: Yes, Robot. Yes, Boss? (John Cutler / The Beautiful Mess)

By now everyone agrees AI amplifies the culture you already have, so John Cutler makes a darker point. The tools are now good enough to carry out your worst intentions and make them sound kind. He shows a manager asking AI to write a performance review that reads as caring and fair. The real goal is a clean paper trail to push someone out. On a healthy team AI clears real drag. On a political one it just automates the sugarcoating, faster and with better manners.

When Nothing Happens (Mike Fisher)

Why does bad behavior slide for years and then suddenly cost someone everything? Mike Fisher hangs his answer on Steve Jobs and the MobileMe meltdown. As he puts it, “We don’t punish behavior. We punish behavior in context.” And the context that buys the most tolerance is good numbers. Strong results quietly excuse how a leader treats people, right up until the results stop.

Make no assumptions (Will Larson / Irrational Exuberance)

AI is very good at producing analysis that looks solid and is quietly, completely wrong. Will Larson pulled his team’s incident data and it looked off. The tool had silently dropped half the incidents. Trust it, and he would have sent the team chasing a problem that did not exist. So the first thing he tells new hires now is to make no assumptions. The real job of leading is getting into the details yourself.

About Exec Engineering

The Rewrite That Actually Worked | Exec Engineering #201

Yassine Kachchani — Thu, 09 Jul 2026 15:52:27 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

The Rewrite That Actually Worked (Roman / High Impact Engineering)

System rewrites are the project every leader watches die at 80% done. Roman, a startup CTO, shipped his in three months with an AI coding agent. For once, the estimate held. It held because of the setup around that agent. The agent is only a multiplier, he says, but “your environment is the exponent.” Instead of static Figma mockups, they built working prototypes the team could click through. That surfaced the real edge cases before production code. Point a raw agent at your mess and you get a faster mess.

The Engineer in the Half-Space (Yusuf Aytas)

Some engineers do their best work as the absence of a problem. Think of the outage that never fired, or the migration that did not break on old customer data. Yusuf Aytas calls this person the gap reader, the one who spots the missing owner and closes the gap before it gets costly. The catch is your hiring keeps passing on them. Your interviews score algorithms and system design, and this is neither. It looks like someone asking plain, practical questions. Worth reading to spot the people your process misses.

In defense of AI mandates (Charity Majors)

Most AI mandates deserve the hate they get. Charity Majors makes the case for the rare good one. A real mandate is the leader giving people cover. It admits some deadlines will slip while the team learns to really build with AI. It promises the team will not carry that slip alone. Skip it and you have told people to pick up AI on their own time. So pick a lane. If you are going to force it, reality had better prove you right in a hurry.

How to think about span of control (Jade Rubick)

There are two ways to shape an org. Leaders usually go flat to move faster, with fewer layers and quicker calls. But flat is not free. It clears the tangle of extra layers only to drop a heavier load onto your front-line managers, who each run far more people. It pays off only when you have set up the right conditions first, and Rubick is sharp on what those are. Flatten without them and you just move the pain downhill.

AI productivity is burning out your best engineers (Sreenivasa Reddy / LeadDev)

Your fastest team might be quietly losing its middle. Juniors and seniors get a real lift from AI. But someone still has to catch the confident nonsense the model hands back, and it is almost always your mid-level engineers. One of them told Sreenivasa Reddy why she quit. “I cannot handle this pressure of making things right without any credit for it.” Reddy lost three of the team’s best inside two months, and never saw it coming.

Stop Lying to Your Cofounder (Aviv Ben-Yosef)

Padded estimates feel harmless, so Aviv Ben-Yosef ran the math. The engineer pads a task by 20% to feel safe, then the manager pads it again, then the VP piles on more. Stack those hidden cushions and you spend almost half your R&D capacity protecting the team from itself. And trust does not fade slowly. One caught white lie colors everything you ever said. So hand over your real estimates with the risks spelled out, and bring your own bad news early, before anyone has to dig for it.

If You Can’t Be Replaced You Can’t Be Promoted (Dave Anderson / Scarlet Ink)

The fastest way to get stuck is to be the only one who can do your job. Dave Anderson made hiring his own backup his first move, and got promoted right on time. Stay the one nobody can replace, and you stay too valuable to move.

The Four Core Areas of Responsibility for an Engineering Manager (James Samuel / ESL’s Newsletter)

You have seen the manager job split into people, product, delivery and technical work, so that is old news. The real point is simpler. Your job is to make the team greater than the sum of its parts. So where you spend your time shifts with whatever the team needs most.

Dialog

I asked Manuel Drews, Director of Engineering at Native Instruments, why AI has made so many teams faster at building without shipping value any faster.

His take is that doubling your build speed mostly drags the real bottleneck into view. If the deciding and the customer-adoption around it stay just as slow, you have only shifted the jam somewhere new.

We also got into why a struggling team is usually badly shaped rather than short on talent, and what he does to fix one. A good read if your dashboards look faster this year but the outcomes have not moved.

About Exec Engineering

I’m Yassine 👋 I spend a big chunk of my time digging into engineering leadership, talent, and craft, plus how AI impacts all three. I share the most valuable gems I come across in this newsletter every week, all curated by hand.

When AI Costs More Than the Engineer | Exec Engineering #200

Yassine Kachchani — Thu, 02 Jul 2026 13:04:15 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

When AI Costs More Than the Engineer (Tomasz Tunguz)

Anthropic spends 2.3 times its whole payroll on raw compute. The number worth watching is what you pay in AI for each engineer. Today the top 1% of firms spend about $89k per engineer, close to 40% of a senior salary, while the middle spends $137 a year. Tunguz maps three ways that gap could close by 2029, and past a point the AI bill stops being optional. Worth a read to see which of those futures you are paying for.

Killing a project is every engineering leader’s hardest call (Alessandro Bahgat / LeadDev)

Your job is to fight for your team, which is not the same as fighting for every project they are on. Bahgat defended one at Google for years before it got cancelled, and what he felt after was guilt, for keeping good people on a dead end. He now runs new bets past a few plain questions first. When you cannot say why us, or what you give up to do it, you have your answer.

AI Demands More Engineering Discipline. Not Less (Charity Majors)

A model can now write fine code for almost nothing, so the hard part moves to reviewing it and owning what it hands you. Charity Majors argues this asks for more care than before. A sharp reply to anyone who thinks cheap code lets a team get sloppy.

So You Want to Fix Your All Hands (Michael Lopp)

Half your team quietly thinks the All Hands wastes their time, and the real reason is easy to miss: it has slowly become a meeting about the leader, not the room. The fix flips that: curiosity keeps people awake, so you build the hour around what they actually want to know. Steal one rule today and cap it at 90 minutes. How to fill the rest is the part worth reading.

The 5 Impacts of the Owner-Operator Model on On-call, Operations, and Incentives (David Anderson)

Every year Amazon froze all code over the holidays, and outages dropped by about ten times. That fits what the data shows, since most outages start with a recent change. So the surest fix for quality is to put whoever wrote the code on call for it. A 3am page from your own bug teaches more than any lecture can.

Is AI unbundling expertise? (Matt Kamelman / Thoughtworks)

The clearest read yet on Anthropic’s big study of 400,000 coding sessions, and it lands somewhere odd. What the tool rewards is not how much you know. It is how well you can hand your thinking to a machine. The accountant who knows the exact rules a script must follow beats the junior dev who cannot say what he wants. So the thing to grow in your people is the habit of spelling out how they think.

Default to Lazy (Aviv Ben-Yosef)

Larry Wall called laziness a good trait in an engineer. Aviv Ben-Yosef makes the same case for whole teams. People who never slow down fill the gap with busy work and tie their worth to raw output. Reward the ones who quietly solve a thing once over the ones who love to play hero.

When Impressive Performance Gains Do Not Matter (Colin Breck)

A query cut from 10 minutes to 1 sounds huge, and Colin Breck explains why your users will not feel it. Past about 10 seconds, people go check their phone, so 10 minutes and 1 minute land the same in their day. A good gut check before a 10x number goes on a slide. Does it cross the line where someone would notice?

Dialog

I recently talked to Manuel Drews, who runs engineering at Native Instruments, about the moment a leader’s hard-won instincts quietly stop working.

His case is that the playbook you trusted at one size quietly breaks as the org changes, and rarely with a bang. It creeps in as plain friction, easy to blame on the wrong thing.

Take a team that looks broken. His read is that it is usually just badly shaped, and the giveaway is that the smart, motivated people inside it keep struggling anyway.

In the full conversation he gets into what to do about a team like that, and where he draws the line on the rush to ship faster with AI.

About Exec Engineering

I’m Yassine 👋 I spend a big chunk of my time digging into engineering management and talent acquisition, especially where the two overlap. I share the most interesting resources I come across in this newsletter, all curated by hand.

Your Instincts Stop Working the Moment Your Org Changes | Manuel Drews, Director of Engineering, Native Instruments

Yassine Kachchani — Tue, 30 Jun 2026 14:44:13 GMT

This week’s guest is Manuel Drews, Director of Engineering at Native Instruments, a Berlin-based company that makes software instruments and hardware controllers for musicians, producers, and DJs.

Manuel has been at Native Instruments for over sixteen years, working his way from Software Engineer to Director of Engineering. Seven years into his tenure, as Chapter Lead, he co-designed the company’s career framework for engineers, a process that shaped his thinking on what it actually takes to create the conditions for growth, not just define it.

He writes regularly on engineering leadership on LinkedIn, covering org design, career development, iterative delivery, and the structural roots of team dysfunction.

Takeaways

Career frameworks fail when they describe growth but don’t create room for it. A Staff Engineer path that requires cross-team influence means nothing if senior engineers are fully allocated to roadmap work.
Org design problems have long feedback loops. They don’t fail loudly on day one, they accumulate as coordination overhead and ownership confusion, until the structure itself becomes the bottleneck.
Leaders without an org design mindset tend to misdiagnose structural problems as people problems, and reach for solutions that can’t fix what’s actually broken.
AI speeding up implementation doesn’t speed up value delivery if discovery, decision-making, and adoption stay the same.

Yassine: You’ve written that when one engineer is consistently outpacing their peers, that’s often less a talent story and more a signal something structural hasn’t been solved. How do you actually act on that insight in the moment, when the instinct to celebrate that person is completely natural?

Manuel: My default is still to celebrate them. High performance deserves recognition, and in most cases I’ve found that these people are acting in perfectly good faith and genuinely want the project to succeed.

The key is to be mindful of what I celebrate: their dedication, ownership, mastery and technical judgment, the ability to deliver under pressure, not the individual heroics.

In the same breath, publicly, I name what wasn’t great, but without putting it on them: “This project asked far too much overtime of you, please take that time back over the next few weeks,” or “It’s on me to make sure the load is spread better next time.” That signals to the whole team how I actually want things to work, and that I own the fix.

In private, I thank them again, so they know the appreciation is real and not just a public gesture. But I also use that setting to discuss the flipside of becoming indispensable: their impact is genuine, but precisely because it’s so concentrated in one person, it’s a risk we need to address. For their sake as much as the team’s. Then I ask for their help building a plan to spread that capability, and I make executing it part of their growth and performance goals. So the work of fixing it is recognized work that helps them in their career, not an extra burden.

That way the engineer hopefully feels genuinely appreciated, and the organization learns from their success instead of quietly depending on it again the next time.

Yassine: As Chapter Lead you co-created a career framework for engineers at Native Instruments, that’s a different kind of work than managing a team or shipping a product. What did building that framework teach you about what engineers actually need to grow, that you wouldn’t have learned any other way?

Manuel: The biggest realization for me was that defining growth, complex as that already is, is still kind-of the easy part. Creating the conditions for growth is much harder.

When we sat down to discuss and align our perspectives, it became increasingly clear to me that the career framework itself is only one part of the puzzle, it can’t live in isolation. We could write down the perfect set of expectations for each level, if the day-to-day reality doesn’t allow engineers to actually meet those expectations we’d either create frustration or incentivize a ‘promotion-driven development’ culture where people chase checkboxes instead of meaningful impact.

For example, if becoming a Staff Engineer requires influencing the technical direction across teams, but the senior engineers are fully allocated to delivering roadmap work in their own teams, we’d have created a conflict of interest that pits their career goals against their team’s success.

So, my takeaway was: career growth requires opportunity, not just clarity. Engineers not only need well-defined expectations and feedback, they also need access to experiences that let them demonstrate and build those capabilities. That’s my responsibility as a leader: I need to deliberately create those opportunities, so that engineers can develop on the job, instead of squeezing growth into their evenings and weekends.

Yassine: In “The Great Scope Wars” you write that getting leadership to trust the iterative path requires “a leap of faith” from them, they give up the “comforting illusion of upfront certainty.” What do you actually give them in return? What does that conversation look like when someone above you genuinely needs to see a plan?

Manuel: First, let me clarify one thing that I didn’t bring across well in the article: I’m not against having a plan. Quite the opposite: I think every project needs a clear plan that states the goals, priorities, key trade-offs, and current assumptions. Without that, you can’t meaningfully decide on “the next most important thing”.

The key question is: what does that plan look like? Is it a Gantt chart with fixed dates, treated as a commitment? Or is it a living reflection of our current best thinking, our priorities, the risks we see, the sequence in which we intend to tackle topics, roughly how long the next steps might take, updated continuously as we learn?

When a leader asks me for a plan, the latter is what I give them.

I won’t pretend that it’s always an easy sell, nor that I’ve always been successful here. Naturally, the benefits, less overhead, lower stress, earlier validation of business value, and reduced delivery risk, only become obvious over time, while the leap of faith is required upfront. And the higher the stakes and investment, the more people want visibility into progress and confidence that the project is on track. They all need to buy into this approach. It’s also not only leaders and product managers. There are also engineers who feel deeply uncomfortable not knowing exactly what they are supposed to deliver.

It’s probably one of those things you can’t fully embrace unless you’ve experienced it. So my current best thinking is to gradually build these habits during lower-pressure periods when the perceived risk to the bottom line is low. Once the routines and habits are established and people have seen them work, it’s far easier to convince them to maintain that way of working even when the pressure picks up.

So, my goal isn’t to eliminate planning; it’s to replace the illusion of certainty with transparency, evidence, and continuous course correction.

Yassine: Most engineering execs learn delivery, people management, maybe strategy. Very few are taught to think explicitly about org design. In your experience, when does that gap start to hurt, what’s the moment where not having that muscle becomes the actual problem?

Manuel: My short answer would be “change.” It’s the moment when yesterday’s successful playbook stops working, even though nothing obvious appears broken.

As long as the environment stays relatively stable, leaders can often rely on intuition and the practices that made them successful in the past. But when the company scales rapidly, goes through a merger, or the leader moves into a new org, those instincts stop being reliable. That’s all the more true if the leader ‘grew up’ in a highly functional environment they didn’t have to shape themselves, where they inherited a structure that worked without ever having to understand why it worked.

The tricky part is that organizational problems have very long feedback loops. A structural issue rarely fails loudly on day one. Instead, it shows up gradually as more coordination overhead, slow and unclear decision-making, ownership confusion, or a general sense of friction and slowdown. Without an org-design mindset, it’s easy to conclude that the people or the processes are the problem, and the temptation to fix those symptoms with straightforward-looking ‘solutions’ is strong.

I believe that the companies in our industry are mostly full of smart, motivated people. When people like that consistently fail to collaborate well, the problem is often less them than the structure they’re working inside. And that’s when the missing org-design muscle becomes the real problem, because optimizing meetings or adding task forces will not fix that structure.

Yassine: You write a lot about the gap between how orgs say they make decisions and how they actually make them, through structure, incentives, role design. What’s the conversation you think engineering leaders at most companies are still avoiding, especially in 2026, as the industry is being disturbed significantly?

Manuel: I’ll say upfront that I don’t envy executives and senior leaders these days. The pressure they’re under must be immense, and the temptation to reach for quick, easy ‘solutions’ must be enormous. Kudos to every engineering leader who manages to resist this to some degree.

That said, there are two conversations I don’t hear nearly enough, at least in public discourse.

The first is the old ‘output-vs-outcome’ discussion. We’re spending enormous energy discussing how AI changes software development productivity and what that means for engineering orgs. But writing code is still only one step in delivering business outcomes. If AI makes implementation twice as fast while product discovery, decision-making, governance, and customer adoption stay the same, we’ve mostly just moved the bottleneck somewhere else. So for me, the strategic question we’re not asking nearly enough is: “How do we redesign our organizations to create value faster?”

The second conversation I am missing is about capability building. I absolutely believe the role of software engineers will change significantly, but I don’t think we will be removing humans from the loop anytime soon. If anything, human judgment will become more important: deciding what to build, making architectural trade-offs, navigating ambiguity, managing complexity, and deciding what constitutes good software in the age of AI.

That raises a question I’m not the first to ask, but one I rarely see tackled strategically: where will those experienced engineers come from if today’s juniors never get the chance to develop those skills? In our excitement about maximizing today’s productivity, we risk underinvesting in the development of tomorrow’s technical leaders. So, I’m less worried about AI replacing experienced engineers than I am about us accidentally stopping the process that creates them.

📚 Manuel Drews’ Go-To Resources:

3 people I follow and recommend:

John Cutler (“The beautiful Mess”) - the Systems Thinking inspiration for me. Lately he’s often a bit too abstract for my taste, but still a great source of inspiring ideas and concepts
Simon Sinek - For me one of the definitive authorities when it comes to what it means to be a leader
Johanna Rothman - lots of insights and practical ideas around true agile work management.

1 podcast I make time for:

“Work Life” / “Re-Thinking” by Adam Grant.

A newsletter I rarely skip:

“The Pragmatic Engineer” by Gergely Orosz

A book I recommend:

The book that first pushed me to seriously think about organizational design and better ways of structuring work - and has therefore had a significant influence on who I am as a leader today is “Reinventing Organizations” by Frederic Laloux.

Thank you Manuel for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

Yassine.

The Anatomy of an AI-Native Org | Exec Engineering #199

Yassine Kachchani — Thu, 25 Jun 2026 13:02:30 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Every hire is a bet made in the dark (Andrew Marritt / Working Ideas)

In his piece, Andrew Marritt argues that the external candidate pool is skewed toward people whose current employer was willing to lose. Strong performers get retained. What reaches your pipeline is what’s left. The firms that figure this out stop relying on credentials and build assessments that actually work, it’s the only way to find signal in a biased pool.

Here’s The Rub: We Don’t Believe You (Michael Lopp / Rands in Repose)

The biggest asset a new senior engineering leader brings is fresh eyes, they haven’t been absorbed by the chaos yet. That fading window is when you see what everyone else stopped seeing. Use it before the organization beats it out of you.

Don’t Stack Weaknesses (Stay SaaSy)

Some leaders clone themselves more than they admit. They hire for “values” but evaluate for the skills they recognize, which are the skills they have. Stack that pattern two levels deep, and the weakness becomes structural, invisible, and very hard to undo.

Revised rules of engineering leadership. (Will Larson)

Will Larson argues that AI made individual engineers dramatically more powerful, but the organizational fundamentals haven’t changed. Durable teams with deep domain context still outperform rotating talent, bad architecture still slows you down, and the CTO who can’t make fast, binding decisions becomes the bottleneck.

Why is Meta destroying its engineering organization? (Gergely Orosz)

Meta had one of the strongest engineering cultures in the industry. Then leadership reassigned 4,500 engineers to data labeling, started tracking every keystroke, and tied performance reviews to AI token usage. Gergely Orosz traces exactly how that chain of decisions led to the most embarrassing security breach in the company’s history.

Key activities for sustainable engineering team (Dunya Kirkali / Incremental forgetting)

Knowing when to get close to the work and when to pull back is one of the least discussed parts of engineering management. This article builds a clean framework for it: internal signals for team momentum, boundary signals for org fit, and external signals for environmental shifts.

The Anatomy of an AI-Native Org (Ajey Gore)

One of the sharpest takes on what AI actually changes inside an org. We spent thirty years pretending that the how was the work, because the how was where the headcount was. The headcount is moving. The org chart will follow, and the teams that figure out the new shape first will look unrecognizable to their competitors.

AI and the illusion of velocity: fixing the value stream first (Wille Faler / The Principal Engineer)

The same issues slowing down software delivery in 2026 were slowing it down in 2006. Middlemen corrupting requirements, handovers dropping context, teams accountable for outcomes they have no authority over. AI just made all of that faster to run into.

Dialog

Allen Cheung, former SVP of Engineering at ujet.cx, shares why engineering output depends less on hiring “A players” and more on building environments where average engineers can consistently do great work.

He explains why AI adoption is pushing teams to finally invest in CI/CD, testing, and review discipline, how hiring for complementary strengths only works when teams have the humility to embrace different work styles, and why high team satisfaction can still hide mediocre business performance.

Check it out here:

About Exec Engineering

The Reliable Team Trap | Exec Engineering #198

Yassine Kachchani — Thu, 18 Jun 2026 13:01:10 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Reorgs happen (Ben Balter)

25 reorgs in 13 years taught one GitHub veteran what actually survives an org chart shuffle: reputation, relationships, and documented work. Help your team invest in those, and a reorg stops being something to fear and starts being something to use.

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

Good feedback is directional. Flag what went wrong, then point toward what should happen instead. That small shift, from correcting to directing, is what separates managers who develop people from managers who just evaluate them.

The people aspect of building high-performing teams (James Samuel / Effective Software Leads)

Motivation is the most important lever a manager has, and it only works when you understand it at the individual level. A manager who does not know what each person on their team is reaching for is essentially flying blind.

The Reliable Team Trap (Kevin Goldsmith / It Depends: Lessons in Technology Leadership)

The team that never drops the ball is the team nobody worries about. And the team nobody worries about is the team nobody consults. Being indispensable where you are is the quietest way to make sure you never go anywhere else.

The engineering manager role is splitting in two (Stephane Moreau / LeadDev)

AI is shrinking team sizes fast enough that small teams either need an embedded technical leader or no dedicated manager at all. That fork is what is splitting the EM role in two, and the preparation for each path looks nothing like the other.

How to Set Quarterly Goals That Your Team Actually Achieves (Karol Wójciszko / Engineering Leader’s Playbook)

Four things make the difference between a goal that gets achieved and one that gets abandoned: time blocked on the calendar, a concrete first step, visibility across the team, and an honest review at the end. Get all four right, and the goals that have been stalling for quarters will finally start moving.

The right kind of AI sceptic (James Stanier / The Engineering Manager)

Your engineers are watching how you engage with AI more than they are listening to what you say about it. A leader who shares real experiments, including the ones that produced nothing useful, builds a culture of genuine inquiry. A leader who mandates enthusiasm builds a culture of compliance.

What the Top 1% of Engineering Teams Do Differently with AI (Gregor Ojstersek / Engineering Leadership)

The top 1% of engineering teams spend more on AI tools than everyone else, and still deliver code at a lower cost per unit of output. They review specs before code gets written. They run AI code reviews and make human reviews optional. They deploy more frequently. Building systems that compound is what separates them from the rest.

Dialog

Check it out here:

About Exec Engineering

The CTO’s Comprehension Debt | Exec Engineering #197

Yassine Kachchani — Thu, 11 Jun 2026 13:03:17 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

The Last Technical Interview (Steve Yegge / Medium)

Technical interviews are a simulation. You spend a few hours watching someone perform, then make a years-long bet on it. Steve Yegge’s alternative, the “campfire model”, is already gaining traction in SF. Bring candidates in for a few paid days on a real codebase with a real team. The work counts twice: signal for you, and a portable record of verified output for them.

The Slide (Michael Lopp / Rands in Repose)

The author has a technique for the feedback that never lands. Instead of repeating yourself, you slide in with a story about the time you struggled with the exact same thing. Discomfort recognizes discomfort in a way that direct advice never does.

The End of the People Manager (Mirek Stanek / Practical Engineering Management)

For a decade, stepping away from the codebase was the price of leadership. AI just eliminated that excuse. The leaders who survive next will be the ones who stay close enough to the work to see where the product breaks, where users get confused, and where the system quietly fails.

The CTO’s Comprehension Debt (Etienne de Bruin / The CTO Substack)

Comprehension debt is what happens when you forward an artifact you never actually absorbed. AI summarization works fine for data. It breaks down the moment another human has to act on what you sent and needs your actual judgment, not a model’s best guess at what you might have thought.

Trust comes before any decision framework (Simone D’Amico / Lead Through Mistakes)

When people escalate decisions they clearly own, the instinct is to wonder about competence. Rarely the case. Psychological safety shapes how freely people can see the options in front of them, and rebuilding it starts with one thing: stop giving the right answer, and give them the context and permission to find it themselves.

What Interruptions Reveal About Company Culture (William Degbey, Benjamin Laker, Baniyelme Zoogah, Sanjay Kumar Singh and Ghulam Murtaza / HBR)

A study of 164 leaders found that the people being interrupted in meetings drew a very different conclusion than the people doing the interrupting. They learned whose voice carried weight in the room, adjusted how they spoke to avoid being cut off, and eventually stopped sharing ideas that were not fully formed. That behavioral shift is what turns a meeting habit into a culture.

Adapting to AI: Adapting Organizations (Colin Breck)

AI scales what already exists in an organization. The companies that will pull ahead are the ones that already have tight feedback loops, end-to-end ownership, and engineers who think across the whole system. For everyone else, shipping more code faster is not an advantage, but a liability that compounds.

How can engineering leaders calculate the return on their AI investments? (Lizzie Matusov / Research-Driven Engineering Leadership)

DORA put a number on AI ROI in engineering: 39% in year one. But that number only holds if you budget for a 15% productivity drop in the first three months. Most initiatives get killed during that window because leadership reads a temporary dip as failure, when it is actually just the cost of learning.

Dialog

Check it out here:

About Exec Engineering

Interviewing in the age of AI | Exec Engineering #196

Yassine Kachchani — Thu, 04 Jun 2026 13:02:36 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

State of the software engineering job market in 2026 (Gergely Orosz and Jessica Salmon / The Pragmatic Engineer)

Hiring is back, but the rules have changed. Fintech and security companies like Ramp and Wiz are outgrowing Big Tech on on headcount growth, while Meta has become statistically the most volatile place for engineers to build a career. And AI engineering demand is growing so fast that it's starting to look less like a specialization and more like a baseline expectation.

Interviewing in the age of AI (Charles-Axel Dein)

Every 12 months, AI models gain roughly a year of software engineering experience. At that rate, designing AI-resistant interview questions is a losing game. The smarter move is to stop fighting the tool and start testing what AI cannot fake: foundational reasoning.

AI made the boring work visible. Cut the work, not the people. (Jeff Gothelf)

IKEA’s AI chatbot automated half of its customer service. Most companies would have cut the other half. IKEA looked closer, found customers asking for design advice, retrained 8,500 people, and made €1.3 billion.

The Ask (Michael Lopp / Rands in Repose)

The meeting with no agenda you almost declined is sometimes the one that prevents two of your teams from spending six months building the same thing. Lopp kept a recurring 1:1 with a peer for three years before it did exactly that.

Trust, Ownership, Feedback, and Excellence (Tom Mango / Sleeping Potato)

Being nice and being kind are not the same thing on an engineering team. The kindest thing you can do for someone is give them honest feedback. Withholding it doesn’t protect them, it just pushes the problem downstream where it gets bigger and eventually does feel personal.

Your Process Is a Rube Goldberg Machine (Roman Nikolaev / High-Impact Engineering)

A workflow that relies on perfect memory, flawless timing, and constant coordination across multiple people has failure built into it from the start. The process is broken, not the people following it.

Inside Bloomberg’s flat engineering culture (Chantal Kapani / LeadDev)

Bloomberg has run its entire engineering organization of 10,000 people on two titles: engineers and people leaders. The bet is that removing hierarchy forces authority to come from results rather than rank, and that full ownership from idea to production keeps engineers more engaged than a promotion track ever could.

Why remote teams start slower but win long-term (Karol Wójciszko / Engineering Leader’s Playbook)

Local teams sprint at the start, but every problem solved in a hallway conversation creates tribal knowledge that lives in no document and survives no onboarding. Remote teams start slower and build something more durable: institutional knowledge anyone can access on day one.

Dialog

Check it out here:

About Exec Engineering

The Management Philosophy Limiting Your Engineering Output | Allen Cheung, Former SVP of Engineering, ujet.cx

Yassine Kachchani — Tue, 02 Jun 2026 12:01:12 GMT

This week’s Dialog guest is Allen Cheung, former Senior Vice President of Engineering at ujet.cx, a cloud-based customer experience platform.

Allen ran engineering at UJET, leading a 300-person org spread across four continents through the company’s push into AI-enabled customer service. Before that, he served as VP of Engineering at Kiddom, where he managed the company’s largest team and rebuilt the platform to handle five times the user load it was carrying when he arrived.

He’s also held senior engineering roles at Affirm and Mystery.org. Allen writes regularly on engineering management at allenc.com, where much of the thinking behind this conversation first appeared.

Takeaways

Productive environments shouldn’t be a perk for top engineers. They need to exist so the average engineer gets it right the first time without having to jump through hoops.
AI adoption gives managers cover to invest in CI/CD, tests, and review discipline, because coding agents only deliver when those systems are actually in place.
Hiring for complementary skill sets only works if the existing team has the self-awareness to value different work styles, otherwise differences get rejected instead of integrated.
High team satisfaction paired with mediocre business results is a warning sign. A leader’s job is to make the team productive, not happy.

Yassine: You’ve said your goal is to “build great teams by creating productive environments so it’s easy for normal folks to do great work.” What does that look like in practice? How do you actually build those environments?

Allen: Great environments are really just about encouraging wanted behaviors, through the path of least resistance. Whereas you can sorta rely on your best people to jump through hoops to build the right things, the point of productive environments is to make it easy for the average engineer to get it right the first time.

I remember a blog post from 25+ years ago from Joel Spolsky, who wrote about building great teams and products in the era of desktop applications, on his Joel Test. It was this 12-part checklist that highlighted the things that made for a productive environment, informed by the experience he had at Microsoft plus his own startup (Fogbugz and eventually Stack Overflow). Many are still surprisingly relevant today.

As managers, the challenge is to carve out the resources to invest in these systems: CI/CD, testing suites, PR review best practices, etc., all while continuing to deliver products and features. Fortunately, one major factor that goes in our favor right now is AI adoption. Every CEO now understands that coding agents are a productivity accelerant, so companies are racing to get AI tooling to their engineers and are encouraging usage. And it just so happens that coding agents work best when you also integrate them into great environments, where they can run builds and tests and their code is properly reviewed. Take advantage of this alignment!

Yassine: You’ve written about hiring for complementary skillsets rather than chasing “A players” who match the people already on the team. What helps you evaluate whether someone will actually complement the existing group, versus just being different?

Allen: To be clear, being different itself is not a bad thing! If the goal is to have a team that doesn’t have wholly overlapping skills/personalities/domain knowledge, then a necessary prerequisite is to have different folks on the team across some of these dimensions.

But you’re right in pointing out that difference is necessary, but probably not sufficient by itself. One of the ways that I’ve tried to solve this is to get as many of the current team to interview potential new team members as possible. What I’m looking for are emergent collaborative dynamics, bouncing ideas off of one another, building solutions that leverage each person’s domain expertise or individual strengths, etc. I sometimes have to remind interviewers that they’re not there just to evaluate knowledge, but to simulate what a working relationship would feel like.

This strategy works reasonably well for complementary functions or skillsets, but it’s a bit harder to suss out personality and working style differences and whether they’d work in practice, particularly in the context of an interview. I’ve found that teams that have a degree of self-awareness and humility are better able to integrate new members and give it an actual chance to work; if the existing team members acknowledge and appreciate a breadth of work styles, then there’s a better chance of the arrangement becoming actually complementary over time.

Yassine: You’ve written about the limits of servant leadership, that engineering managers who define their role solely around supporting their team can miss other critical qualities like decision-making and consistent output. How did your own understanding of that balance evolve? Was there a point where you realized the “servant” framing wasn’t capturing the full picture?

Allen: For me, it was receiving some tough managerial feedback about my teams’ effectiveness. Essentially, I had a series of performance reviews where my teams gave me very high marks as their manager. I was following all the best practices that I could find on what it meant to support my teams. But the business results were mediocre, which spoke to a real gap between perceived and actual excellence. Another manager of mine framed it like this: your job isn’t to make your team happy; it’s to make them productive.

And honestly, embedded within the “servant” framing and ethos is a level of idealism that, unfortunately, I’ve grown more cynical of over time. Yes, it would be great if everyone in your organization just needed some nurturing and support to do amazing work, but that doesn’t square with reality. Some do just need some managerial support and basic blocking and tackling, but others require much more investment across your entire team to get them on the right track, and few of us have the luxury to give them that level of support. And some,I speak from experience, will take full advantage of your supporting nature and offer up a litany of excuses.

Maybe an alternative way to think about servant leadership is to expand what it means to support your team. Sometimes that support comes in the form of holding strict accountability and providing tough feedback.

Yassine: For leaders who naturally default to support mode, what’s helped you develop those other muscles? The decisiveness, the willingness to be directive when it matters?

Allen: I always think it’s important to stay true to yourself, especially when you’re trying something unfamiliar or against your natural instincts. You have to evolve your management principles to allow for something that’ll come off as less supportive, more directive, otherwise you won’t really believe in what you’re doing and burn out.

For instance, I strongly believe that everyone has amazing potential, and given the time and motivation each one of us can accomplish amazing things. The challenge is that none of us have infinite time and energy, and it’s fundamentally unfair to the rest of the team if I spend the bulk of my efforts on 1 or 2 people and underinvest in others’ potential. For me then, the real constraints of finite resources and business realities means that I can’t operate in pure support mode; I’m forced to make tough decisions and have difficult conversations. At the same time, because I believe in people reaching their potential, I offer to keep in contact and chat regularly with folks after we no longer work together, and some do take me up on that arrangement.

Yassine: You’ve written about the “feedback void,” how leaders can become isolated from critical perspectives as their conviction hardens. Your advice is to intentionally hire people who think differently, and work hard to listen to them. What does “work hard to listen” actually look like for you? Is there a rhythm or habit that helps you stay connected to perspectives that might otherwise not reach you?

Allen: You know how sometimes, when you’re talking with a non-technical person about a technical subject and they’re describing something that you suspect is wildly misinformed, and there’s just this instinct building up where you just want to interrupt them and tell them how wrong they are?

Working hard to listen means suppressing that reflex.

But really, for me it’s about giving space for others to articulate their perspectives. I heard on a podcast recently that one of (CEO of Apple) Tim Cook’s tactics when he runs a meeting is to not say anything in the first 10 minutes, to not even react, so that his team has a little bit of space in the beginning to give honest assessments. My version of that is to try to take feedback or suggestions, and instead of reacting in the moment (which ends up being defensive 9 times out of 10) I nod and tell them I’ll sleep on it. A lot of times, I’ll be writing notes as they’re talking so I force myself to give them space to say the whole thing, and then I’ll review those notes at the end of the week as a way to reflect on the perspective.

Another technique I use is to paraphrase what they said back, both to ensure that I really understand the feedback, and to signal to the other person that I’m taking them seriously. With enough iterations and repetitions, I’m usually able to get folks to open up a bit, and feel like they can be a little bit more honest with me than before.

Oh, one last thing: I also remind folks that while I can and do listen to them, I cannot promise to act on every single piece of feedback. With larger teams (or many different functions), there’ll be a lot of back-and-forth, and suggestions that will end up being mutually incompatible. Or sometimes, an individual’s pet peeve just isn’t all that important in the grand scheme of things. So I always try to draw a line between hearing them out, and invoking major changes based on their commentary.

📚 Allen Cheung’s Go-To Resources:

3 people I follow and recommend:

Matt Levine, author of the Money Stuff newsletter, pointing out the absurdity of finance
Will Larson, who has written multiple books on eng. management with lots of tactical advice
Noah Smith, who opines on economics, geopolitics, and technology

1 podcast I make time for:

Greatest of All Talk, a basketball-focused podcast that has figured out what makes the podcast medium unique (e.g., personalities, takes, irreverent humor)

A newsletter I rarely skip:

Ben Thompson’s Stratechery, for a tech+business lens into our industry that’s also away from SF/NYC

A book that shaped my thinking:

Ask Iwata, a biography of Satoru Iwata, the former President of Nintendo; he was universally beloved and the book gets into some of that, but there’s also a surprising amount of great management advice and mental frameworks presented as well

Thank you Allen for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

Yassine.

AI didn't kill your junior pipeline. You did | Exec Engineering #195

Yassine Kachchani — Thu, 28 May 2026 13:03:11 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

AI didn’t kill your junior pipeline. You did (Andrew Murphy)

Here’s the bet a lot of engineering orgs are making right now: that AI pricing stays cheap, that their senior engineers don’t leave, and that nobody ever needs to explain how the system works to someone new. Every single one of those assumptions is wrong. The companies still hiring and training juniors are the only ones building something that compounds.

Why Defining Teams Is So Hard (John Cutler / The Beautiful Mess)

Every reorg changes who reports to whom. Almost none change how work actually gets done. John Cutler argues that the real org chart lives in Slack channels and hallway conversations that no diagram ever captures. You can redesign the boxes, but you can't redesign what you won't look at honestly.

Recognize your management wins (Lara Hogan)

The best management wins are invisible by design. You created clarity during chaos. You fixed a pay gap nobody wanted to look at. You kept someone from quitting without them knowing you did. This piece is a good reminder that if you’re waiting for someone to hand you a scorecard, you’ll be waiting a long time.

Diagnosing difficult behaviour (Stephane Moreau / Blog for Engineering Managers)

Before labeling an engineer as difficult, three questions worth sitting with: Is ownership actually clear, or does the loudest voice in the room make the final call? Are decisions really closed, or have people learned that escalation works? Is the system still rewarding the behavior everyone complains about in DMs? The hard conversation treats the symptom, but the system is usually the cause.

Written culture is higher leverage (Jade Rubick)

AI is only as useful as the context you feed it. A company where everything lives in someone’s head or gets shared verbally in meetings is leaving most of that leverage on the table. Written culture was always a good idea, but now, it’s a competitive advantage.

On Blunt Feedback (Shreyas Doshi)

“Feedback is a gift” is good advice for most people. For those already operating at a high level, it can be quietly destructive. The person giving blunt feedback may have good intentions but limited judgment in the specific area. The two are easy to confuse, and conflating them is where a lot of senior leaders go wrong.

Fix Delivery First (Ant Murphy)

The companies struggling with discovery, OKRs, and strategy usually don't have a discovery problem. They have a delivery problem. When your release cycle is measured in quarters, discovery insights go stale before anyone can act on them. Fix the bottleneck first. Everything else is pouring water into a full funnel.

How to Finish Engineering Projects Early Without Added Stress (Gregor Ojstersek and Karol Wójciszko / Engineering Leadership)

Parkinson’s Law: work expands to fill the time available. Give an engineer four days for a two-day task, and they’ll use all four, polishing things that don’t need polishing, revisiting decisions that are already made. Early finishes evaporate quietly, but delays show up on everyone’s burndown chart. This case study fixes that by cutting estimates aggressively and replacing individual deadlines with a shared team buffer.

Dialog

Fredrik Wallenius, CTO at EsterCare, shares why startup success often comes down to engineers who can step beyond narrow roles, adapt quickly, and take ownership of whatever the business needs most.

He breaks down why big-company hires often struggle when support structures disappear, how “corporate” systems like engineering ladders and performance reviews become critical as teams scale, and why autonomous teams only work when they stay fluid instead of turning into isolated fortresses.

Check it out here:

About Exec Engineering

Why Big-Company Engineers Struggle at Startups | Fredrik Wallenius, CTO, EsterCare

Yassine Kachchani — Tue, 26 May 2026 12:03:15 GMT

My Dialog guest this week is Fredrik Wallenius, CTO at EsterCare, a Swedish digital health company focused on women’s healthcare.

Prior to EsterCare, he served as Engineering Director at Tink, the Swedish open-banking fintech that scaled to 600+ employees before its acquisition by Visa, where he led a platform team supporting hundreds of engineers. Before that, he led cloud engineering teams at Google.

I reached out to Fredrik to discuss what changes when you go from scaling a high-growth fintech to building a team from scratch at an early-stage startup.

Takeaways

The big-company hires who thrive in startups are the ones who see nothing as “somebody else’s problem,” and don’t mind shifting their priorities depending on what the company needs.
Engineering ladders and performance reviews feel boring and corporate, but they’re what keep expectations consistent when headcount crosses into the hundreds.
Distributed teams work better when you mix locations within teams rather than grouping by site, even though co-located teams seem simpler on paper.
Autonomous teams sound good until each one becomes a fortress with its own agenda. Fluid structures and rotating people between teams prevent that from hardening.

Yassine: You’ve hired engineers at Google, Tink, and now EsterCare. When someone from a bigger company wants to join an early-stage team, what separates the ones who thrive from the ones who struggle?

Fredrik: Obviously it depends a bit on the role but one thing that everybody will notice is the breadth of the role. In larger companies, there are so many support structures and different teams in place that your role is often to do one specific thing. In small start-ups, there are no such structures, or maybe even other teams, so the job is more to do what is most needed at any given time.

Using myself as an example, yes most days I spend time on our technical strategy or implementing new features. But another day my main priority might be buying a laptop for a new employee. Or watering the plants in our office :)

So to answer your question about who will thrive, the people here really must be problem-solvers and without too much prestige. Someone who understands that very few things are somebody else’s problem.

On the flip side, this comes with many benefits. In large companies, even in senior roles, you often work on things with a narrow scope and a limited impact on the overall business. In smaller organisations, your individual impact is so much bigger.

And not to mention the speed of getting things out the door. Here we can go from idea to having the feature in the hands of our customers within days if we want to. That is very challenging to achieve in larger companies with quarterly planning, organisation-wide prioritisation, dependencies between teams, and so on.

Yassine: Tink scaled to 600+ people across Europe during your time there. Looking back, what did you put in place that felt premature at the time but you’re glad existed before the growth really hit?

Fredrik: I’m surprised at myself for saying this, as I find these kinds of things a bit boring and “corporate-y”, but we did get a good engineering ladder definition and performance review structure in place fairly early.

It creates a lot of work and adds new processes which will inevitably take time away from core tasks. But when your headcount starts climbing into the hundreds, you have to have something in place that ensures everyone is working to the same expectations. The end result is that wherever in the organisation you are, and whatever job you are doing, your performance is rewarded equally, regardless of who your manager is.

It also allows engineers to understand what behaviours and efforts are valued the most, and provides a mechanism for them to grow into more senior roles, if that is their ambition.

And finally, the tougher but very important reason for role definitions and performance reviews: it allows you to systematically identify people who are not meeting the standards you have set and hired for. This will then force you to manage poor performers by either helping an individual to get back on track or, in the worst case, explain that this might not be the right place for them.

Yassine: Tink had teams spread across a dozen countries. What did you learn about making distributed teams actually work?

Fredrik: Make the teams spread across several sites, i.e., have people from different countries in the same teams. It seems obvious at first to do the opposite, i.e. that you should have teams that are built with just people from the same location as they then speak the same language and work from the same office. But in my experience, this creates weird conflicts and lack of understanding between the teams.

And then the obvious: make sure that virtual teams have the opportunity to meet in person, at least once, but ideally more regularly. Just working together in the same room for a couple of days and then going out for dinner and drinks does miracles to the level of collaboration.

Yassine: You saw Tink’s full arc, from growth to the Visa acquisition. What lessons from that experience are you applying as you build EsterCare’s engineering team?

Fredrik: Three things come to mind:

1. If you are growing very fast make sure you have people in charge of the overall architecture in place. Call them Staff Engineers or System Architects or whatever fits your liking. Put them in charge of making sure your overall system architecture stays sound and coherent, that you have the same practices and processes in the whole organisation for things like incidents, API design, testing, deployments and so on.

2. Don’t go too hard on the “autonomous teams” strategy. Try making things stay a little bit fluid with people moving around in the organisation, with teams that grow and shrink depending on workload. Otherwise you will end up with each team being almost like a little fortress with their own agenda and very few contacts with the wider organisation.

3. Don’t just add more things in perpetuity. Be it on system level or feature level. You have to be able to “kill your darlings”. Or take the tough decision that a part of a system just is beyond salvation and needs to be rebuilt.

📚 Fredrik Wallenius’ Go-To Resources:

3 people I follow and recommend:

Authors of the best engineering books out there:

1 podcast I make time for:

Mellan Kodraderna (Swedish podcast on engineering leadership)

A book that shaped my thinking:

The Phoenix Project

Thank you Fredrik for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

Yassine.

The Faster You Go, the Wronger You Get | Exec Engineering #194

Yassine Kachchani — Thu, 21 May 2026 13:01:23 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

AI Broke the Job Interview. Now What? (Monika Kuqi)

1 in 3 candidates is now using AI during technical interviews. Companies panicking about this are missing the point. The format was already broken, AI just made it obvious. Predictable assessments test memorization, and memorization is now free. The fix is interviews that reveal how someone thinks, not what they remember.

Distilling leadership wisdom (James Stanier / The Engineering Manager)

You read a great interview, feel sharper for a few days, then the ideas fade back into the noise. James Stanier has a solution: turn the thinking of leaders you admire into an AI role you can actually query when you’re stuck on a decision, and stress-test your judgment against a different set of questions.

Repeat Until It Hurts (Roman Nikolaev / High-Impact Engineering)

The author separates communication into four stages: unawareness, understanding, familiarity, and adoption. Each stage requires more repetition than the last. What’s worth remembering is that something obvious to you may still be unclear to others, or they understood it intellectually but aren’t bought in yet.

“Mandating sounds efficient, but it often backfires. Buy-in takes longer, but it scales.”

The Finger Is Not the Moon (Csaba Okrona / Leadership Garden)

Post-mortems, 1:1s, retros, career ladders, every one of these was designed to serve a real purpose, but the meeting is much easier to keep on the calendar than the purpose is to keep alive. Teams get very good at running the process and slowly stop asking what it was supposed to change.

The State of Engineering Management in 2026 (Jellyfish)

84% of engineering leaders say productivity is a top management concern, and AI is now the main lever they’re reaching for. The data from Jellyfish’s annual report suggests the organizations pulling ahead are investing in measurement, structured training, and aligning engineering output directly to business outcomes.

Engineering managers should read team diffs, not just dashboards (Dunya Kirkali / Incremental forgetting)

Dashboards, engagement surveys, and status reports tell you where things stand today, but say nothing about where they’re heading. This piece is about developing the habit of reading behavioral change over time, because by the time something turns red, the shift has usually been happening for weeks.

You Need AI That Reduces Maintenance Costs (James Shore)

Speed is the wrong thing to optimize for when adopting AI coding tools. The real question is what happens to maintenance costs on everything the agent produces. If those costs grow proportionally with output, the net effect over a two to three-year horizon is negative, regardless of how fast you shipped in month one.

The Faster You Go, the Wronger You Get (Paulo André / The Hagakure)

AI rewards precision, the clearer your spec, the better the output, so teams naturally specify more, plan more, and design more upfront. Somewhere in that process, the feedback loop that was supposed to catch mistakes gets quietly skipped, and by the time reality corrects you, you’ve already built a lot more than you needed to.

Dialog

David Doyen, CTO at Bankin’, shares why the real risk of AI-generated code is teams losing the ability to truly understand the systems they ship.

He breaks down why developers who can’t explain or adapt AI-generated code are the new hiring red flag, how over-reliance on AI creates a dangerous “debt of understanding,” and why engineering value now lies in auditing, challenging, and owning AI output, not just generating it.

Check it out here:

About Exec Engineering

Building Teams That Own AI Output Not Just Generate It | David Doyen, CTO, Bankin’

Yassine Kachchani — Tue, 19 May 2026 12:00:28 GMT

On this week’s Dialog, I spoke with David DOYEN, Chief Technology Officer at Bankin’, a personal finance app that lets users aggregate their accounts and manage their budgets in one place.

Before joining Bankin’ in 2023, he was VP Engineering at Adikteev, where the platform processed millions of ad requests per second, and CTO at Preconys, where he led development of a wealth management platform supporting over €1 billion in client assets. He was also co-founder and CTO of SonetSuite, and Head of Technology at Viadeo.

He shares his thinking on engineering leadership and technical strategy through his writing on LinkedIn.

Takeaways

When AI handles syntax, language stops being a constraint on architecture, and the engineering leader’s job collapses back to system design judgment.
The clearest sign an engineering org is adopting AI constructively is when developers start sharing their failures with the tools, not just their wins.
Training people who leave pays off because in the startup world those former employees become future co-founders, partners, or key hires in your next company.
Over-relying on AI-generated code creates a “debt of understanding” that only surfaces during a 3 a.m. incident.
A candidate who cannot deconstruct or adapt AI-generated code under a new constraint is a passenger, not an engineer, and that is the new interview red flag.

Yassine: You wrote that “today, a CTO must become a learner again.” After 10+ years where you were mostly structuring teams and delegating technical work, AI brought you back to hands-on building. What are you actively figuring out or exploring right now? What’s fun about being back in that learner mindset?

David: Recently, I took the lead in designing a cloud-based budget management system. I oversaw the entire architecture, from serverless business logic to Slack integrations and industrialized deployment pipelines. What’s fascinating is that the choice of language is no longer a barrier to entry. Since AI handles the technical implementation, I can systematically select the most appropriate technology for any given project without letting syntax-learning curves slow down my architectural vision.

Yassine: What’s fun about being back in that learner mindset?

David: After years of delegating implementation, rediscovering this direct link to building is incredibly stimulating. This ‘learning mode’ forces me to challenge every technical decision to validate the AI’s output. For a CTO, it’s a return to the essence of system design: expertise no longer lies in mastering a specific syntax, but in the ability to orchestrate scalable architectures. It keeps me grounded in reality, bridging the technical distance that sometimes grows when we grant teams total autonomy.

Yassine: You encourage voluntary discovery over top-down mandates for AI adoption, letting time, curiosity, and experimentation do their work instead of forcing it. That requires patience. What gives you conviction in that approach?

David: Throughout my 25 years of experience, from startups to scale-ups, one lesson has remained constant: imposing technical solutions from the top down kills engagement. When technology is forced without debate, adoption remains superficial. AI represents a paradigm shift that requires personal ownership. Real buy-in comes from conviction, not instruction. I prefer a team that embraces a tool by choice rather than one that uses it out of obligation.

Yassine: What signs tell you your engineering org is engaging constructively?

David: The most reliable indicator is an enthusiasm for experimentation. I know an organization is engaging constructively when I see engineers testing new tech rather than rejecting it reflexively. I look for that shift from skepticism to active curiosity, when developers start sharing both their breakthroughs and their failures with AI. That is when the transition becomes rooted in the culture rather than just an administrative process.

Yassine: Your line about training really stuck with me, that it’s better to train people who will leave than to keep those you don’t train. That’s a bold training philosophy. How has AI shaped that vision?

David: The advent of AI radically reinforces this belief. Today, engineers must be curious, question technical choices, and constantly evolve. When used properly, AI is a phenomenal lever for accelerating skill development. Investing in training for these tools is no longer optional; it is the only way to maintain an agile, state-of-the-art organization.

Yassine: What’s the long-term payoff you’ve seen from investing in people who eventually leave?

David: With 25 years of hindsight, I view training as a relational investment. Developing an employee is personally rewarding but also highly strategic. In the startup and scale-up world, these talents become your future partners or key hires in your next ventures. If they know that working with you accelerates their career, they will be the first to follow you into a new challenge. The ‘cost’ of their departure is more than offset by the power of this alumni network.

Yassine: You wrote that evaluating AI-era candidates is like reviewing a pull request, detecting their intrinsic reasoning and system thinking rather than just prompt mastery. When you’re interviewing someone now, and they’re using AI to work through a problem, what’s the red flag that tells you a candidate doesn’t truly understand AI-generated code?

David: The immediate warning sign is an inability to explain AI-generated code or to adapt it during a live interview. If a candidate cannot deconstruct the logic or pivot when I introduce a new constraint, they are no longer in control. In our industry, we cannot afford to have ‘passengers’ at the keyboard.

Yassine: How do you see this playing out differently for junior versus senior engineers?

David: We see a real risk of ‘systemic laziness’ in some junior profiles. Without deep experience in underlying systems, they often rely exclusively on AI. However, without that foundational understanding, it is impossible to optimize an architecture or catch subtle AI errors. Today, a developer’s value lies not in their output, but in their ability to audit and guarantee the system’s robustness. Judgment is a human skill forged through real-world experience.

Yassine: In light of all conversations around AI in software engineering, what aspects do you think we are not talking about enough?

David: What we overlook: The “Debt of Understanding”

We talk a lot about productivity, but not enough about the loss of intellectual sovereignty over our own systems. By over-relying on AI-generated code, we risk creating architectures that no one truly understands. If a major incident occurs at 3 a.m. on a critical system, the AI won’t be there to take responsibility. Maintaining ‘mechanical sympathy’, the deep understanding of how code interacts with infrastructure, is a matter of resilience that isn’t discussed enough.

The ethics of technical decision-making

Another blind spot is the shift in decision-making. AI often proposes the most statistically probable solution, which isn’t necessarily the most innovative or suitable for a specific Fintech context. We need more discussion on the risk of ‘mediocre standardization.’ The CTO’s role tomorrow is not just to manage developers, but to ensure humans have the final say, especially when security and compliance are non-negotiable.

The illusion of replacement vs. augmentation

The most dangerous mistake today is believing that AI can replace skills. AI only augments and accelerates existing expertise. If you hollow out your internal skills, who will be left to challenge the AI? Who will guarantee that the output is viable, secure, and scalable? Without experts to audit and arbitrate, you aren’t building a tech company; you’re accumulating fatal knowledge debt. AI is a co-pilot, but a plane has never needed an experienced pilot more than when its automated systems become complex.

📚 David Doyen’s Go-To Resources:

Someone I follow and recommend:

Thibault Renouf

1 podcast I make time for:

Silicon Carne

A newsletter I rarely skip:

The Unicorn CTO community

A book that shaped my thinking:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren

Thank you David for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

Yassine.

Two Captains, One Ship | Exec Engineering #193

Yassine Kachchani — Thu, 14 May 2026 13:02:46 GMT

Hey👋

Thanks for reading Exec Engineering, a weekly digest for the busy tech executive.

I hope this edition brings you value.

The Digest

Minimally Viable Consistency (Part 3) (John Cutler / The Beautiful Mess)

Every scaling org hits the same wall: too much standardization kills autonomy, too little makes coordination a nightmare. Cutler maps this out with a sharp distinction between what must be locked down, what just needs shared intent, and what can vary as long as it’s named. The framework alone is worth the read.

A Lesson From the Cockpit (Subbu Allamaraju)

When you automate the hard parts of a job for long enough, the people doing that job gradually lose the ability to handle those hard parts without the automation. Aviation learned this through crashes and built mandatory unassisted training to counter it. Software engineering is heading toward the same wall and has built nothing equivalent yet.

Why engineering teams swing between process extremes (Dunya Kirkali / Incremental forgetting)

The worst time to adopt a trend is when everyone is talking about it. By then, the pendulum is already preparing to swing the other way. Dunya Kirkali’s piece is a useful reminder that most of what looks like progress in our industry is actually oscillation, and the job of a good engineering leader is to stay aware of the motion, not get swept up in it.

Two Captains, One Ship (Alex Kurilin)

Co-founder advice usually comes in two flavors: inspirational or cautionary. This is something rarer. It’s an honest, experience-dense account of what the CEO/CTO relationship demands from both sides, written by someone who has been in the seat enough times to know what actually matters.

Can one bad apple ruin your team? (Bruce Daisley / Make Work Better)

Most team performance conversations focus on the best people, who to promote, who to retain, who to stretch. But the data points in the opposite direction, showing that the biggest predictor of team performance isn't your strongest engineer but your weakest cultural fit, and how long you let them stay.

Leadership in AI-Assisted Engineering (Justin Reock / InfoQ)

Teams go through a rough patch when they first start using AI, productivity dips, code quality drops, and engineers feel the friction of rewiring how they work. This is a predictable stage, not a failure. The leaders who know it’s coming, communicate it clearly, and give their teams time to push through it are the ones seeing real gains on the other side.

Bad code is contagious (Jeff Foster / JoT)

Bad code has always spread through codebases by imitation. AI just made that process dramatically faster. This is one of the more original ways I’ve come across to think about technical debt, applying epidemic modeling to code quality, and using it to figure out where engineering interventions actually matter.

”Engineering leaders spend a lot of time thinking about how to produce more code. The more useful question is how to ensure that the code you produce does not contaminate the code you already had.”

The Transitional Instability of AI Engineering (Peter Spellward / Refactoring Leadership)

AI conversations in engineering usually focus on speed. This one focuses on what gets quietly lost as speed increases, the organisational understanding, ownership clarity, and control systems that took years to build and can erode in months. That’s the transition worth preparing for.

Dialog

Vincent Chu, VP of Engineering at Visier Inc., shares why distributed teams don’t fail because of weak async documentation, but because they lose the informal signals that reveal who’s stuck, overwhelmed, or quietly disengaging.

He also breaks down why distributed teams only work when each site owns a problem space end-to-end, how AI shifts the bottleneck from coding to code review and comprehension, and why engineering leaders who stop coding lose touch with what’s actually practical versus hype.

Check it out here:

About Exec Engineering

Async Documentation Alone Will Not Save Distributed Teams | Vincent Chu, VP of Engineering, Visier Inc.

Yassine Kachchani — Tue, 12 May 2026 12:19:22 GMT

On this week’s Dialog, I spoke with Vincent Chu, VP of Engineering at Visier Inc., a workforce analytics platform used by HR and finance teams, where he leads a ~90-person engineering organization across platform, product, and SRE.

Before Visier, Vincent was Chief Product Development Officer at AgencyAnalytics and Head of Engineering at Later.com through its 2022 acquisition by Mavrck. Earlier, he spent four years at Apple on the iWork suite and got his start at Electronic Arts (EA) on FIFA.

Vincent Chu also writes about engineering leadership and team culture on his personal site, where he shares practical reflections from his experience.

Takeaways

Async collaboration across time zones breaks down not because of bad documentation, but because you lose the informal signals that tell you who is stuck, overwhelmed, or quietly disengaging.
Distributed teams stop functioning when a site is just an execution arm for headquarters. They start functioning when each site owns a problem space end-to-end and can ship without constant cross-timezone coordination.
AI tools spike output, but velocity without comprehension is a liability. The bottleneck shifts from writing code to reviewing it, and engineers end up shipping systems they no longer fully understand.
Engineering leaders who stop writing code lose calibration. Without firsthand experience of the tools, opinions get formed on secondhand summaries, and the gap between what people say is possible and what’s actually practical becomes invisible.

Yassine: You have expertise in leading Engineering and Product teams across multiple time zones. What took you the longest to figure out about making that actually work? What assumptions from your earlier years in leadership didn’t hold?

Vincent: What took me the longest to figure out was that async by itself is not the answer.

Earlier in my career, I genuinely believed that if we wrote everything down, kept a clean repo, recorded meetings, and were disciplined about documentation, cross-time-zone collaboration would mostly take care of itself. I thought the problem was operational. It turned out to be structural and human.

The first thing that broke that assumption was trust and visibility. When you do not have prior working history with someone, especially more junior team members, you lose all the informal signal. You cannot tell who is stuck, who is overwhelmed, or who is quietly disengaging. Documentation does not fix that. You have to intentionally design clarity around ownership, expectations, and what “great” looks like.

The second assumption that did not hold was around time zones themselves. Most people will say they are fine working in the center of gravity time zone. I would have said that too. But if someone is waking up at 5am or staying online until 1am five days a week, that is not sustainable. It looks fine for a quarter. Then it shows up in energy, decision quality, and retention.

What actually works is not heroics or better note taking. It is structure:

Each site needs a real mission.
Clear delegation.
Independent release cycles.
End-to-end ownership.

If a location is just an execution arm for another office, the friction compounds. If that location owns a problem space and can ship independently, the time difference becomes manageable.

The real shift for me was stopping the question of how to collaborate better across time zones and starting to ask how to design the organization so it does not require constant cross-time-zone coordination to function. That mindset change made everything else simpler.

Yassine: During your tenure as VPE at Later, you rebuilt the career framework and scorecard definitions for engineering to provide “fair and transparent progression.” What prompted the rebuild, and what design choices made the new system work?

Vincent: I would not frame it as walking into something that was broken and trying to fix it. It was more that the system was incomplete, and the team had clearly outgrown it.

There was strong ambition across the engineering org. People wanted to grow, to understand what good looked like, and to know how to get to the next level. What we had at the time was directionally right, but it was not fully fleshed out. Different managers were interpreting expectations slightly differently. That creates noise, even if everyone has good intentions.

At Later, transparency and fairness were core cultural values. So the question became, if we actually believe that, what does it look like in practice? For us, that meant building a clear job matrix with explicit expectations at each level. Not just technical depth, but scope, ownership, cross-functional impact, and leadership behaviors. It gave managers and team members a shared reference point instead of relying on informal calibration.

One common fear leaders have is that once you make everything explicit, people will treat the matrix like a checklist. They will point to each bullet and say they qualify for a promotion, regardless of business context or financial constraints. In my experience, that is manageable.

The key design decision was separating job level from title. Level reflects scope and impact. Title is more about external signaling and organizational design. By decoupling the two, we could have honest conversations about readiness and progression without every discussion automatically translating into a title change or comp event.

What changed after that was the quality of the conversation. Instead of debating whether someone was “good enough,” we were discussing evidence of impact relative to a clear standard. That shift alone made progression feel much more fair and much less political.

Yassine: Engineering leaders have been pressured to accelerate AI adoption in their orgs and products over the past 2 years. You describe yourself as “pragmatic with software development processes” and say you “thrive in organized chaos.” How have you been navigating the pressure to adopt AI at Visier? What are some pragmatic decisions you’ve made amidst that chaos?

Vincent: These days every conversation has some version of “what’s your AI strategy?” I think the mistake would be to swing too far in either direction, either blocking everything or chasing every shiny tool.

The way I have navigated it is pragmatic and structured.

First, we encourage experimentation, but with guardrails. Security, IP protection, and data handling are not optional. Teams are free to try different tools, but within a clear boundary. That gives people room to explore without putting the company at risk.

Second, we accept that the tools are evolving faster than any policy. A guideline that was perfect one quarter can be outdated six months later. So instead of trying to lock down a permanent standard, we revisit guidance regularly. The goal is not to standardize forever. It is to create clarity for now and be willing to update it.

Visier has been supportive financially, which helps. If you want teams to adopt responsibly, you cannot force them onto free or crippled tiers and expect magic. We invest where we believe there is leverage.

Where I have been particularly cautious is around long term ROI. AI can absolutely increase output. It can also create a maintainability problem if people are merging code they do not fully understand. We talk a lot about whether our developers still understand the systems they are shipping. Velocity without comprehension is a liability.

There are also very practical side effects. PR volume can explode. Review time can explode. If you do not adjust expectations and review practices, you just shift the bottleneck from writing code to reviewing code. We made that explicit early so managers were not surprised by the second order effects.

Organizationally, we have a central owner coordinating at a high level, but execution is pushed down. Each manager is accountable for how their team uses these tools and whether they are actually becoming more effective. Part of my role has been educating people managers on the tradeoffs of different tools so they can make informed decisions, not just mandate adoption.

It really is organized chaos. The key is not to eliminate the chaos, but to put enough structure around it that experimentation compounds instead of fragmenting.

Yassine: You’re a tinkerer, and you’ve kept your GitHub green across your leadership career. Most executives end up operating at pure abstraction like OKRs, roadmaps, org charts. What does staying in the code prevent you from losing?

Vincent: I do operate at the abstraction layer most of the time. OKRs, roadmaps, org design, people management. That is the job. But staying in the code prevents me from drifting too far away from reality.

The first thing it protects is technical intuition. Especially right now with AI accelerating development. If you are not actually using the tools, building small things, experimenting with agents, copilots, MCP servers, whatever the latest wave is, you end up forming opinions based on secondhand summaries. The delta between what people say is possible and what is actually practical is huge. Writing code keeps my judgment calibrated.

It also directly informs product strategy. When I experiment on nights or weekends, I am not just tinkering for fun. I am pressure testing ideas. I get a feel for what feels magical versus what feels brittle. That helps me recommend what we should build, where we should invest, and what is hype versus leverage.

The other thing it prevents me from losing is credibility. Not in a performative way, but in a grounded way. The teams I lead know I used to code heavily. But in this AI era, everyone is a beginner again. The tools are changing fast. If I am not learning alongside them, I slowly become the person who talks about transformation without understanding the friction on the ground.

Staying close to the code reminds me how hard the work actually is. It keeps me honest about tradeoffs. It keeps my empathy sharp. And it makes sure that when I talk about velocity, architecture, or adopting a new paradigm, it comes from lived experience, not abstraction.

📚 Vincent Chu’s Go-To Resources:

1 podcast I make time for:

Matt Wolfe from FutureTools

A newsletter I rarely skip:

Vancouver Tech Journal

A book that shaped my thinking:

Team Topologies by Manuel Pais and Matthew Skelton

Thank you Vincent for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

Yassine.

Executive Engineering Newsletter

Your incident response wasn't built for AI | Exec Engineering #207

The Digest

More reads

About Exec Engineering

How I Decide Whether to Split a Team | Exec Engineering #206

The Digest

More reads

About Exec Engineering

Yes you can measure engineering | Exec Engineering #205

The Digest

More reads

About Exec Engineering

Should we still design code for humans? | Exec Engineering #204

The Digest

More reads

About Exec Engineering

Engineering managers are paying the price of rising expectations | Exec Engineering #203

The Digest

More reads

About Exec Engineering

How to hire engineers for strong judgment and taste | Exec Engineering #202

The Digest

More reads

About Exec Engineering

The Rewrite That Actually Worked | Exec Engineering #201

The Digest

Dialog

More reads

About Exec Engineering

When AI Costs More Than the Engineer | Exec Engineering #200

The Digest

Dialog

More reads

About Exec Engineering

Your Instincts Stop Working the Moment Your Org Changes | Manuel Drews, Director of Engineering, Native Instruments

Takeaways

📚 Manuel Drews’ Go-To Resources:

The Anatomy of an AI-Native Org | Exec Engineering #199

The Digest

Dialog

More reads

About Exec Engineering

The Reliable Team Trap | Exec Engineering #198

The Digest

Dialog

More reads

About Exec Engineering

The CTO’s Comprehension Debt | Exec Engineering #197

The Digest

Dialog

More reads

About Exec Engineering

Interviewing in the age of AI | Exec Engineering #196

The Digest

Dialog

More reads

About Exec Engineering

The Management Philosophy Limiting Your Engineering Output | Allen Cheung, Former SVP of Engineering, ujet.cx

Takeaways

📚 Allen Cheung’s Go-To Resources:

AI didn't kill your junior pipeline. You did | Exec Engineering #195

The Digest

Dialog

More reads

About Exec Engineering

Why Big-Company Engineers Struggle at Startups | Fredrik Wallenius, CTO, EsterCare

Takeaways

📚 Fredrik Wallenius’ Go-To Resources:

The Faster You Go, the Wronger You Get | Exec Engineering #194

The Digest

Dialog

More reads

About Exec Engineering

Building Teams That Own AI Output Not Just Generate It | David Doyen, CTO, Bankin’

Takeaways

📚 David Doyen’s Go-To Resources:

Two Captains, One Ship | Exec Engineering #193

The Digest

Dialog