The Fifteen-Minute Principal Engineer - by Mark Atwood
Words about Thoughts
SubscribeSign in
The Fifteen-Minute Principal Engineer<br>What AI compresses, and what it doesn't<br>Aug 06, 2026
Share
Sixty hours a week for seven years. Maybe four hours of that was irreducibly principal-engineer work.
I left Amazon two years ago, so I don't know how things work there now. But I know how they worked when I was there, and I've been running the numbers against current AI tooling. The conclusion is not flattering to anyone involved.<br>The bulk of my hours went to: reading and understanding code, writing code, writing documents, writing reviews of other people's documents, debugging, oncall triage, and responding to review feedback on my own work. Call it six hours of a ten-hour day on artifact production.<br>With current AI tooling (not hypothetical future AI, the stuff that exists right now), that six hours compresses to maybe thirty minutes of steering. The code gets written. The docs get drafted. The review feedback gets addressed. I'm not mass-producing slop; I'm directing a process that produces the same artifacts I would have produced, at twenty times the speed.<br>Fifteen minutes is probably underselling it. Call it an hour to be conservative.
What would I have done with those hours?<br>I had a list. Projects I wanted to contribute to. Open source work that aligned with Amazon's interests but never rose high enough in my priority stack because the day job consumed everything. Standards bodies where I had standing but not bandwidth. Internal tools that needed an owner and never got one because everyone was underwater.<br>There were a good dozen open source projects, foundations, and standards activities I wanted involvement in and couldn't get to. Two I particularly regret now: Matter and Unicode. Both were live and active during my tenure, both relevant to Amazon's interests, and both would have benefited from someone with my background showing up consistently. I couldn't show up consistently because I was underwater on artifact production for the projects already on my plate.<br>I was regularly working ten to twelve hours a day for seven years, not because I was inefficient but because the work expanded to fill the time. The artifact-production portion alone was that large.
Meetings compress too.<br>If I'd had AI transcription and summarization for every meeting I sat in, I could have skipped most of them entirely. The median meeting is fifty-five minutes of context-setting around five minutes of actual decision. AI lets you read the five minutes in ninety seconds and send a well-briefed position statement to the rest.<br>The meetings that actually needed me (live negotiation, relationship maintenance, the sessions where my physical presence was itself the signal) were maybe two or three hours a week. The rest was organizational metabolism I was forced to participate in because there was no other way to stay in the loop.
My recurring problem at Amazon was that I would often reach the conclusion faster than everyone else in the room. I'd been pattern-matching on similar problems for thirty years and could see where the argument was going before it got there. A source of friction, not a virtue.<br>AI makes that friction worse, not better.<br>If I was already hitting the answer in twenty minutes and then waiting forty-five for the room to catch up, AI just changes the ratio. Now I hit it in two minutes. The room still takes the rest of the hour. The organizational clock doesn't speed up just because I did.<br>The bottleneck at principal-engineer level was never my own processing speed. It was the speed at which the organization could absorb, align, and act: decision latency, approval chains, the slow accretion of buy-in, the need for other people to feel heard before they'd commit.<br>AI compresses my side of that latency. It doesn't touch the others.<br>But that lag is slack, not dead time. If I'm waiting forty-five minutes for the room to catch up to a conclusion I reached in two, those forty-five minutes are available for something else, as long as the something else doesn't require my full attention. Standards work fits that profile. Foundation governance fits that profile. The kind of asynchronous, document-heavy, "show up to the meeting prepared and then wait for the next meeting" cadence of open source foundations is exactly the shape of work that slots into organizational dead time.<br>I could have gone broader. Twelve conversations instead of three, waiting on all of them in parallel, using the lag from each to make progress on the others. The Matter working group, the Unicode Technical Committee, the projects I mentioned earlier that I never got to because artifact production for my existing work consumed all my hours.
I don't have a conclusion. I just have the arithmetic.<br>Sixty hours a week for seven years. Maybe four hours of that was irreducibly principal-engineer work, the thinking and the judgment calls. My most effective place to...