Engineering leadership, oriented

The DevOps Research and Assessment program measures five leadership dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition. Its 2017 report found teams with the least transformational leaders were half as likely to be high performers — and, in the same data, that leaders in the top tenth still varied widely in delivery performance. Necessary, not sufficient. The validated model is explicitly indirect: leaders affect delivery by enabling teams to adopt technical and lean product management practices.

That turns delegation from a style question into a decision-rights question. The program's team-experimentation capability defines the authority operationally: a team can work on new ideas, and change stories and specifications, without permission from outside the team. Its named failure modes are treating technical staff as order-takers and giving a team specific direction on how to do the work.

So hand over "move billing off the shared database, no customer-visible downtime, by end of quarter" — not a sequenced plan. The plan version is supervision in delegation's clothes: the team cannot revise the specification when it learns something in week two, which is exactly the authority being measured.

The common misread is that the charismatic lead is the cause of a fast team. Charisma with no adopted practice is a well-liked manager of a slow team.

Rule: if you named the steps as well as the outcome, you kept the decision — delegate the definition of done and the constraints instead.

The typology scores six things: cooperation, how messengers are treated, whether responsibility is shirked or shared, whether people bridge between teams, what happens after a failure, and what happens to a new idea. Pathological: messengers punished, failure means scapegoating, novelty crushed. Bureaucratic: messengers neglected, failure handled as justice, novelty causes problems. Generative: messengers trained, failure leads to inquiry, novelty gets implemented. The research program reports that a high-trust generative culture predicts software delivery and organizational performance, and its 2019 report found psychological safety predictive of delivery performance, organizational performance and productivity. The named way organizations destroy it is ignoring or punishing bad news.

Hence the misconception worth killing: safety is not comfort or niceness. A team can be unfailingly pleasant and sit squarely in the bureaucratic column.

Google's site reliability workbook walks a team through forming, storming, norming and performing, and its norming checklist is concrete: reliability objectives and error budgets exist, on-call rotations are established and sustainable, toil is documented and bounded, postmortem culture is established. It also warns against renaming an operations team without first applying the practices — a culture claim with no mechanism.

Rule: judge a culture by what happened to the last person who raised a problem early, and locate a team by which of those artifacts it actually has.

The research program defines job satisfaction in two halves: work that is genuinely challenging and means something, done by someone trusted to use their own skill and judgment. Concretely: people rate meaningful work about as highly as salary; teams that choose their own tools do better at continuous delivery; teams that routinely get improvement time get better at it and are more likely to stay.

Burnout is treated as an environment problem with a specific structure, drawn from Christina Maslach's research: work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, and value conflicts. The line worth memorizing: organizations mostly try to fix the person and ignore the work environment, even though fixing the environment has the higher chance of working — and management can change every one of the six.

So when someone says they are burned out, ask which factor is loaded. Volume? No say over their own work? A promotion round that looked arbitrary? Shipping something they believe is wrong? Time off addresses overload and nothing else, which is why it so often buys three good weeks.

Rule: before you change something about the person, change something about the work — name which of the six factors you are moving.

Change lead time runs from a change being committed to version control to that change running in production — not from idea to launch. Deployment frequency is how many deployments happen in a period, or the time between them. Change fail rate is the share of deployments needing immediate intervention afterwards, not the share of tickets that turn out to be bugs. Failed deployment recovery time is how long recovering from such a deployment takes. A fifth, deployment rework rate, counts deployments that were unplanned and happened because of a production incident.

Speed and stability being correlated rather than opposed is the finding that changes decisions, because it removes "we go slower to be safe" as a defense. The real trade-off is doing both well versus doing both badly.

The published pitfalls are the misuse guide. Setting a metric as a goal ignores Goodhart's law: mandate that every application deploy daily by year end and you get deployments split to hit the count. One metric alone hides the tension the set relies on. Comparing unlike applications misleads, because these measure an application or service — and competing with other teams, rather than with your own past, defeats the point.

That is also why no individual version of any of them exists: each is defined over deployments and services, so a lead time belongs to a delivery path, not a programmer. Velocity and story points counted per head measure activity, and are trivially gamed.

Rule: measure the delivery path, compare it only with its own history, and never let the target replace the thing it was standing in for.

