Essays
I write about leading engineers: the management decisions behind AI-first organizations, and what they cost. New essays land here and on LinkedIn.
The AI-First Playbook: what actually changed
Six weeks, 30 engineers, 80% daily adoption. The three things that changed for good, and the two that snapped back.
Nobody owns the seam
Cross team projects fail in the gaps between teams, where no one's name is on the work. What I do at the start of every collaboration to make sure the seam has an owner, and how I keep product, design, and sales from being surprised.
The economics of AI-first development
Seat prices are the smallest line item. Token economics, review cost, and the real cost of a bad rollout, with the numbers from ours.
Managing up is mostly writing things down
The leaders I have worked for well were not the ones I agreed with. They were the ones who never got surprised by me. What I send, when I send it, and how I disagree without losing the room.
Leading engineers through the AI transition
The fear of becoming disposable is real, and ignoring it stalls adoption. How I addressed it directly, and what the team did with the room it created.
How to reorganize without lying to anyone
Reorganizations fail in the announcement, not the org chart. What I do in the weeks before, what I say on the day, and the question every engineer is actually asking when the boxes move.
Shipping in week two
New hires on my teams ship production code in their second week. Not because they are special, but because onboarding is designed backwards from that moment. What the first ten days look like and what I stopped including.
Hiring for judgment
The interview loop I inherited measured how fast someone could code under observation. The one I run now measures whether they can tell good work from bad, including work a tool produced. What changed, what stayed, and where the candidates actually come from.
Growing a team without breaking it
Doubling a team is the fastest way to halve its output for two quarters. What I have learned about pacing growth, protecting the people already there, and the number I watch instead of headcount.
Retros that change something
Most retrospectives produce a list of action items that nobody looks at again. The ones that worked on my teams produced one change, tracked until it was real. How I run them, and the question I ask that usually finds the real problem.
The first time I managed a manager
Managing engineers is about the work. Managing managers is about the people they manage, seen through a layer you do not get to remove. The habits that did not transfer, and the ones I had to build.
What I say in the first hour of a bad week
Layoffs on another team, a cancelled project, a production incident that made the news. The first hour decides how the team remembers the whole thing. Here is what I have learned to do with it.
The pipeline was never the problem
Every diverse team I have built came from changing how we interview and how we run the room, not from a sourcing initiative. What actually moved the numbers, and what did not.
What calibration is actually for
Performance reviews are where managers find out whether they have been honest all year. Calibration is where they find out whether the other managers have. How I prepare, what I argue for, and the review nobody should ever be surprised by.
Recognition that costs nothing and recognition that costs something
A thank you in the team channel and a promotion are both recognition, and confusing the two is how managers lose people. How I use each, and the mistake I made for years.
People do not leave for money as often as you think
Every resignation I have received had a reason underneath the reason. Here are the ones that actually showed up, what I could have done about them, and the retention conversation I now have before it is too late.
The meeting I should have called sooner
Two senior engineers, one design decision, and three weeks of polite comments that were actually a fight. What I learned about resolving conflict before it costs a quarter.
Growth is a scheduling problem
Engineers do not grow from feedback alone. They grow from work that is slightly too big for them, handed over on purpose. How I plan that, and what it costs the roadmap.
Your best engineer is the one you are most likely to lose
High performers do not need less management. They need a different kind, and most of them are getting none at all. What I do differently with the people who carry the team.
Low performance is a diagnosis, not a verdict
Most engineers I have managed through a performance problem were not bad engineers. They were in the wrong setup. How I tell the difference, what a real improvement plan looks like, and when to stop.
Trust is built in the boring weeks
Nobody trusts a manager because of a speech. They trust the manager who did what they said during the forty weeks when nothing was on fire. What that looks like in practice.
What my 1:1s are for
The weekly 1:1 is the only meeting I refuse to cancel. Here is what happens in mine, what I stopped doing, and the three questions I ask every engineer at least once a quarter.