The Mind Map
A wiring diagram you can wander through.
The topics aren’t the point — the connections are. The same few threads keep surfacing whether I’m thinking about reliability or the Mahabharata, an org chart or a curse. Pick a node and follow where it leads.
← Back homeHow to wander
Start anywhere. The point is what happens next.
This isn’t a list of things I’m interested in. It’s a wiring diagram. Every node here earned its place by connecting to the others, and the connections are the actual subject — the topics are just where you grab on. Try it: start at Reliability. Stay with it long enough and it stops being about uptime and becomes about trust — who believes the system will hold. Trust is human behavior, which is the engine of every myth I’ve read, which is why I keep writing stories, which is the same instinct that makes someone follow you when you lead. Five steps, five disciplines, one thread. Wander like that. The map rewards it.
- Reliability
- Trust
- Human behavior
- Myth
- Stories
- Leadership
Unexpected connections
The map’s argument, in five small proofs.
None of these is me claiming expertise in two fields — it’s me noticing the same pattern showed up in both, and following it.
-
What mythology taught me about distributed systems
Every myth is a recovery doc: compressed memory about what happens when someone reaches past their limit, encoded to survive the people who weren’t there. That’s exactly what a runbook and a post-incident review are trying to be. The Mahabharata and a good RCA are the same genre — here’s what it cost, don’t pay it twice.
-
What architecture taught me about novels
A four-book arc needs the same dependency graph as a platform migration. Set up a payoff in book one and you’ve signed a contract you have to honor in book four. Foreshadowing is just good API design: expose a promise early, stay accountable for it later. I plot the way I’d sequence a cutover.
-
What cities taught me about scale
A city is the most honest large-scale system there is; it shows you exactly what it optimized for and what it deferred. One that blooms upward while rotting at the root is every codebase that chased features and skipped foundations. Cities and engineering orgs fail the same way, on different clocks.
-
What parenting taught me about leadership
My daughter asks sharper what if questions than I do, and she does it without once worrying whether it’s a dumb question. That’s the exact condition I spend most of my energy trying to build on a team. You can’t order someone to tell you the bad news; you can only make it cheaper to say than to hide.
-
What product strategy taught me about ancient kingdoms
Strategy is mostly the discipline of what not to build, and every kingdom that overreached is a roadmap that said yes to everything. The empires that lasted picked a few bets and defended them. The fall is almost always a focus problem wearing a map.
The threads
The patterns I can’t stop finding.
Pull any node and the same few threads come up attached to it — under the engineering, under the fiction, under the leadership. I didn’t choose them; I kept noticing they were already there.
-
Trust
The whole thing rests on it. Uptime is trust that the system holds; leadership is trust that you’ll do what you said; a privileged-data migration is trust that nothing leaks in transit. Engineering and storytelling are both, finally, about earning belief and not spending it carelessly.
And it’s the wound at the center of half my novels.
- Reliability
- Migrations
- Security
- Hiring
- Leadership
-
Power
Who gets to decide, and who pays for the decision. I wrote a crime novel to watch power hide in concrete and silence; I think about it every time I draw an Org Design boundary or sign off on a Security model.
An org chart is a power diagram whether you meant it to be or not.
- Cities
- Mythology
- Strategy
- Regulated
- Leadership
-
Memory
How knowledge survives the person who learned it. A recovery doc, a runbook, a myth, a well-commented schema — the same move: encode the hard lesson so the next person doesn’t relearn it mid-incident.
Every epic is compressed memory wrapped in faith so it lasts; so is good documentation, it just admits it.
- Mythology
- Systems
- Reliability
- Writing
- Migrations
-
Scale
What’s true of one stops being true of a thousand. Willpower doesn’t scale, heroics don’t scale, and a city shows you exactly what it optimized for at size.
The question is always the same — what holds when the load goes up an order of magnitude — whether it’s a service, a team, or a four-book plot.
- Systems
- Startups
- Cities
- Delivery
- Org Design
-
Incentives
People do what the system pays them to do, not what you asked. Reward the 3 a.m. save and you’ll get more 3 a.m. fires.
The quiet engine under every villain I’ve written who was just responding rationally to a broken game. Most failures I’ve debugged were an incentive problem in a technical costume.
- Psychology
- Hiring
- Execution
- Leadership
-
Identity
Under pressure, people act from who they believe they are, not from the role you gave them. The engineer who loved the war room wasn’t chasing the failure — he was chasing proof of who he was.
Threads the immortal warrior who outlives the meaning of his own name. Change what a person ships and you’re sometimes changing how they see themselves.
- Psychology
- Hiring
- Leadership
-
Coordination
The product is rarely the code; it’s how decisions travel between the people writing it. Forty engagements on three continents taught me that distributed systems break in the handoffs, not the modules — and so do teams.
Get the seams wrong and nothing else saves you.
- Delivery
- Org Design
- Execution
- Startups
-
Civilizations
The longest-running distributed systems we have. A city, a firm, a religion — millions of people staying loosely coordinated across time with no central thread, held together by shared memory and trust.
I read ancient kingdoms the way I read architecture diagrams: someone designed the incentives, and the ruins tell you where the design was wrong.
- Cities
- Mythology
- Regulated
- Future
- Systems
Ideas that rewired me
Shifts I can’t unsee.
Shifts I can’t unsee.
-
Conway’s Law
- Used to think
- Used to think architecture was a technical decision and the org chart an HR one, two separate whiteboards.
- Then saw
- Then saw the shape of the team quietly becomes the shape of what it ships, every time, designed or not.
- Now
- Now I draw team boundaries around the things that change together before I draw a single box in the architecture. It’s a tool, not a warning.
-
Incentives drive behavior
- Used to think
- Used to think people underperformed from lack of skill or will.
- Then saw
- Then realized almost everyone is behaving rationally inside the game they can see — and if the behavior is bad, the game is usually what’s broken.
- Now
- Now when something keeps going wrong I stop asking who to fix and ask what the system is quietly rewarding. Made me a better leader and a better novelist at once.
-
The map is not the territory
- Used to think
- Used to trust the dashboard, the status report, the diagram; if it said green, it was green.
- Then saw
- Then learned the model is a lossy compression of a messier reality, and the gap is exactly where the outage lives.
- Now
- Now I treat every clean abstraction as useful and suspect in equal measure. A green status hiding a slipping outcome is more dangerous than an honest red one.
-
Systems optimize what they measure
- Used to think
- Used to believe measuring more was always safer.
- Then saw
- Then watched a metric become the goal, and the moment it did, people optimized the number instead of the thing it stood for.
- Now
- Now I pick metrics like I’m handing someone a wish from a monkey’s paw, because that’s what I’m doing. What you count is a quiet statement of what you value.
-
Myths encode memory
- Used to think
- Used to read mythology as old stories, beautiful but finished.
- Then saw
- Then it clicked that a myth is a recovery doc: compressed memory about reaching past a limit, written to survive the people who weren’t there.
- Now
- Now I read epics and runbooks as the same genre — both saying here is what it cost last time, do not pay it again.
What I’m thinking about
A running notebook.
Where running engineering organizations, writing novels, and watching AI reshape both keep colliding — the questions behind the calls I actually make.
-
AI inside engineering orgs
The teams winning with AI aren’t writing the most code — they’re the ones whose judgment was already strong enough to absorb the speed. AI multiplies whatever discipline it finds, including none.
-
Leadership at scale
Past a certain headcount you stop managing the work and start managing the quality of the decisions made when you’re not there. Most of the job is making the good call easy to reach for without you.
-
Execution as communication
Most missed deadlines aren’t capability failures. They’re three people who each assumed someone else owned the seam. The fix is rarely faster typing — it’s saying out loud who owns what, and what “done” means.
-
Developer productivity
We measure output when the real question is whether the org stays correct as it speeds up. Velocity you can’t sustain just comes back as next quarter’s incidents.
-
Storytelling as leadership
A roadmap is a spreadsheet; a narrative is something people defend when it’s inconvenient. Four novels taught me that humans act on the story the data is wrapped in — a leader who can’t tell that story is just issuing instructions.
-
Mythology & modern systems
Every myth is a recovery doc — compressed memory about what happens when someone reaches past their limits, written for people who weren’t there the first time. Distributed systems and ancient epics solve the same problem: encoding hard-won lessons so the next person doesn’t relearn them mid-incident.
The Intersection
Where I spend most of my time
Engineering, storytelling, and human behavior look like three different jobs. They’re the same one, viewed through three lenses. The overlap is the most interesting real estate I know — and very few engineering leaders can credibly stand in it.
-
Stories make me a better leader.
A roadmap is just a plot — stakes, characters, and a third act people actually want to reach.
-
Systems thinking makes me a better writer.
A four-book arc needs the same dependency graph as a platform migration. Foreshadowing is just good API design.
-
Mythology sharpens product instinct.
Every myth is a user, researching the same fears we build products to soothe. The oldest stories are the deepest user studies.
-
AI is, in the end, a question about humans.
What we choose to automate is a quiet confession of what we actually value. I’d rather make that choice on purpose.
Still exploring
Questions I haven’t closed.
These don’t have answers yet — that’s why they’re still here. If any resolve cleanly, I’ll suspect I got it wrong.
- Can you build an organization that scales without optimizing the humanity out of it? I’ve watched systems absorb the load so people didn’t have to. I still don’t know the ceiling — the headcount where the systems start running the people instead of freeing them.
- What does AI actually do to judgment over time? It raises the floor on output, I’ve measured that. But if the machine drafts everything and the human only approves, does the muscle that knows why a thing is right quietly atrophy?
- If a capability arrives before the conscience to hold it, who’s accountable for the gap? The act takes a second now; the consequence still takes years. Nothing has closed that distance.
- Is reliability a virtue, or just an aesthetic I happen to prefer? I’d rather ship boring and dependable than brilliant and brittle — and I can’t fully separate engineering truth from temperament dressed up as principle.
- Do myths keep returning because they’re true, or because we keep needing them to be? Every age rewrites the same handful of stories. I can’t tell if that’s evidence they encode something real, or proof of how little we change.
- Can a system remember a lesson its original authors have all left? Documentation decays, context evaporates, the people who knew why move on. I keep trying to encode memory that outlives the team, and I’m not sure how much survives the handoff intact.
- What’s the real difference between a city, a company, and a religion? They all coordinate huge numbers of people across time on shared memory and trust. The more I look, the more they rhyme — and I can’t yet name what makes them genuinely different.
- Where’s the line between developing leaders of leaders and quietly making myself absent? I keep building the thing that runs without me. Some days I can’t tell if that’s leverage or just stepping back one room too far.
- How cheaply can an organization stay correct as it speeds up? Velocity is easy to buy and easy to fake. The number I actually care about is whether the org gets things right faster, not just more — and that one resists measurement.
Still wandering?
Want to pull a thread further?
If one of these connections sparked something — under the engineering, the fiction, or the space between — let’s compare notes.