Last Thursday, Mike ended Issue 04 with a bet. He said understanding the system would be a big part of my answer on how engineers grow when writing the code is no longer the hard part. He’s right, and I’d take it one step further. Understanding the system is the floor. What gets you promoted is how far the trust in you reaches.
In Issue 03 I promised to share what I look for in the engineers I’m betting on. This is that issue. It’s written for engineers at every level, and for the leaders who grow them. At the end of each stage there’s a 90-day roadmap you can start on Monday, and the templates are in the playbook kit at the bottom.
First, the part that keeps changing. Agents and software factories are how a lot of software gets built today. My team works this way. Engineers scope the work, talk to users, pull the data, ship and iterate, and agents do much of the writing. The specifics will keep changing, and the models will keep getting better. So I’d be careful about building a career around any one tool or factory setup. Build it around what holds no matter what writes the code.
Three things hold at every level. Know the business problem and who you’re solving it for. Understand the system well enough to explain it with the agent closed. And assume what you build can break and will break, because that’s how you should run on-call and security. Get those right in your current job before you reach for the next one.
None of this is a brand-new career framework. Most of it would have made sense ten years ago. What changed is the floor and the pace. An engineer on day one now checks agent output that already looks finished, and the time it takes to move between stages is shrinking for people who work this way.
New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.
Trust grows in circles
Everything else in this issue hangs on one idea. Your career grows by earning wider circles of trust.
Your project team trusts you to deliver.
Your team trusts you with a whole problem.
Several teams trust your calls and build coalitions with you.
Several orgs trust your direction enough to put their own capacity behind it.
You can’t jump to the outer circles if your own team doesn’t trust you. I’ve watched engineers try. They pitch a cross-org platform while their own team is still waiting on the last thing they promised. It doesn’t land, and it shouldn’t. The work in each circle is still doing your current job well. The next circle gets layered on top of it.
You can skip a title. People do it by changing companies. The circles reset when you do, though. An experienced hire from outside still has to earn their new team’s trust first, and plenty stall in their first year for that reason. A viral project gets you attention. Leaders still need to trust you before they commit capacity.
Your customer changes as the circles widen. Early on it’s the user of your feature. Then it’s the users of your product or service. Further out, it includes the engineers who use the platforms, tools and agent workflows you build. At some point your own team becomes one of your most important customers, and engineering excellence becomes part of your job.
One more thing. Good work only builds trust if people can see it. Write your calls down so they add up to a track record, and make commitments people can watch you keep.
Where you are today
The model has four stages: Builder, Owner, Multiplier and Shaper. Your title tells you which stage you should be aiming for. The grid tells you where you actually are, and the answer can be different on each row. You score yourself on four rows, and each one answers a single question.
Problem and customer: what outcome, and for whom?
System understanding: how does it work, and why is it built this way?
Engineering excellence: what happens when it breaks, and how do we build better?
Raising others: who got better because of you?
The bottom row is your circle of trust. You don’t score it. It’s what the other four earn you, and it shows up in signs other people can see.
Here’s how I’d use it.
Score yourself 1 to 4 on each of the four rows. Every score needs one artifact you can point to, like a spec, a design doc, an RCA, a dashboard or a write-up someone else reused. Writing is how most of those artifacts exist.
Ask your manager to score you separately, then compare.
Check your circle. Which signs do people outside your current circle already see?
Pick your row and follow the roadmap for your stage. Choose the row that blocks your next circle, or the one where you and your manager disagree most.
A few caveats. If you’re a deep specialist in security, performance or ML infrastructure, keep sharpening that spike. Depth can be how you become a Multiplier, and your evidence may be an incident that never happened. Experienced engineers also come in different shapes. Some lead a technical area, some go deep on the hardest problems, and some extend a senior leader’s reach. The grid works for all of them, but each one weights the rows differently. And no row counts without a shipped result you can point to. From Owner up, it has to be measured too.
Your 90-day roadmap at a glance
Every stage follows the same shape. In the first 30 days you find your baseline. In the next 30 you build the thing. In the last 30 you make it visible, because trust only grows from work people can see. Each phase ends with an artifact, and each roadmap ends with a gate that tells you you’re ready for the next circle.
Stage 1 · Builder: early career
Usually interns, new grads and your first few years · Scope: a task · Horizon: days to weeks · Agent work today: you use agents on scoped tasks and check every result
Stuck signal: you can’t explain what you shipped.
Let me be honest about this stage first. There will be fewer entry-level roles for a while, and the ones that exist look different. The bar on day one is higher. You’re expected to check work that already looks finished, and to notice when it isn’t. I still think teams that stop growing early-career engineers lose their bench in five years. I wrote about protecting that apprenticeship in Issue 01, and I haven’t changed my mind.
What I expect. Deliver what you said, when you said, and raise it early when you can’t. That’s how your project team starts to trust you. Name the user and the outcome before you start. Walk a reviewer through your change, including the parts the agent wrote, and say which parts you don’t fully understand yet. Saying that out loud builds more trust than pretending.
How to get your reps. The agent writes a lot of the code now, so you have to build fundamentals on purpose. Once a week, explain one agent-written change to a teammate with the agent closed. Build one small thing by hand, then again with the agent, and compare. Read before you re-prompt, as Mike put it in Issue 04. Ask to shadow on-call. Watching things break is the fastest teacher you’ll get.
Getting close to users. You might be three layers away from them. Read the support tickets, logs or call recordings for your feature. If your manager mostly counts tickets closed, do this anyway. It’s the story you’ll want in your first promotion conversation.
What gets you noticed. Catching a mistake before it ships, yours or the agent’s, and explaining why it happened.
Your 90-day roadmap: find your baseline, then ship one thing end to end, then make it visible. The full plan, with the artifact for each phase, is in the playbook kit.
Ready for the Owner circle when: your team hands you a whole problem instead of a list of tasks.
Use the Explain it cold checklist in the kit every week.
Stage 2 · Owner: mid to senior
Scope: a problem · Horizon: up to a quarter · Agent work today: you run a workflow end to end through agents
Stuck signal: you ship, but you can’t say whether it moved the metric.
What I expect. Take a vague ask and turn it into a shipped, measured outcome. Talk to users regularly. Know your service, its data and its dependencies well enough to debug it with the agent closed. Define what done means before work starts, including how it fails. Own on-call and the RCA for what you ship. Teach as you review, and build the starter path that gets the next new engineer shipping sooner.
Your team trusts you with a whole problem when it keeps running while you’re out. If the team’s hardest work still has to go through you, you’re at the start of this circle.
Crossing into the next circle. This is where a lot of strong engineers stall. Great Owner work mostly earns you more Owner work. Nobody hands a senior engineer a cross-team outcome. The first move is usually one nobody asked for. Find a problem a neighboring team has, fix it, and hand it to them.
What gets you noticed. Turning a vague ask into a result you can measure.
Your 90-day roadmap: find the problem nobody owns, then get another team to commit, then hand it over and report. The full plan, with the artifact for each phase, is in the playbook kit.
Ready for the Multiplier circle when: teams outside yours ask for your call before they decide.
Use the Cross-team proposal and Decision record templates in the kit.
Stage 3 · Multiplier: Staff and principal
Scope: an outcome across teams · Horizon: two to four quarters · Agent work today: you make the team’s agents and software factory trustworthy, whatever tools they run on
Stuck signal: you’re still the best coder, and the bottleneck in every review.
What I expect. Pick which outcomes are worth chasing, and drop the ones that aren’t. One of those outcomes is often making your own team faster. At this stage, the engineers who use what you build become a big part of your customer base. Explain the whole system and take complexity out as it grows, or be the go-to person for one hard domain.
This is where the engineering excellence muscle matters most. Name the one-way doors before the team walks through them. Write the design doc others build from. Keep up with how the industry is building with AI, test new approaches early, and turn what works into standards for the team. Know what your area’s agent work costs per outcome. Sponsor engineers by name, and hand them visible work you’d have taken yourself.
Coalitions. At this stage, if you aren’t influencing things beyond your team, it’s hard to say what you’re multiplying. Coalitions here are earned. Teams outside yours ask for your call before they decide, and commit to a plan with you. You get there by being right often, writing your reasoning down, and being easy to disagree with. When you lose an argument, say in writing why you committed anyway. People remember that.
What gets you noticed. Another team adopts your pattern without you in the room.
Your 90-day roadmap: write the direction, then make one pattern portable, then show the multiplier. The full plan, with the artifact for each phase, is in the playbook kit.
Ready for the Shaper circle when: leaders in other orgs commit capacity to something you proposed.
Use the Technical direction template in the kit.
Stage 4 · Shaper: Principal and above, director-level ICs
Scope: a direction across orgs · Horizon: one to three years, revisited every quarter · Agent work today: you decide where software factories and agent teams should run, and what they cost
Stuck signal: your strategy is one nobody funds or can execute.
What I expect. Shape the few bets the org funds, with the cost case behind them, and stop the ones that stop paying off. See the shared failure points and the duplicated spend across orgs. Platform thinking at this level is concrete. You find three teams paying for the same thing. You write the case for one shared version, agree on a migration path, and retire the rest. You measure it by adoption and by what got retired.
Set the org’s defaults, including when to build, buy or partner. Own what a failure costs, who answers for it, and what security and audit need to see. Stay technical. Review designs and build prototypes for the bets that matter most, because the people you’re aligning will check whether you still can. Grow the next Multipliers, so each of the top critical systems has someone ready to take it over.
Coalitions at this level. Leaders across orgs give up some of their own roadmap to back your direction, and they keep it funded through reorgs and budget cycles. None of them report to you. They do it because every inner circle already trusts you.
What gets you noticed. Your calls held up, or you reversed them early and explained why. With AI moving this fast, a good call you reverse quickly counts too.
Your 90-day roadmap: find the duplicated spend, then make the case, then fund it and grow the bench. The full plan, with the artifact for each phase, is in the playbook kit.
You’re doing it when: leaders give up some of their own roadmap to back your direction, and keep it funded.
Use the Consolidation case template in the kit.
If you lead engineers
Use the grid in 1:1s as a conversation. Keep it out of calibration as a score.
Protect the reps for early-career engineers. Put them in on-call rotations and incident reviews on purpose.
Don’t promote someone because agent output makes their work look more senior than it is. Ask them to explain it with the agent closed.
In your next 1:1, ask three questions. Which row would you score yourself lowest on, and why? What artifact would prove the score you gave yourself? Which roadmap phase are you starting this week?
The playbook kit
Download the kit below. It has the scorecard, all four 90-day roadmaps and the six templates, ready to fill in. Save a copy and bring it to your next 1:1.
What stays when the tools change
The row about agent work will look different next year, and I expect to rewrite it. The rest of the model should hold. Someone still has to understand the problem and the system, plan for it breaking, grow the people around them, and earn enough trust to move other teams and orgs.
If you try one thing this week: score yourself on the four rows, ask your manager to do the same, and start Days 1 to 30 of your roadmap.
There’s one skill this issue only touched, which is judgment, including when to say no. It deserves its own issue, and it’s coming.
Which row is holding you back from your next circle? Reply with your four scores, like 3-2-2-1, and the row you’re working on. The best answers become future issues.
If you want to go deeper
What Is Your Job Now?, Farhan Thawar at Cursor’s Compile 2026, on what an engineer’s job becomes when AI writes most of the code.
Kent Beck on which skills lost value and which gained via Simon Willison.
Vibe engineering by Simon Willison, on everything the job includes once agents write the code.
Andrej Karpathy’s case for agentic engineering from his Sequoia AI Ascent 2026 talk.
The Next Two Years of Software Engineering by Addy Osmani.
Become a Great Generalist or Extreme Specialist by Gregor Ojstersek, on why the middle gets squeezed.
How AI is changing my work as a staff+ engineer by Maxime Najim, LeadDev.
How AI is transforming work at Anthropic including what heavy AI use does to the skills you need to supervise it.
Canaries, interest rates and timing from the Stanford Digital Economy Lab, on early-career employment in AI-exposed jobs.
Measuring AI ability to complete long tasks from METR, on why you should assume the tools keep getting better.
Want the next one? Subscribe and you can reply to any issue. We read every reply, 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,