Everything I know about running engineering orgs, sorted by the size you actually are.
Twenty-five years of running engineering teams, written down in roughly the order things break. 9 tracks, 81 lessons, from your first hire to your first hundred and fifty. All of it free, none of it hedged.
Opinionated on purpose. Occasionally wrong, on the record.
9 tracks · 81 lessons · 5 stages · 0 paywalls
The whole curriculum, on one screen.
Every square below is a lesson. Tell it how many engineers you have and the ones that don't apply to you yet will step back. Hover anything to see what it argues.
Nine tracks, seventy lessons, every one of them free. Pick a size and the ones that don't apply to you yet will step back.
What it sounds like.
“You set the price. Not with a values statement. With about four seconds of your own face.”
Trust is a price, not a poster · Foundations
“Everyone will happily co-own the interesting new service. Nobody co-owns the reconciliation job.”
Ownership is the atomic unit · Teams & Structure
“A team that delivers the wrong thing with perfect efficiency has produced nothing.”
What high performance actually means · Foundations
Or never open this website again.
The curriculum is also an MCP server. Connect Claude Code, Claude Desktop, or ChatGPT and ask it about your actual situation while you work, instead of coming here to read. Early access is open and the lessons stay free either way.
How the MCP server works →claude mcp add --transport http tinycto \ https://tinycto.com/api/mcp \ --header "Authorization: Bearer <your-key>"
Come in through the problem.
Most people don't arrive looking for a curriculum. They arrive on a Tuesday with something specific going wrong.
“Nobody owns this service.”
Ownership is the atomic unit
“Everyone is busy and nothing ships.”
Throughput beats utilisation
“Someone isn't working out.”
Managing out, humanely and quickly
“Sales promised a date I didn't agree to.”
Managing up and sideways
Nothing here matching? Press ⌘K and describe it in your own words.