Engineering Leadership

Eighteen months ago, I wouldn’t have guessed we’d be removing Peer Review on pull requests. Over the last several months I’ve watched this team spend increasing effort trying to get pull requests reviewed. Not because people were avoiding reviews. Quite the opposite. They reminded each other in Slack, randomly assigned reviewers to beat the bystander effect, coordinated schedules, built skills and nudged each other throughout the day. Eventually I realized what this optimization of the review process was telling me. ...

I’m a systems person. The work I’m proudest of is the kind nobody notices: the test suite that catches the bug before review, the pipeline that makes the safe path the easy path, the process that quietly turns the right thing into the default. Get it right and the improvement compounds. You fix something once and it stays fixed, long after you’ve moved on. That instinct has served me well. When a team is slow and chaotic, the fix is usually structural. At one company we took release cycles from three or four months down to two weeks, not by asking people to try harder but by moving to trunk-based development, wiring up CI, and putting real quality gates in the path. The system became automatic. It was the default. People did the right thing because the right thing was the easy thing. ...

I build with AI every day, and I have pushed my teams to do the same. We have rolled out AI tooling across engineering, built production agents for the boring work, and I spend real time coaching engineers on how to get more out of these tools. I am not a skeptic. I think this is the biggest shift in how we build software in my career. So I want to be careful about how I say the next part, because it is not a complaint about AI. It is a warning about what AI does to us. ...