Playbooks.
The same lessons as the tracks, read standalone. Land here from a search, get the answer, and go deeper only if you want to.
What high performance actually means
Speed is a symptom. A high-performing org is one that converts judgment into shipped outcomes with very little loss along the way.
From FoundationsThe four loops every org runs
Delivery, learning, people, and strategy each run as a loop. Your org moves at the speed of the slowest one, and it is almost never delivery.
From FoundationsThroughput beats utilisation
A team booked at 100% has no capacity to absorb variance, so everything queues. Deliberate slack is what makes an org fast.
From FoundationsMeasuring an engineering org without lying to yourself
Every engineering metric is gameable. Use them as conversation starters and outlier detectors, never as scoreboards.
From FoundationsOperating cadence: the org's heartbeat
Weekly is the only standing cadence that earns a permanent slot. Anything slower should be written, not met, and most dysfunction is one missing meeting or one extra one.
From FoundationsTrust is a price, not a poster
Psychological safety is not niceness. It's the observed cost of telling the truth, and you set that price with your own reactions.
From FoundationsDiagnosing an org in two weeks
You can find an engineering org's real constraint inside a week, if you follow work items rather than opinions. Ten days is the padded version you promise other people.
From FoundationsNew value versus keeping the lights on
Most orgs can't say what fraction of their capacity built something new last quarter versus kept the lights on. Look at the split occasionally. The moment it becomes a target, it starts lying to you like every other metric does.
From PeopleYour first ten engineers
The first ten hires are not employees, they are the constitution. Everything you tolerate in them becomes policy for the next hundred.
From PeopleThe bar: define it, write it down, hold it
A hiring bar that lives in people's heads drifts downward, and not only under pressure. Comfort is the force nobody names. Write the criteria, then give somebody other than the decision-maker standing to invoke them.
From PeopleInterview loops that predict performance
Most loops measure interview skill. Give each stage exactly one job, and let the highest-weight stage be a structured judgment conversation with the people who'll actually work with the person.
From PeopleLevels and ladders, later than you think
A career ladder written too early encodes a company you don't have yet. Write it when the same fairness argument has surfaced two or three times.
From PeoplePerformance management without the theatre
If a review surprises someone, the process already failed. Run feedback continuously through one-to-ones, and keep exactly one scheduled formal ritual: the 360.
From PeopleCompensation that doesn't leak
Comp is a system, not a negotiation. Bands visible internally, a stated market position, and an annual correction pass prevent most of the damage.
From PeopleManaging out, humanely and quickly
Once the decision is made, days rather than months. But speed only works on top of honesty. The team already knows if you've been having the conversations, and if you haven't, fast just reads as arbitrary.
From PeopleGrowing managers out of engineers
Promoting your best engineer into management is a coin flip unless you've already handed them the job in pieces and they've come back for more.
From PeopleOnboarding that pays back in 30 days
Time to first meaningful change is the most honest measure of your engineering environment. Onboarding is a stress test you run on yourself, with a fresh pair of eyes attached.
From Teams & StructureTeam size, structure, and cognitive load
Team size is a function of how much system a group of humans can hold in their heads, not of how much work there is to do.
From Teams & StructureConway's law as a design tool
You will ship your org chart whether you meant to or not. So draw the architecture you want, then draw the org that produces it.
From Teams & StructurePlatform teams: when, why, and when not
A platform team formed too early builds abstractions for problems nobody has. Formed too late, it inherits five incompatible ones.
From Teams & StructureEmbedded vs centralised: design, data, QA, security
Embed the specialists in the teams, centralise the standard. Neither pure model survives contact: embedded alone drifts, centralised alone becomes a queue.
From Teams & StructureOwnership is the atomic unit
Almost every system, service, and surface needs exactly one owning team. Shared ownership is usually unowned, and unowned things decay in a predictable order.
From Teams & StructureOn-call that doesn't burn people
The people who built it carry it, always. On-call load is a design signal, and a rotation that hurts is the system telling you something the roadmap isn't.
From Teams & StructureDesign is not a paint layer
Design applied after the technical decisions are made can only make bad decisions look better. Its leverage is upstream, in the framing of the problem, not downstream in the polish pass.
From Teams & StructureThe real cost of a reorg
A reorg costs roughly a quarter of throughput and buys you a different set of problems. Do it only when you can say plainly that the current structure is the constraint.
From Teams & StructureThe platform team you already have
A platform team justified by a recurring pain has one real test once it's running: has that pain actually stopped. Adoption and satisfaction scores are a distraction from the only question that matters.
From DeliveryThe weekly demo
A standing demo where working software is shown to real stakeholders is the cheapest forcing function in engineering management. Mandatory, never cancelled.
From DeliveryPlanning without fortune-telling
Plans are for alignment, not prediction. Commit to outcomes and dates separately, and be explicit about which one you're holding fixed.
From DeliveryEstimation is a conversation, not a number
The value of estimating is the disagreement it surfaces. The number itself is nearly worthless, and you can forecast better from throughput than from anyone's guess.
From DeliveryWIP limits and the queues you can't see
Most delay in software is waiting, not working. You need one rule people will actually keep: nobody starts something new while the review queue is red.
From DeliveryRoadmaps that survive contact
A roadmap is a communication artefact with a shelf life. Now / Next / Later beats a Gantt chart because it tells the truth about certainty.
From DeliverySaying no, and the true cost of yes
Every yes is a permanent liability that arrived disguised as a one-time cost. What an organisation declined is a truer description of its strategy than what it built.
From DeliveryShipping culture vs launch culture
Launch culture optimises for a moment. Shipping culture optimises for a slope. Only one of them compounds, and the difference shows up in what people choose to work on.
From DeliverySmall batches, or nothing else matters
Batch size is the master variable of software delivery. Almost every other improvement is downstream of shipping smaller things more often.
From DeliveryThe product trio, not a feature factory
A roadmap owned by one function is a request queue. Product, design, and engineering have to co-own the why before any of them can be trusted with the how.
From DeliveryDiscovery is a track, not a phase
Discovery-then-delivery is a relay race with a baton drop built in. One continuous discovery track running in parallel with delivery, always, is what actually de-risks a roadmap.
From TechnologyArchitecture decisions that age well
Write down the decision, the alternatives you rejected, and the conditions that would make you revisit it. Future you is a stranger with no context.
From TechnologyBuild, buy, or borrow
There's no default rule worth having here. Three tests decide it: is this what customers pay us for, who carries it at 3am, and what does it cost to get out.
From TechnologyTech debt as a balance sheet, not a feeling
Debt is the gap between the system you have and the one your roadmap needs. Price it against specific upcoming work and pay it inside that work, never in a scheduled debt sprint.
From TechnologyThe monolith you should probably keep
A service is earned when a workload's operating characteristics genuinely diverge and a specific team can own that failure domain. Not at a headcount threshold, and never because the codebase feels large. Most of the time what you actually want is a stateless monolith.
From TechnologyDeveloper experience as a product
Setup time, build time, review latency, and deploy time are the compound-interest numbers of an engineering org. Everyone pays them, every day, and nobody bills for them.
From TechnologyThe data model is destiny
You can refactor code in an afternoon. A wrong core entity outlives three rewrites and quietly decides what your product is allowed to become.
From TechnologyBoring technology, deliberately chosen
You get a small number of innovation tokens. Spend them where your product is actually differentiated and buy the rest off the shelf.
From TechnologyCloud cost is an engineering metric now
Unit cost belongs on the same dashboard as latency and uptime, watched by the people who can actually move it. Engineering owns the number, finance partners on it.
From Quality & ReliabilityA testing strategy for people who ship
Tests exist to let you change things confidently. Any test that doesn't increase your willingness to deploy on a Friday is overhead.
From Quality & ReliabilitySLOs you'll actually honour
An SLO you won't stop feature work to defend is a decoration. Set two or three, mean them, and write down what happens when the budget is gone before you need it.
From Quality & ReliabilityIncident response under pressure
Mitigate first, understand second. During an incident, clear roles and honest communication matter more than technical brilliance.
From Quality & ReliabilityPostmortems without blame theatre
Blameless isn't a tone, it's a method: keep asking what made the wrong action look reasonable at the time. Every incident gets one, including the near misses.
From Quality & ReliabilityThe deploy pipeline as a safety net
Optimise for rollback speed, not release care. Every change behind a flag, no persistent staging, and a release that's just a merge.
From Quality & ReliabilityObservability before you need it
You cannot retrofit visibility during an outage. Instrument the few things that answer "is it working for users right now", and do it before you need the answer.
From Quality & ReliabilitySecurity posture for small teams
There's a short list of controls that prevents almost every realistic outcome. Do that list completely, and don't start anything else until it's done.
From LeadershipThe job changes four times
Builder, multiplier, architect of the machine, then steward of the strategy. Each transition invalidates the habits that got you promoted.
From LeadershipDecisions, disagreement, and speed
Most decisions are reversible and belong to one person, made in minutes. Consensus is reserved for doors that only open one way.
From LeadershipWriting is the leadership multiplier
Writing is the only thing you do that reaches people you'll never meet, in rooms you're not in. Major decisions get a document before they get a meeting.
From LeadershipDelegation without abdication
Delegating an outcome means handing over the decisions that come with it. What you keep is the definition of done and the frequency of checking.
From LeadershipManaging up and sideways
Your peers in sales, product, and finance aren't obstacles, they're constraints with reasons. Translate engineering into their currency and most of the friction goes away.
From LeadershipWhat your boss is carrying
The person you report to is carrying two or three specific worries, and almost none of your work is pointed at them. Find out what they are and solve one.
From LeadershipComplaints and proposals
A complaint hands someone a problem plus the work of deciding what to do about it. A proposal hands them a decision. Same information, completely different weight.
From LeadershipThe board and the exec team
A concise monthly written note, and no surprises, ever. Boards want confidence that you see reality clearly, not detail about how the system works.
From LeadershipHard conversations
Have it early, plainly, and once. Early means the second occurrence, not the first and not the fifth, because that's when a thing stops being an incident and becomes a pattern.
From LeadershipYour calendar is your strategy
Whatever you actually spend hours on is your real strategy. Everything else is an aspiration you've written down, and the calendar is the only honest record of which is which.
From LeadershipYou don't know half their story
You're comparing your full interior record against someone else's edited exterior, and losing. Compare against yourself twelve months ago and against the job you want to be able to do.
From ScalingWhat breaks at every size
Org failures arrive on a schedule. Knowing which one is next turns a crisis into a maintenance task you did early.
From ScalingFrom five to twenty
This is where informal coordination stops working. Add the smallest amount of structure that a repeated failure has already justified, and not one increment more.
From ScalingFrom twenty to fifty
You stop knowing everything and start managing through others. The thing that degrades first isn't quality or communication, it's decision speed.
From ScalingFrom fifty to one hundred and fifty
You're now running a system that runs the work. Your leverage is the quality of your leaders and the clarity of what you've written down.
From ScalingHiring plans and budget, in the CFO's language
A headcount request is a bet about next year's output. Argue it bottom-up from outcomes and unit costs, in the CFO's language, never as a number you need.
From ScalingProcess debt
Process accumulates like code and gets removed far less often. Every rule should name the failure it prevents and when that failure last happened, or it goes.
From ScalingKeeping speed at scale
Big organisations aren't inherently slow. They're slow because coordination cost grows quadratically unless you deliberately design it down, and a strong platform layer is what buys most of it back.
From Agentic EngineeringWhat agentic actually means
"Agentic" doesn't mean a smarter autocomplete. It names a loop that plans, acts, and checks its own work without a person approving each step, and that loop is what changes both the value and the risk.
From Agentic EngineeringWhere agents earn their keep
The payoff is real in the parts of the job that are well-specified, bounded, and checkable. It's close to zero everywhere the actual work is judgment under ambiguity.
From Agentic EngineeringReview capacity is the new bottleneck
Generation got cheap. If review, testing, and judgment don't scale with it, you've built a bigger queue, not a faster team.
From Agentic EngineeringAutonomy levels and blast radius
The permission an agent has, not the model behind it, is the real governance question. Decide autonomy per task and its reversibility, not once for the whole tool.
From Agentic EngineeringEvals, not vibes
"It feels faster" is not a measurement. The organisations getting real value from this are the ones that measured something specific before and after.
From Agentic EngineeringWhat junior engineers should be learning now
The apprenticeship that built engineering judgment ran on writing a lot of mediocre code and getting it corrected. That loop is gone, and it didn't need rebuilding so much as replacing: juniors who review more than they write, and ship sooner, grow faster than the old one ever managed. The failure isn't the agent writing the code. It's the junior not reading it.
From Agentic EngineeringBuild vs buy for agent infrastructure
Buy the model, buy the harness. Build the context and the guardrails. Most of what actually differentiates your setup, and most of the risk, lives in those last two.
From Agentic EngineeringThe spec is what you review now
For well-specified work, the spec is what gets approved, not the diff behind it. Get the spec wrong and you've automated the mistake instead of catching it.
From Agentic EngineeringContext is maintenance, not a build
Agent context files don't rot because nobody cares. They rot because updating them was never anyone's job. The team that changes the behaviour maintains the file, and one named leader is accountable for whether it still tells the truth.
From Agentic EngineeringThe conversation about jobs
The first question is about jobs, whether or not anyone asks it out loud. You can't promise an outcome you don't control, and the promise you make instead has to be one you'll still be keeping in a year.
From Agentic EngineeringTeam composition when review is the constraint
Team composition was sized for authorship being scarce. When review is the constraint, the team that ships fastest is usually smaller, owns less surface, and has moved the first pass of review off people entirely.
From Agentic EngineeringAgents amplify what's already there
Agentic tooling doesn't fix a weak team, it amplifies it faster and louder. Audit testing discipline and ownership clarity before you scale adoption, not after.