I spent last week deep in a new agentic AI platform. The lessons that stuck had almost nothing to do with the technology.
I’ve been leading engineering teams for a few decades now, so I should have expected that. Every time I take on something new, I tell myself this one will be different, that the hard part will be the code. It never is.
Map the people before the architecture
Most of my week went to a question that sounds trivial and isn’t: who actually owns what?
It came up in an incident review. It came up again in a release quality discussion, and again at the kickoff for a new product. Same question, three different rooms. So I traced ownership across teams and time zones, sat in on org structure conversations, read an architecture decision doc, and spent real time on recruiting. Almost none of it involved reading code.
It’s tempting to open the codebase first. Don’t. A platform is a people-and-systems problem wearing a technology costume. If you can’t name the owner of each critical component, no design review is going to save you.
Draw the map first. Who owns what, who decides what, where the seams are. The technical priorities start sorting themselves once you can see it. Before your first design review, list every critical component with a single name next to it. The blanks are your real backlog.
Adoption is a behavior problem, not a feature problem
We have capable AI tools, and an honest question came up last week: How do we continue to drive adoption?
One early instinct in the room was to mandate it. Declare that certain work has to go through the tool. I understand the appeal, and sometimes a nudge is warranted. My first move was different. I asked to shadow our heaviest users and watch them work.
If the tool is better, usage is a pull problem, and the fastest way to create pull is to learn what your power users already figured out and make that the default for everyone else. Mandates manufacture compliance. They don’t manufacture belief. Simon Sinek wrote an entire book on the fact that people need to understand the why before they’ll change what they do, and nothing about AI tooling repeals that.
Find the three heaviest users of any new tool and watch them for an hour. You’ll learn more about adoption than any dashboard will tell you.
The best feedback teaches people to notice
An engineer ran a set of tests recently. The results were fine, but there was a meaningful shift between runs that I caught, and they hadn’t flagged.
My feedback wasn’t “fix the numbers.” It was that I’d expected them to catch the difference before I did. That’s a different bar, and I told them so directly.
Here’s the version of that instinct I admire most. SpaceX has been trying to get Starship Flight 13 off the pad all week. The first attempt aborted at T-0 on an engine start problem. They pulled two Raptors, replaced them, came back, and got scrubbed by weather. Tonight is the third window. Nobody on that team is waiting to be told the numbers look wrong. The entire discipline is built around noticing something small and being willing to stop.
That’s what I want on a release call. Holding a release is a leadership decision, and so is speaking up before someone senior asks you to.
So I paired the feedback with real questions. Why was this run better? Is it CPU or memory? Raising the bar and staying curious aren’t opposites. Carnegie’s whole argument was that you can hold someone to a high standard and still leave them wanting to meet it.
Aim your feedback one level above the task. Correcting the work fixes today. Coaching the instinct fixes every tomorrow.
Be your own most demanding user
I noticed something about my own week. I kept reaching for AI to do real work, not demos.
I used it to reconstruct where a stalled hiring requisition sat in the approval chain. To draft review comments on a root cause analysis. To sanity check a technical sizing question. To think through what a proposed process change would actually change day to day.
I also run a morning brief I built myself. It merges my calendars, flags the collisions before I walk into them, and lands in my task list before 7 am. Twice last week it caught a double-booking I would have missed, and once it told me I had to choose between two meetings I’d both said yes to. That’s a small thing, but I use it every single day, which is the only honest test of whether a tool is good. I keep a standing daily Todoist task to work on a personal project. It isn’t really about the project. It’s about staying close to what building actually feels like.
Two things stood out. First, it’s hard to ask a team to adopt tools you don’t lean on yourself. Dogfooding is the most honest product feedback there is. Second, I hit the tool’s edges in the process. It couldn’t safely edit a document in place the way I wanted, and that friction told me more about what to build next than any roadmap review has.
Use the thing. Feel the friction. Fix the friction.
Spend a week routing your own real work through the tool you’re asking others to adopt. Wherever it annoys you is your product backlog.
The thread running through all four
Technology was the easy part. The durable work sat in ownership, behavior, judgment, and the willingness to be your own toughest customer. The human systems around the tools.
Most of this thinking happened before 8 am, which is when my brain is most effective and I’m least distracted. I’ve stopped fighting it. The mornings go to the problems that need judgment, and the afternoons go to everything else.
Tonight I’m watching a rocket try again and then going to see Trombone Shorty play outdoors. Both feel like the right way to end a week spent thinking about people who keep showing up to do the hard part well.
Leave a Reply