The vocabulary of organisations, ownership and delivery

What it is

The terms that describe where work gets stuck and who is allowed to unstick it. This is the largest of the three language pages because it is where a lead spends most of their words: the costs that organisations pay without noticing (the taxes), the flow concepts that explain why adding people does not help (constraint, critical path, WIP), the ownership concepts that determine whether anything gets decided (decision rights, DRI, escalation path), and the mechanisms that make an outcome recur rather than happen once.

The organising claim, and it is worth holding explicitly: almost every "we are moving too slowly" problem is one of four things. A queue nobody is measuring, a decision nobody owns, a cost nobody has priced, or work in progress nobody has limited. The vocabulary below is organised around those four, because a term that helps you identify which one you are looking at is worth more than a term that merely sounds senior.

Don't be confused: a mechanism is not a process, and the difference is what interviewers are listening for. A process is a set of steps people are expected to follow. A mechanism produces the outcome whether or not anyone remembers to care: it has an owner, a trigger, a forcing function and an output that someone would notice the absence of. "We agreed to review dependencies quarterly" is a process and it will lapse by the second quarter. "The dependency report is generated automatically, lands in the team channel, and the platform lead is named on it" is a mechanism. When asked "how do you stop this recurring", answering with a process is the most common way to give an answer that sounds right and scores low.

The problem it solves

Organisational costs are mostly invisible, and invisible costs never lose an argument because they are never in it. Every one of the "tax" terms below exists to make one of these costs sayable: the ongoing price of a dependency between two teams, of a shared database, of a self-hosted system, of an architecture that a team cannot hold in its head. Once a cost has a name, it can appear in a comparison, and once it appears in a comparison it can win.

The flow vocabulary solves the opposite problem: too many visible things. When delivery is slow there are twenty plausible causes and no way to rank them. Constraint, critical path and queue discipline give a ranking, and the ranking is usually surprising, which is the point.

Mechanics

The taxes: costs paid continuously, noticed rarely

Coordination tax: productivity lost because people or teams must synchronise. "Splitting this across four teams adds more coordination tax than technical value." Coupling tax: the ongoing cost of dependencies between systems. "The shared database is a significant coupling tax." Integration tax: the recurring cost of connecting things built independently. "Supporting five auth providers is a permanent integration tax." Operational tax: the burden of running something. "Self-hosting gives us control and a substantial operational tax." Carry cost: the ongoing cost of keeping any decision around. "Every additional datastore has a carry cost."

They are variations on one move, and the move is what matters: convert a one-time-looking decision into a recurring cost. The reason this wins arguments is that build-versus-buy and split-versus-consolidate discussions are almost always framed as one-time comparisons, in which the option with the lower upfront cost wins by construction. Naming a tax changes the units.

Cognitive load: the mental effort required to understand or operate a system. "The architecture is elegant and imposes too much cognitive load." This is the one with the most theoretical backing, from Team Topologies, which argues team boundaries should be drawn so that each team's domain fits within its cognitive capacity. Its practical power is that it makes "this is too much for this team" a design statement rather than a complaint about the team, which is the difference between a conversation that goes somewhere and one that offends people.

Toil: repetitive manual operational work that scales with service size and produces no lasting value. "Certificate rotation is our biggest source of toil." The SRE definition is strict and the strictness is the value: toil is manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly with growth. Work failing those tests is not toil, it is just work you dislike. Google's SRE practice puts a numeric cap on it, 50 percent, and having a number is what makes it a constraint rather than an aspiration.

Undifferentiated heavy lifting: necessary infrastructure work that gives no competitive advantage. "Running our own broker is undifferentiated heavy lifting." The phrase is Amazon's and it is the core buy-over-build argument. The counter to have ready, because a good interviewer will push: the boundary moves, and something undifferentiated at your scale can be your entire advantage at another. A search company running its own retrieval stack is not doing undifferentiated heavy lifting; a payments company doing the same thing is.

