Ellis & Kherdekar, Issue 03 · Engineering Leadership in the Agentic Era
The teams that move fastest with AI will be the ones whose culture is built for uncertainty. Every team can buy the same tools. Culture is harder to copy, and building it is a leader's job. In my teams, that culture starts with one anchor: the business problem stays put, even when the work underneath it keeps shifting.
Here's why that matters now. Traditional engineering works like a ladder. You write a piece of code, make it work, and build the next piece on top of it. Some rungs break and you fix them. Each step holds the weight of the last one and gets you closer to where you're going. Sprints, design reviews, handoffs, and release trains all worked because the work behaved predictably.
AI takes a lot of that away. You can do the same work twice and get two different outcomes. A full day of work can turn out to be useless by evening. Your team is working with a black box, and they feel it well before anyone says it out loud.
In Issue 01 I laid out the playbook I'd use to set up an engineering org for agents. In Issue 02, Mike looked at how builders keep real control when agents do more of the work. This issue covers the mindset shift and ways of working that make the culture real, and what they cost.
There is more than one way to build this
What I describe here works for my team, my people, and the culture I'm building. I've seen it get results, but it isn't the only path, and your lines may sit somewhere else.
Any leader working through this faces the same questions:
What do you actually do about the uncertainty?
How much failed work can a team absorb before morale and retention take a hit?
Where does experimentation stop and normal building start?
What do you say when an engineer's week of work gets thrown out?
Engineers tie a lot of their identity to shipping code that works. Losing that work stings, and pretending it doesn't helps nobody. Every answer has a cost. Move too fast and you wear people out and ship things that break. Move too carefully and you spend months designing for a problem you don't understand yet. Here's where I've landed, in the order I'd build it.
Start by understanding the problem
I start without AI. The team first has to understand the business problem and the process behind it, usually by working through it by hand. Then we automate the parts that need it.
This is also where I draw the line on experimentation. If the process is broken or the data is bad, it isn't ready for AI. AI won't stop to ask what's wrong. It will take the garbage and amplify it. So we fix the fundamentals first. Good architecture, clean data, and solid engineering judgment matter more once an agent is in the loop.
The cost of being wrong is the other half of where that line sits. Mike covered that in Issue 02 with the grid he uses to decide how much oversight a piece of work needs. I highly recommend it: read Issue 02 here.
A team that understands the problem can break it down. That's where speed comes from.
New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.
Small pieces keep the team moving
Once the team understands the problem, I want the smallest piece that works on its own and can ship. Get that first version out, even if the full solution isn't working yet. Then build the next piece on top.
Some pieces won't work. Some releases will be bad and some things will break. Because each piece is small, a miss costs hours or a few days. If it takes weeks to ship the first thing and weeks for each round after that, you're already behind. Every miss costs a month, and the team stops wanting to try anything.
Small pieces also let the architecture grow with demand. Nobody knows the perfect design on day one, and I'd rather not spend weeks building layers we may never need. How architecture should evolve this way deserves its own issue, and I'll come back to it.
Shipping small means some pieces will fail, often. Whether people keep taking that risk comes down to how the team treats failure.
Failure the team can talk about
Small pieces shrink the emotional cost. Culture handles the rest.
When an experiment dies, we run a blameless root cause analysis (RCA). It's a structured look at what went wrong and why. Blameless means the review is about the problem and the process, and nobody gets singled out. We ask four questions. What was the problem? What did we try? What was the root cause? What could we have done better? The same thing could have happened to anyone on the team. We write it up, share what we learned, and change our process where it needs changing.
I also want the people who surface problems to get credit for it. Someone who writes up what went wrong and how to fix it is showing the behavior I want more of. Once failures get used against people, they start hiding them. Hidden problems are slow problems, and you lose the safety this whole approach depends on.
Owning failure as a team only works if the team can see what it's working toward. That's where the problem comes back in.
Keep engineers close to the problem
This is the part I care about most.
If code is only a means to an end, you need another way to see progress. I use input and output metrics. Output metrics are the needle you're trying to move. They're usually the business problem itself, and you don't fully control them. Input metrics are the levers you do control, like testing, deployment practices, and the checks that keep new pieces from breaking old ones. The team works the levers and watches the needle.
When an attempt fails but the output metric still improves that week, losing the code hurts a lot less. Engineers can only see that if they're close to the customer and the problem.
Territory gets in the way. It shows up between roles, when an engineer says something is the product manager's job. It shows up between teams, when the conversation turns into "our area" and "your area." Either way it pulls people away from the problem. In most large organizations you rarely own a problem end to end. You depend on other teams, and solving the problem means building coalitions with them. That deserves a full issue, and it's coming.
Let go of how we've always done it
The biggest shift for engineers goes past code. It's letting go of "this is how we've always done it."
Across the industry, I see a lot of energy spent defending process: the sprint shape, the review steps, the handoffs, the way a design doc has to look before anyone builds. Some of that still earns its place. A lot of it was built for the ladder. When an engineer spends a week defending how the work should flow, their eye is off the ball. The ball is the outcome for the customer, so spend as much time with them as you can.
So I'm asking engineers for three things. Own the problem, even when you don't own every piece of the code. Get comfortable experimenting, because a failed attempt still teaches the team something. And work closer to the customer than you're used to.
Under all of that is understanding the problem. If an engineer doesn't understand the business problem, or isn't clear on input and output metrics, the rest won't land. That's the biggest gap I see, and it's where I spend a lot of my time.
The destination stays put
I explain all of this to my team with Google Maps. The destination is the business problem, and it doesn't move.
Nobody has ever asked for their problem to take longer to solve or to come back with more mistakes. What took a week becomes a day, then an hour, and better agents will keep pushing that. The tools and timelines will keep changing. What people want holds steady: the right outcome, faster, with fewer mistakes. That's the destination, and it's the one thing I don't let the team lose sight of.
The route is the code, the approach, and yes, the process. Drive from California to New York on roads you've never seen and you'll hit traffic, construction, and a wrong turn or two. You reroute and keep going.
That's the culture that replaces the ladder. Understanding the problem tells the team where it's going. Small pieces make rerouting cheap. Blameless reviews make wrong turns safe to admit. Metrics show whether you're getting closer.
The engineers who struggle with agentic work hold tight to the route. The ones who do well hold tight to the destination.
If you try one thing this week: ask your team to name the output metric for the work in front of them. If they can't, start there.
Next Tuesday: if the work keeps changing this fast, how do you grow your career in it? What gets you promoted when writing the code is no longer the hard part? I'll share how I think about that, and what I look for in the engineers I'm betting on.
Don't miss next Tuesday's issue on growing your career when writing code is no longer the hard part. Subscribe free to get it in your inbox. You can also reply to any issue, and the best questions become future issues.
The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.
Till next time,