How I Work

Programs are guidance systems. Not task lists.

A standup degrades into a status report. A retro surfaces problems everyone already knew. Quarterly planning produces slides nobody references again. The ceremonies look like alignment. They aren't.

My graduate work was in guidance systems for rockets — sensing position, computing trajectory, adjusting before errors compound. Rockets don't wait until they miss the orbit to check if they're on course. Neither should software teams.

At AWS, six weeks before a planned launch, I caught a critical gap in the technical specification that nobody else had flagged — because I was the only person reading both the frontend and backend specs. That kind of catch doesn't come from a status meeting. It comes from someone who knows the system well enough to sense when something doesn't fit.

Clear Context

Documentation is infrastructure, not a deliverable. ADRs that capture why, runbooks as code, domain language that shapes how the whole system is designed. Stale documentation is worse than none — it's a gauge stuck on green.

Active Communication

The information usually exists. It just doesn't reach the person who can act. I track dependencies across teams and route decisions to the people they affect — before cross-team surprises turn into cross-team rework.

Shared Culture

Culture is what lets people make the decisions you haven't anticipated. It forms through shared decisions over time — code reviews, architecture debates, studying how past choices aged. No shortcut, but you can create the conditions.

AI accelerates building. It also accelerates misalignment. When implementation takes days instead of weeks, the ratio flips: alignment becomes the dominant cost. Speed without alignment is divergence with velocity.

Read Guidance System for Software Teams →