Force multiplier: something or someone that makes others substantially more effective. "A platform team should be a force multiplier, not a service desk." Worth using sparingly and precisely, because it has been diluted into a compliment. The precise use is comparative: this work makes N other people faster, therefore it is worth more than the same effort spent directly.

Flow: why the obvious fix does not work

Constraint: the limiting factor on throughput. "If QA capacity is the constraint, adding developers will not increase throughput." This is Goldratt's theory of constraints in one word, and it earns its place because improving anything other than the constraint improves nothing, which is deeply counterintuitive and is why teams work hard and get faster at nothing.

Critical path: the dependency sequence that determines the earliest possible completion. "The frontend is not on the critical path; the data backfill is." Long pole in the tent: the same idea, informally, for the component that determines the timeline. "Data migration is the long pole." Both let you say the most useful sentence in project planning, which is that work not on the critical path is free to be late, so effort spent accelerating it is wasted.

Move the bottleneck: what happens when you fix a constraint and expose the next one. "We sped up development and moved the bottleneck to code review." This is essential for setting expectations, because it predicts that the first improvement will disappoint, and predicting a disappointment in advance is how you survive it politically.

WIP limit: a cap on concurrent work in progress. "The team needs a WIP limit, not more parallel projects." The argument is Little's Law: cycle time equals work in progress divided by throughput, so with throughput roughly fixed, halving WIP halves cycle time, and it does so without anyone working harder. It is the single most reliable intervention available to a new lead, and it is the one teams resist most, because starting feels productive and finishing feels slow.

Queue discipline: the rules governing how queued work is ordered and served. "Changing queue discipline may improve tail latency without adding capacity." The lead application is that most teams run their review and support queues FIFO by accident, never having chosen, and that shortest-job-first or an explicit priority class is often strictly better and free.

Ownership: who is allowed to decide

Decision rights: who has authority over which decisions. "The problem is not accountability, it is that decision rights are unclear." This is frequently the actual diagnosis when a team is stuck, and it is invisible until named, because everyone assumes the question of who decides was settled and nobody checks.

DRI, directly responsible individual: one named, accountable person. "Who is the DRI for the migration?" Apple's term, widely adopted. The value is the singular: a group is not a DRI, and "the team owns it" is how things stop being owned.

RACI (responsible, accountable, consulted, informed) is the heavyweight version and is worth naming with a caveat: it is genuinely useful for a cross-team programme with unclear boundaries, and it is bureaucratic overkill for one team's work. Say which you would use and why. Two-in-a-box: two leaders jointly responsible, usually product and engineering. "We run product and engineering two-in-a-box."

Ownership boundary: the explicit division of responsibility between teams. "The incident exposed an unclear ownership boundary." Note that ownership boundaries and Conway's law interact: an unclear ownership boundary reliably produces a bad interface, because there is no one to negotiate it.

Escalation path: the defined route for resolving something beyond local authority. "We need a clear escalation path for cross-team blockers." The specific failure this prevents is the two-week silent block, where a team is stuck on another team and nobody has said so to anyone with the power to resolve it, usually because escalating feels like an accusation. Naming the path in advance removes the social cost of using it, which is the whole point.

Hero culture: an organisation dependent on individuals repeatedly rescuing it. "We should fix the process rather than reward hero culture." The mechanism worth explaining is that heroism is self-perpetuating: it resolves the incident, which removes the pressure to fix the cause, and it is rewarded, which produces more of it. Recognising the hero and fixing the system are not in tension, and saying both is the mature version.

Talking: the phrases that shape a discussion

Disagree and commit: state the disagreement, then support the decision once made. "I still prefer Postgres, but I will disagree and commit to DynamoDB." The important half is the first one, and the phrase is regularly abused to mean "stop arguing", which inverts it. It requires that the disagreement was actually heard and recorded; without that it is compliance with extra syllables.

