About
I learned leadership by being accountable for what happened next.
I'm John Munn. I've spent more than twenty years building software, leading engineers, and taking responsibility for systems after the launch meeting ended.
I have inherited code nobody wanted to touch, watched fast teams become slow organizations, and made plans that looked sensible until reality disagreed. The useful lessons did not come from having the right framework. They came from staying with the consequences long enough to understand them.
Today I write about engineering leadership, architecture, and AI systems. I am most interested in the point where a technical decision changes how people work—or where a people problem quietly becomes part of the architecture.
A few convictions
What experience changed my mind about
Architecture records the organization that made it.
When a system is difficult to change, I look at ownership, incentives, and communication before blaming the code.
A plan is only useful if somebody can say no.
Most delivery failures begin long before an estimate is missed. They begin when scope can enter but nothing can leave.
Clear writing is part of the engineering work.
If a consequential decision cannot be explained plainly, the team probably does not understand it well enough yet.
Why I write
Writing is how I test an idea before asking a team to live with it.
The essays here are working arguments, not a management playbook. Some begin with a mistake I made; others with a pattern I have seen often enough to distrust. I write them down so the claim can be examined rather than merely asserted.
I also write in the World of Artumin, where strategic and leadership ideas get tested through narrative rather than direct argument.
If you want to compare notes
Send me the situation as you understand it: the decision, the constraint, and the part nobody agrees on yet.