The published sizing test is blunt: anything taking longer than a week is too large, and work is decomposed to be independent, negotiable, valuable, estimable, small (hours to a couple of days) and testable. A second named pitfall is regrouping finished pieces into one release before testing, which throws the feedback away again. The current version of the trap is an assistant-generated pull request of a thousand lines — a batch-size problem in a productivity costume, and the guidance names the review load it creates.

Limits on work in process are the enforcement mechanism. Each stage of the board gets a cap; once it is full, nothing new enters until something leaves, so the team pulls instead of pushing. The named failure modes are setting the caps far too high, and relaxing them the moment someone goes idle. Idle is the signal, not the problem — the guidance is to help elsewhere in the value stream rather than start another card.

When lead times vary wildly, predictions about future work will not be as reliable, whatever technique produced them. Reduce the variability first and the forecast improves without anyone getting better at guessing.

Rule: when estimates keep missing, shrink the batch and cap the work in flight before you re-estimate — variability, not optimism, is usually what broke the forecast.

Taken as a lever rather than a joke, that becomes the inverse maneuver: design team structures so the communication patterns push toward the architecture you intend.

The useful part is that a boundary has an operational test, and it is not the org chart. Can the team make large-scale changes without permission from another team? Complete work with minimal cross-team coordination? Deploy and release independently of the services it depends on? Test on demand without an integrated test environment? Deploy during business hours with negligible downtime? Every no is a dependency the reporting line is hiding.

Size follows from that rather than the reverse. One published example: a large-scale storage service supported by a team of about eight people, because it sits on layers of lower-level services.

The misconception is expensive: reorganizing people to fix delivery when the coupling is in the system. Move the boxes and the queue moves with them. The named pitfalls point the same way — a single team everyone depends on becomes the bottleneck, and releasing many services together turns every deploy into a big bang.

Rule: test a proposed boundary by asking whether that team could deploy on a Tuesday afternoon without asking anyone; if not, you have drawn a reporting line, not a boundary.

The misconception feels like prudence, so state the result carefully: an external approval board slows delivery, and the study found no support for the hypothesis that a more formal external review process goes with a lower change fail rate. The mechanism is batch size again: heavier approval means larger batches released less often, each landing harder on production.

The alternative meets the same requirement. Segregation of duties says someone other than the author must approve a change. Peer review during development, with the review, comments and approval captured in the development platform, satisfies that while staying close to the change. Named pitfalls: relying on a central board to catch errors, treating every change as equally risky, and answering a problem with more process.

For technical debt, maintainability is a set of conditions: code is easy to find and reuse, code another team maintains is easy to change, dependencies are easy to add and upgrade, and they rarely break you. That yields non-aesthetic measures: median lead time for a cross-team change, how current your library versions are, how many versions run in production. Argue debt in those terms outside engineering. And migrate by strangling: route work to the new path incrementally rather than replacing a system in one cutover.

Concretely: a two-line rate-limit change and a schema migration both wait for Thursday's board, which reads neither diff. The guidance warns that people that far removed from a change may not understand its implications, and that treating all changes equally starves the one that needs it. A colleague had approved the two-liner in the pull request that morning, so the requirement was already met.

Rule: put the control as close to the change as you can — reviewed by someone other than the author, in the tool, on the day.

Perfect reliability is not worth buying — a user on a 99% reliable phone cannot tell 99.99% from 99.999%, while the last increment costs enormously in speed and money. So product management sets an objective, monitoring measures what actually happened, and the gap between them is the budget. Above the objective, releases go out; spend the budget and releases pause while effort goes into testing and reliability. The reported behavioral effect is the interesting part: as the budget drains, the developers themselves start pushing for more testing, because they do not want to stall their own launch.

Toil is the second instrument, defined tightly: manual, repetitive, automatable, tactical, of no enduring value, and scaling linearly with the service. Google's published targets: at least half an engineer's time on engineering and no more than a quarter on call, against a measured toil average near a third.

The staffing numbers follow from load, not fairness — and the common mistake is treating on-call as a rota to fill rather than a load to shrink. A round-the-clock rotation with a primary and secondary wants about eight engineers at one site, or six per site across two. The cap is two incidents per twelve-hour shift, because an incident runs about six hours including analysis, remediation and postmortem. Every page must be actionable; hourly low-priority alerts wreck both productivity and the attention a real incident needs.