Strong opinions, loosely held: have a defensible position and update on evidence. Useful as an aspiration and worth being slightly wary of, because in practice it often licenses the strong opinions without the loose holding. The better operational form is to state in advance what would change your mind, which is falsifiable in a way the slogan is not.

Challenge the premise: question the assumption behind the question. "Before we discuss Kafka, I want to challenge the premise that this needs to be asynchronous at all." One of the highest-value moves available in a design interview, because a large fraction of design questions contain an unnecessary assumption, and because it demonstrates that you engage with problems rather than with tasks.

Work backward: start from the outcome and derive the implementation. "Work backward from the latency SLO rather than starting from the technology." Amazon's working-backwards process (write the press release first) is the formal version, but the everyday use is simply refusing to start a design from the components.

Bikeshedding: disproportionate attention to trivia. "We are bikeshedding names while the consistency model is unresolved." Yak shaving: a chain of prerequisites before the actual task. "I wanted to change one endpoint and ended up yak shaving the CI pipeline." Boil the ocean: attempting an unnecessarily vast scope. "Let us not boil the ocean; solve recommendation freshness first." Gold-plating: sophistication beyond the requirement. "Multi-region active-active is gold-plating at our current scale." Premature abstraction: generalising before you have the cases. "I would rather duplicate this twice than introduce a premature abstraction."

Metrics and avoidance

Leading indicator: predicts a future outcome. "Review queue depth is a leading indicator of cycle-time deterioration." Lagging indicator: reports an outcome that already happened. "Availability is mostly a lagging indicator." The value of the pair is that leading indicators are the only ones you can act on, and most dashboards are entirely lagging.

Proxy metric: a measurable stand-in for what you care about. "PR count is a weak proxy for productivity." Vanity metric: impressive and decision-free. "Lines of code is a vanity metric." Counter-metric or guardrail metric: paired with a target to catch the obvious gaming. "Click-through is the target; unsubscribe rate is the guardrail." The mechanism behind all three is Goodhart's law, and the practical rule is that a target without a guardrail will be met in the cheapest available way.

Paper over: hide a problem with a superficial fix. "Raising the timeout papers over the contention." Kick the can down the road: defer rather than solve. "Another exception just kicks the migration down the road." Tax the happy path: degrade the common case for a rare one. "Do not tax the happy path for a 0.1 percent edge case." Pay down debt and debt service: "That integration consumes 20 percent of the team's capacity in debt service."

Of these, debt service is the one that changes outcomes, because a percentage of capacity is a number a finance-literate manager can act on, whereas "we have a lot of technical debt" is a mood.

Worked example

A team is late. Three diagnoses, in the order they usually get offered, and what the vocabulary does to the conversation.

Diagnosis one, the default: "The team needs to move faster; can we add two engineers?" Brooks's law says this makes it later, but that argument alone rarely wins because it sounds like an excuse.

Diagnosis two, better: "Let me look at where time actually goes before we add people." A week of measurement finds: median cycle time 9 days, of which 5.5 is waiting for review, 1 is waiting for a deploy slot, 2.5 is work. Six items in progress across four engineers.

Diagnosis three, the one that gets funded: "Cycle time is 9 days and under 3 of those are work, so this is not a capacity problem, it is a queueing problem, and adding people would add coordination tax to a system whose constraint is review. Three changes. A WIP limit of one per person, because by Little's Law cutting WIP from six to four should cut cycle time by roughly a third with no other change. A review rotation with a same-day expectation, which attacks the 5.5 days directly and costs nothing. And deploy on merge instead of the Thursday window, which removes the last day and is a no-regret move anyway. My prediction is cycle time under 4 days in six weeks, and my counter-metric is change failure rate, because the obvious way to hit that target dishonestly is to ship worse. If it does not move, my diagnosis was wrong and we should revisit headcount then, not now."

What made the third version work: it names the constraint, it prices the alternative (coordination tax), it cites a mechanism for the prediction rather than asserting one, it attaches a counter-metric, and it commits to a falsification condition. That last element is what distinguishes an analysis from an opinion, and it is what makes it safe for a manager to back you, because you have told them how they will know if you were wrong.

Production evidence

WIP limits and their effect on cycle time are the most empirically grounded item here. Little's Law is a theorem, not a heuristic, and its application to knowledge work is the foundation of Kanban practice; Daniel Vacanti's work on flow metrics documents the relationship in real delivery data. The prediction that halving WIP halves cycle time at constant throughput is arithmetic, which is why it is worth stating with confidence.

Toil's 50 percent cap is documented Google SRE practice: SRE teams are meant to spend at least half their time on engineering work, and exceeding the toil budget is treated as a signal to hand operational load back to the development team. The enforcement mechanism is the interesting part rather than the number: a cap with no consequence is a preference.

The DRI convention is long-established Apple practice, widely reported and widely copied; its function is that every item on a meeting agenda has one name against it.

Theory of constraints comes from manufacturing (Goldratt's The Goal, 1984) and reached software through The Phoenix Project. The transfer is legitimate because the underlying mathematics is queueing theory, which does not care whether the items in the queue are car parts or pull requests.

Team Topologies' cognitive-load-based team sizing has been adopted publicly as the basis for platform charters at several large organisations, and the associated claim, that a platform's job is to reduce the cognitive load of stream-aligned teams, is what distinguishes a platform team from an infrastructure team in most modern charters.

The debate

Are WIP limits universally good? No, and the exception matters. WIP limits assume work is blockable and that a blocked person can help elsewhere. In a team with extreme specialisation (one person who can touch the ML model, one who can touch the iOS app), a strict WIP limit idles people, because the work they could pull is work they cannot do. The correct response is to treat that as the finding rather than to abandon the limit: the specialisation is the constraint, and the fix is cross-training or a different team boundary, both of which take a quarter. My position: introduce the WIP limit, expect it to make specialisation visible and uncomfortable, and use that visibility as the argument for the structural fix. Do not set the limit so low that it produces idleness in month one; start at roughly one and a half items per person and tighten.

Is "undifferentiated heavy lifting" a good reason to buy? It is a good frame and a bad conclusion, because it smuggles in an assumption about where your differentiation is, and that assumption is exactly the strategic question. The version I would defend: buy when the capability is not differentiating and the managed option's constraints do not bind you and the exit cost is bounded. All three, because the common failure is buying something genuinely undifferentiated whose constraints turn out to bind hard eighteen months later, at which point the switching cost is the whole argument. Name the exit cost when you make the recommendation.

Does "disagree and commit" belong in a healthy team? Yes, with a limit worth stating. It is the correct resolution when a decision must be made, the disagreement has been genuinely heard, and the decision is reversible enough that being wrong is survivable. It is the wrong resolution when used repeatedly on the same person, which is how you convert a dissenter into someone who has stopped speaking, and when applied to one-way doors, where the cost of overriding a well-founded objection is unbounded. The health check: how often has the person invoking it been on the other side of it? If a leader always asks others to disagree and commit and never does so themselves, the phrase has become a euphemism.

Should individual metrics ever be used? Covered as a position elsewhere in this book and worth restating in the vocabulary frame: individual output metrics are proxy metrics for something (impact) that is not measurable at the individual level in collaborative work, they are subject to Goodhart within one cycle, and they tax exactly the glue work that does not appear in any of them. Use them privately as a signal to look, never publicly as a judgement. The one legitimate published exception is metrics about the system that happen to be per-person, such as on-call load, where the point is to detect unfairness rather than to rank.

Follow-up Q&A

How do you find the constraint without instrumenting everything? Look for the queue. The constraint is almost always immediately upstream of the longest wait, and you can find it by walking a handful of recently completed items backwards and marking timestamps at each state change. Ten items done by hand in an afternoon is enough to find it, and it beats a dashboard project that takes a quarter. A useful shortcut: ask the team where work waits, then verify. They usually know, and the verification is what makes it actionable to people outside the team.

A platform team is being treated as a ticket queue. What do you change? That is the "force multiplier versus service desk" failure and it has a structural cause: the platform is supplying labour rather than capability, so demand scales with the number of consuming teams. The fix is to move up the interaction modes: turn the top ticket categories into self-service, so the team consumes a product rather than a person's time, and be explicit that the paved road is the supported path while off-road use is unsupported. The measure to watch is the ratio of self-service actions to tickets, and if it is not moving, the self-service path is not good enough and the tickets are telling you exactly which part.

How do you introduce a mechanism without adding bureaucracy? Three tests before adding one. Does it have a single owner who would notice its absence? Does it produce an artifact someone outside the team reads? Does it have a removal condition, a statement of what would have to be true for us to stop doing it? A mechanism failing the third test is how bureaucracy accumulates, because nothing in an organisation is ever removed for lack of a reason to keep it. Attaching an expiry or a review date at creation is the cheapest possible defence, and it costs one sentence.

What is a closed loop and why does it matter for ML systems specifically? A closed loop is one where outcomes feed back into future decisions rather than being observed and forgotten. "Recommendation evaluation needs a closed loop from impressions through to model changes." It matters disproportionately in ranking and recommendation because the system's own output shapes the data it will train on next, so an open loop does not merely fail to improve, it degrades: you learn from a distribution you created, which is the feedback-loop problem behind popularity bias. The lead-relevant question is whether anyone owns the loop end to end, because the loop typically crosses a team boundary (serving, logging, training) and a loop with three owners has none.

What is the difference between an operating mechanism and a meeting? An operating mechanism is a recurring process with a named owner, a defined input, a defined output and a decision that gets made. A meeting is a slot in a calendar. "The dashboard is not the solution; the weekly review with a named owner and a written decision is the operating mechanism." The test: if nobody prepared, would the session still produce a decision? If yes, it is a meeting and it should be an email. If the absence of preparation would be noticed, it is a mechanism.

How do you tell essential complexity from accidental complexity in practice? Ask whether a competitor solving the same problem with a completely different stack would also face it. Exactly-once financial posting: yes, everyone faces it, essential. Three serialisation formats because of a historical migration: no, accidental. The test is imperfect and it is fast, and it usually settles the argument, because accidental complexity tends to have a date attached to its origin and essential complexity does not.

Common misconceptions

"Adding people increases capacity." It increases capacity only if the constraint is labour and the work partitions. Otherwise it adds coordination tax against unchanged throughput, which is Brooks's law with its mechanism attached.

"A DRI means one person does the work." It means one person is accountable for the outcome and for making sure the decisions get made. They may do none of the work.

"Toil is any work I dislike." Toil has a definition, and it is manual, repetitive, automatable, tactical, without enduring value, and scaling with growth. Difficult non-repetitive work is not toil, and calling it toil devalues the term when you need it.

"Cognitive load is about how smart the team is." It is about how much system there is. A brilliant team of four cannot operate twelve services well, and framing this as a capability question rather than a boundary question is how leads get talked into unsustainable ownership.

"A leading indicator is just an early metric." It has to be predictive, which requires evidence that it moved before the outcome moved in the past. A metric that is merely earlier is just noise you receive sooner.

Interview delivery note

The sentence with the highest return on this page, because it reframes almost any delivery question: "Before we talk about capacity, I want to know where the time actually goes, because in most teams I have seen, most of cycle time is queueing rather than work, and those have completely different fixes." It is true, it is checkable, and it moves the conversation from a resource negotiation to a diagnosis, which is the ground you want to be on.

The senior-to-lead separator across this vocabulary is whether you name the cost that lands on someone else. A senior engineer optimises their team's throughput. A lead says "this decision reduces our coordination tax and increases the platform team's operational tax, so we should check with them before committing", and that sentence is the whole job in miniature: seeing the system past your own boundary, pricing the effect, and routing the decision to the people who should make it.

The Staff & Team Lead Interview Reference