Rule: decide how many pages a shift may receive, then treat every page above that as a defect to delete or automate — the rota is downstream of the alert volume.

The commander holds high-level state and structures the response, assigning responsibility by need and priority. Operations is the only group modifying the system during an incident. That rule prevents the classic disaster: several capable engineers making uncoordinated changes at once, each invisible to the others, while stakeholders hear nothing.

The commander's most important artifact is a living incident document, kept somewhere that does not depend on the systems being repaired. That sounds obvious until your wiki sits behind the thing that is down. The document is what makes a handover survivable and a postmortem possible.

Declare early. It is better to declare, find a simple fix and close it out than to spin up incident management hours into a growing problem. Useful triggers: you need a second team, the problem is customer-visible, or an hour of analysis has not resolved it.

During the outage, restore service first and preserve the evidence; finding the cause belongs to the postmortem. The trap is handing command to your best debugger. Whoever tracks the whole picture cannot also be head-down in a stack trace.

Concretely, the book's own pair. Unmanaged: 2 p.m. on a Thursday, one datacenter stops serving, then a second, then the third of five. The on-call engineer reverts alone, wakes the author at 3:30 a.m. in her time zone, and two colleagues poke at terminals "just looking". Managed, same alerts: at the second one she asks a colleague to take command. The new commander emails a prearranged list and records each assessment in a live incident document, and the email thread keeps the vice-presidents informed without pulling them in.

Rule: name a commander and open the document first — a declared incident that turns out small costs minutes, and an undeclared one that turns out large costs the outage twice.

A postmortem records an incident, its impact, what was done to mitigate or resolve it, the causes, and the follow-up that stops a recurrence. Blameless means assuming everyone involved acted in good faith on the information they had, and looking for contributing causes rather than someone to indict. The justification is mechanical, not sentimental: people are not the repairable part of the system; the processes and defaults that shaped the decision are. Blame does not remove the failure — it removes the reporting, and issues swept out of sight raise risk.

Decide the trigger criteria before you need them: user-visible degradation beyond a threshold, data loss of any kind, on-call intervention, resolution time over a threshold, a monitoring failure. Agreeing them in advance is what stops the choice becoming political.

The wording test is small and sharp. Compare "why didn't you make sure your team finished the training?" with "should that training be required before anyone joins the rotation?" — same fact, and only the second produces a next action.

Then the part most teams skip: action items get a single owner (collaborators are fine) and a tracking number, because unowned items do not get resolved. "Improve alerting" cannot be verified; "alert when more than a set share of machines is taken out of service" can. Tagging every item at the same priority means nobody can tell what to do first. And resist the single cause — the well-worked examples trace a cascade of conditions that all had to line up.

Rule: agree the trigger criteria before the outage, and judge the document by whether its action items have owners and verifiable end states.

Quality means clarity, findability and reliability, not mere existence. That is the gap between a wiki and a place people actually look, and why a decision recorded only in a call did not happen for anyone absent.

The team-facing half is visual management: put key information where everyone can see it — card walls, pipeline monitors, production telemetry — and use it in daily work, not at review time. The pitfalls: metrics chosen without the team, displays too complex to act on, data left to go stale, and treating the display as the goal instead of a driver of improvement.

That is also the honest way to manage upward. A display anyone can read differs structurally from a status report only you can produce, because it takes you off the critical path of knowing. The guidance says the same of delivery metrics: share them across development, operations and release rather than siloing ownership.

For decisions, the worked mechanism is a standing production meeting. It runs weekly for thirty to sixty minutes, with a chair role many teams rotate. It is compulsory for the team, with major stakeholders and partner teams invited, and follows a fixed agenda pre-populated in a shared document: upcoming changes with timing and expected effect, metrics and resource use, outages, paging and non-paging events, prior action items. When it grows too big, send a representative subset.

Distributed work makes all of this load-bearing. Working across sites costs latency and communication; the stated requirements are clear deliverables, clear deadlines, and an agreed way to make decisions. Writing offsets the distance, though nothing substitutes for occasional in-person time.

Rule: if the only way to learn the state of the work is to ask you, that is the defect — put the state on a display and the decisions in a document.