Engineering Leadership curriculum

The change is in what gets counted, and it is disorienting because the old measure was legible and immediate. A week where you wrote nothing and unblocked four people was a good week. The failure mode is reaching back for personal throughput when you feel unproductive — which is precisely when the team most needs the time you would be spending on it.

The two roles cost time differently. A manager's day is already a grid of slots, so one more costs an hour. A maker's day is a few long blocks, and a meeting dropped in the middle destroys both halves around it. Cluster meetings at the edges of the day rather than spreading them evenly, which feels fair and is the most expensive arrangement.

The relationship has changed whether or not anyone says so, and the silence is read as either denial or a warning. One short explicit conversation — what is different now, what is not, and what you will do when the two conflict — costs ten minutes and prevents months of people guessing. Skipping it is the common choice and the expensive one.

Taking the hardest task is the most tempting mistake because it is genuinely the fastest way to ship that one thing. What it costs is compounding: the work no longer routes around you, the person who would have grown into it did not, and your own attention is now inside a task instead of across the team. Take the second-hardest task, or none.

DORA's five dimensions are worth knowing individually because leaders are rarely weak at all of them — the usual pattern is strength in vision and communication with a gap in intellectual stimulation or recognition. Naming the five turns a vague sense that something is missing into a specific thing to practice.

This is the finding that stops leadership being a story about personality. The measured path runs through what leaders make possible — the technical and process capabilities a team can actually use — so a leader with vision and no investment in those capabilities moves nothing. It also means the work is unglamorous and delegable.

Handing over the destination and the constraints leaves the route to the person doing it, which is where the learning and most of the ownership live. Prescribing the path leaves them accountable for a plan that was never theirs. If you cannot state the constraints, that is the thing to work out before delegating, not a reason to specify steps.

Treating delegation as binary is what makes it feel risky. Naming the level converts it into a dial you can set per task and move over time: report back, recommend, or decide. Most disappointment on both sides is a level that was never stated, so each party assumed a different one.

Seniority is the wrong input — a strong engineer meeting their first incident command or their first vendor negotiation needs direction, and being given none reads as abandonment. Ask what experience this person has with THIS task, then set the level from that, and expect it to differ across tasks in the same week.

It is the cleanest test available, and it can be applied at the end of any conversation. If you are holding the next step, you have not delegated — you have taken a briefing. Say who does what by when before anyone leaves, because both parties usually walk away believing the other one has it.

The instinct to close the last twenty percent is what quietly reverses a delegation: the work comes back, the person learns that their version is not sufficient, and you have bought a small quality gain at the cost of the thing you were building. Correct what is actually wrong, not what is merely different from your way.

Sorting by reversibility rather than by importance is what stops everything escalating. A decision you can undo next week deserves a fast local call and the information the person closest to it already has. Applying a one-way-door process to two-way doors is the commonest way an organization becomes slow while feeling careful.

Ownership sets the content. When the report brings the agenda you hear what is actually on their mind; when you bring it you hear answers to your questions, which is a different and much thinner signal. Keep a list of your own topics and spend it after theirs, or you will reliably crowd them out without noticing.

Status is available in a dozen other places; this slot is the only one that is private and regular. Once it fills with updates the drift is invisible, because the meeting still feels useful. The tell is that nothing uncomfortable has come up for a month — which is not evidence that nothing uncomfortable exists.

The structure exists to stop a coaching conversation collapsing into advice. Establishing the goal and the current reality before options is what keeps you from solving a problem you have misread, and ending on will is what makes it the person's action rather than your instruction. Skipping to options is the default failure.

It samples the experience of being led, which is information you cannot get from the manager. It stops working the moment it becomes a channel for redirecting work: the manager learns their decisions can be routed around, the report learns to escalate past them, and you have broken the thing you were trying to measure.

The finding that surprises people is that contingent rewards can make complex work worse, not merely fail to help — they narrow attention onto the reward. For routine work incentives do fine. Knowing which kind of work is in front of you decides whether a bonus or a better problem is the right lever.

Satisfaction and dissatisfaction are not one scale. Bad pay, tooling and conditions will actively drive people out, and fixing them buys you a neutral baseline rather than motivation. That is why a compensation correction resolves the complaints and changes nothing about engagement, which is usually read as ingratitude.

The structure does its work by forcing specifics. Naming when it happened stops the conversation generalizing into a trait, describing what was observed keeps it checkable, and stating the impact supplies the reason to change. Feedback that skips any of the three is either unanchored, unfalsifiable, or gives no motive to act.

A behavior can be changed tomorrow; a character judgment can only be accepted or fought, and most people fight it. The rewrite is mechanical — describe what you saw rather than what you concluded — and it converts an argument about who someone is into a question about what they will do differently.

Each side owns half and neither can see the other's. You know what the behavior did to you; they know what they meant. Arguing about intent is unwinnable and beside the point, so report the impact and let them supply the intent. The gap between the two is usually the whole finding.

Once someone recognizes the pattern, praise becomes a signal that criticism is coming, so both halves are devalued. The criticism is also the part most easily dismissed, sitting between two reassurances. Give praise when it is earned and criticism when it is needed; pairing them is a comfort for the giver.

Treating them as one dial is the mistake — as if being kinder means being less direct. They are independent, so the aim is high on both at once, and the two named failure modes are what each corner looks like when one axis collapses. Most people know which corner they fall into and cannot see it in the moment.

It is the most common failure precisely because it feels like the virtue. Withholding the hard thing spares an uncomfortable conversation now and costs the person the information they needed to change, which is unkind on any longer horizon. The tell is relief after a 1:1 where you did not say the thing.

Delivering the hard message without the care is often defended as honesty, and it is cheaper than the real thing. It closes the channel: the person defends rather than listens, and the next problem reaches you later. Being right about the content does not make the delivery effective, which is the part that feels unfair.

A review that introduces new criticism tells the person two things — the content, and that you have been sitting on it. The second damages more than the first. It also removes any chance they had to act on it during the period being reviewed, which makes the assessment somewhat your responsibility too.

A softened opening is not received as gentleness, it is received as reassurance, and the person then reinterprets everything after it. State the conclusion, then the evidence, then the path. It is the harder sentence to say and the only one that leaves both of you agreeing afterwards about what was said.

Three causes that look identical from outside and need opposite responses: skill needs training, motivation needs a different conversation entirely, and a system problem needs you to fix the system. Guessing wrong is worse than doing nothing — coaching someone through a blocker they cannot move reads as blaming them for it.

Verbal warnings get remembered differently by each party, and the difference always surfaces at the worst moment. Writing down what must change, by when, and what happens otherwise is protection for the person as much as the company: it is the version they can act on rather than interpret.

Both are legitimate, and running one while pretending it is the other is what destroys trust — the team reads a designed-to-fail plan accurately, and so does the person. Decide honestly which one this is before writing it, and if it is an exit, the humane version is usually to say so.

The cost is not borne by you, which is why it is easy to defer. It is paid by the people absorbing the work, by a standard that quietly drops to what is tolerated, and eventually by your strongest engineers, who have the most options and leave first. The delay is comfortable and never free.

The definition is about risk, not comfort — whether it is safe to admit an error, ask an obvious question or challenge a senior person. Reading it as comfort produces the failure mode of a pleasant team that avoids hard conversation, which is close to the opposite of what the construct measures.

Safety on its own gives a comfortable team that does not improve; standards on their own give anxiety. The learning zone needs both at once, which is why raising the bar and making it safe to fail are the same piece of work rather than a trade-off between them.

The study set out expecting better teams to make fewer mistakes and found they reported more — because reporting was safe. It is the finding worth carrying, because it inverts how an error count reads: a unit with few reports may be the one where nobody dares file them.

It is decided in a moment rather than by policy. The first time someone brings the senior person a problem, everyone watching learns what happens next — and one visibly irritated response teaches the room to route around you. The reaction has to be genuine, because the performed version is legible.

The three types are distinguished by what happens to information. Pathological cultures punish the messenger, bureaucratic ones route it into process, generative ones actively seek it because the mission needs it. The useful question is not which type you are but what happened to the last piece of bad news.

It matters because it moves culture out of the soft column: it is measured with a short instrument and predicts delivery and organizational outcomes. That makes it something to invest in deliberately and to track, rather than a by-product people hope emerges from good intentions.

The value is in recognizing storming for what it is. A team arguing about direction and roles is doing necessary work, and a lead who reads it as dysfunction and suppresses it produces a team that is quiet and never norms. The stages also repeat whenever membership changes, which is more often than people plan for.

The order is the argument: each layer rests on the one below, so a team avoiding accountability usually has a commitment problem, which usually has a conflict problem, which rests on trust. Working on the visible top layer while the base is missing is why accountability initiatives so often achieve nothing.

Being heard is not the same as getting your way, and it is what makes disagreement survivable. Someone who argued and lost can commit; someone who was never asked cannot, because they have nothing to have changed their mind from. This is why announcing a decision costs more later than debating it would have.

It is a two-part bargain and both halves are load-bearing. Dissent has to be genuinely wanted beforehand, or commitment afterwards is just compliance. The failure mode is relitigation — reopening the decision in side channels — which is worth naming out loud as the thing that is not allowed, because it is rarely deliberate.

Effort per person falls as the group grows, and the mechanism is that individual contribution stops being visible rather than that people become lazy. It is why a large meeting produces less than a small one, and why keeping ownership nameable matters more than headcount when a team is growing.

The unstructured interview performs poorly and feels excellent, which is why it survives. Asking every candidate the same questions and scoring against an anchored rubric is what makes two candidates comparable at all — without it you are mostly measuring how easy the conversation was, which correlates with similarity to you.

Sampling the actual work is the strongest common signal, and it is also the fairest, because it measures the thing rather than a proxy. Brainteasers and pedigree predict weakly and are attractive because they are quick. If your process cannot show a candidate doing the job, that is the gap worth closing first.

Submitting written scores before the debrief costs nothing and preserves the panel's independence. Without it the first confident voice anchors the room and you have collected one opinion with corroboration. The effect is strongest exactly where you least want it — when the senior interviewer speaks first.

"Fit" is undefined in practice, so it fills with similarity, and the result is a team that agrees quickly and misses the same things. Replacing it means stating the values you actually require and asking what perspective this team is missing — both of which are harder and are the point.

The hiring manager has an urgent seat to fill, which is a real and legitimate pressure that reliably lowers the bar. An interviewer with no stake in this particular hire is a structural correction rather than a judgment about anyone's integrity. It only works if their no is genuinely binding.

An unresolved substantive doubt is information, not squeamishness. The asymmetry is what settles it: a missed hire costs a vacancy and another search, while a mis-hire costs months of a team's time, a performance process, and often someone else's departure. The cost of waiting is visible and the smaller one.

Different signals for different bets. For a junior, rate of learning predicts where they will be in a year, and current knowledge mostly reflects their last job. For a senior you are buying demonstrated depth now. Interviewing a junior for depth screens for luckier previous employment.

It is a ramp signal precisely because it is small: getting something trivial to production exercises access, environment, review, deploy and the courage to press the button. A new hire who has not shipped in a month is usually blocked on something nobody has noticed, not ramping slowly.

Two describe throughput and two describe stability, which is what makes the set hard to game and why they are always read together. Each has a precise definition that matters — most disagreement about DORA numbers turns out to be two teams measuring different things and comparing the results.

The intuition that speed costs stability is strong and the data does not support it: the same organizations lead on both. That reframes a slow, careful process as a symptom rather than a safeguard — large batches make change risky, and the cure for the risk is smaller changes, not fewer.

The window is deliberately narrow: commit to running in production. It excludes discovery and prioritization, which vary by organization and would swamp the signal. Measuring from idea instead is a reasonable thing to want and a different metric, and mixing the two makes comparison meaningless.

Nobody cares about deploy count for its own sake. Batch size is what actually drives risk and cycle time, and it is hard to measure directly, so frequency stands in for it — deploying more often means each deploy carries less. That is also why raising the number without shrinking batches achieves nothing.

It is a property of deployments, not of tickets: the share of changes that degrade service and need remediation. Counting bug reports instead measures something real and different, and produces a number that cannot be compared with anyone else's or with your own after a process change.

Failure in a complex system is certain, so the question is how long it lasts. Optimizing for never failing produces heavyweight change processes, longer lead times and — because changes get bigger — worse outages when they come. Investing in fast recovery is the counterintuitive move that improves both.

They describe a delivery system: its tooling, architecture, approval process and team structure. Attributing them to an individual is a category error, and it is the fastest way to make the metrics useless, because people optimize what they are judged on and the system stops being visible.

Any one key bends easily — deploy trivially to raise frequency, stop deploying to protect failure rate. The set resists because throughput and stability pull against each other, so moving one dishonestly shows up in another. It resists gaming; it does not prevent it, and it never replaces looking.

Every property improves at once, which is unusual: a reviewer can actually hold the change in their head, verification is quicker, and if it goes wrong the revert is obvious and safe. The resistance is that batching feels efficient — one review, one deploy — and that efficiency is paid for in risk you meet later.

The relationship is not linear. Holding more in flight raises defect rate and rework, and each of those feeds back into elapsed time, so doubling what is in progress can more than double how long it takes. It is the reason a team that feels busier is often shipping less.

Wait time rises steeply as a system approaches full load, which is why a team booked to capacity delivers unpredictably rather than maximally. Planning for full utilization feels responsible and removes the slack that absorbs variation; the queue then appears as missed dates nobody can attribute.

A limit on work in progress feels like doing less and finishes more, because items stop aging in parallel. It also makes blockers visible immediately — when you cannot start something new, the stuck item has to be dealt with rather than quietly worked around.

Sequencing by value lost per week of waiting is what makes the order defensible. The alternatives — biggest first, smallest first, whoever asked most recently — all optimize something other than outcome, and the last one is what most backlogs actually do while appearing prioritized.

They are different objects: an estimate is a range with uncertainty, a commitment is a promise with consequences. Treating an estimate as a promise manufactures failure — the range was honest and the promise was not — and it teaches engineers to pad, which destroys the estimate as information.

Early estimates are uncertain by multiples, and the range narrows only as the work is actually done, not as the deadline approaches. That means pressing for precision early does not produce precision, it produces confidence. The honest early answer is a range wide enough to be uncomfortable.

The moment the date moves in your head is the moment it is worth the most to say, because that is when there is still room to act. Waiting for certainty converts a manageable adjustment into a surprise, and the surprise is what damages credibility — not the slip.

Dates rarely move, and quality only appears to move — it returns later as rework and incidents. That leaves scope as the honest lever, which means the useful conversation is which parts are cut rather than whether the date holds. Naming that early makes it a decision rather than a discovery.

Two costs land at once: existing people stop working to ramp the new ones, and communication paths grow faster than headcount. Both are worst exactly when a project is late and pressure is highest. It is not an argument against ever adding people, only against adding them as a schedule remedy.

The law bites hardest where work cannot be split, and stating that boundary is what keeps it from becoming a slogan. Genuinely partitionable work — independent services, separate test surfaces — absorbs people better. Knowing which kind you have is the question, and the answer is usually less partitionable than hoped.

Deciding, discussing and informing need different preparation, different attendees and different endings. A meeting with no stated type defaults to status, because status is what fills any unstructured slot. Putting the type in the invitation costs one word and changes what people bring.

Without a named decider a discussion produces either consensus theater or nothing, and the ambiguity is usually only noticed afterwards when the decision fails to stick. Naming them does not make it undemocratic — it makes clear whose judgment the input is feeding.

An hour with eight people is a day of engineering. Invitations are issued as though the cost were the room, and the cure is the smallest group that can reach the outcome plus notes for everyone else. Inviting people to be informed is the commonest and most expensive habit.

Attention flows to whatever everyone feels qualified to have an opinion about, which is reliably the least consequential item. The tell is a long, energetic debate on something small immediately after a large decision passed quietly. Naming it in the moment is usually enough to move on.

Imagining the project has already failed and asking why surfaces risks that a status review never does, because it gives permission to voice doubt without sounding negative. It is cheap, it takes half an hour, and it works best before commitment rather than after the first slip.

An open floor collects the view of whoever is most comfortable speaking, which is not the same as the best view. Written rounds and explicit turns surface the quiet read — and the quiet read is disproportionately the one holding the objection nobody else wanted to raise.

The value is the reasoning, not the verdict: what the context was, what else was considered, and what the decision costs. A year later the decision alone is unfalsifiable, while the context tells you whether it still holds. Most ADRs are thin because the options section is skipped.

The test is differentiation, not capability. Anything a competitor could buy off the shelf and reach parity on is not where your engineering should go, however satisfying it is to build. The usual error is building infrastructure that is genuinely interesting and entirely undifferentiating.

Framed as code quality it reads as engineers wanting nicer code and loses every prioritization conversation. Framed as weeks of delivery lost per quarter and incident risk carried, it becomes comparable with the features it competes against — which is the only form in which it gets funded.

A rewrite discards the accumulated bug fixes that make the old system actually work, and those were never written down. It also delivers nothing until it is finished, so it is the option with no feedback and no early exit, which is why the estimate is always the one that slips.

Routing traffic incrementally makes each step small, observable and reversible, and it means value arrives throughout rather than at the end. The cost is running both systems for a while, which is real and is the price of not betting the quarter on a single cutover.

Skip the scheduled deletion and both systems run forever — twice the surface, twice the on-call, and every new feature written in two places. Fixing that date is what turns the work from an addition into a replacement, and it belongs in the plan from the start rather than bolted on at the end.

DORA's finding is uncomfortable because the board exists to reduce risk: it lengthens lead time without improving stability. The mechanism is that reviewers distant from the change cannot assess it, so approval becomes ceremony. Peer review and automated checks are what actually move the numbers.

A system ends up shaped like the communication structure that produced it, which means an architecture diagram that ignores the org chart is a wish. It also explains integrations that are awkward in exactly the places two teams rarely talk — the seam is organizational before it is technical.

If structure follows communication, then changing the teams is a lever on the architecture — arguably the strongest one. It is slower and more disruptive than a design document, and it is the move that actually holds, because the alternative is fighting the org chart in code indefinitely.

Of everything DORA measures architecturally, this is the strongest predictor: can a team test and deploy on its own schedule without depending on another team. It is a question about coordination cost rather than about technology, and a microservice architecture that still requires a joint release fails it.

Four types with different purposes: stream-aligned teams own a flow of work end to end, platform teams reduce cognitive load for them, enabling teams teach and leave, complicated-subsystem teams hold genuine specialist depth. Most organizations have all four informally and manage them as one kind.

Three modes, and collaboration is deliberately time-boxed because it is expensive — high bandwidth, high cost, appropriate for discovering an interface rather than living in. X-as-a-service is the steady state; facilitating is temporary by design. Permanent collaboration between two teams usually means the boundary is wrong.

A team can own what it can hold in its head, and that ceiling does not rise because headcount did. Adding a fifth service to a team already at its limit degrades all five. The boundary is a property of the domain's complexity, which is why the fix is usually platform support rather than people.

Both directions cost something, which is what makes it a trade rather than a best practice. Few reports each gets real attention and the organization grows layers; many reports and support thins to exception handling. The right number depends on how much support the work actually needs.

The dip is real and reliably left out of the business case: relationships reset, context is lost, and people spend weeks working out who owns what. That does not make reorgs wrong — it makes the honest comparison the benefit minus a quarter, which some reorgs survive and many do not.

One person owns coordination and decisions, and the role only works if they are not also debugging — the moment they are in a terminal, nobody is running the incident. It is a role rather than a rank, and the most senior person in the channel is often the wrong choice for it.

Splitting command, operations and communications keeps the person fixing the problem from being the person answering questions about it. Merging them is the default under pressure and it is what makes long incidents longer: every executive update interrupts the debugging it is asking about.

The asymmetry decides it. A false alarm costs a few people a few minutes; a late declaration costs the time nobody was coordinating. Teams under-declare because declaring feels like an admission, so it is worth saying explicitly that escalating early is the behavior you want to see.

One timestamped document that everyone updates is what makes handover possible at all, and it is the only source the postmortem will have for what was known when. Reconstructing a timeline from chat afterwards loses exactly the thing you need: the order in which people learned things.

Restoring service and understanding the cause are different activities, and doing them in the wrong order extends the outage for curiosity's sake. The discipline is hard because the cause often feels within reach. Roll back, restore, then investigate with the pressure off and better data.

Rolling back is the known-good state, and a forward fix written under pressure is the least reviewed code you will ship that week. Make rollback the default and require a reason to do otherwise — the exceptions are real (irreversible migrations) and rarer than they feel at 2am.

Every question directed at the person typing costs more than it looks, because it interrupts the only work that is shortening the outage. Routing executives to the comms lead is a real part of the commander's job, and doing it firmly is usually appreciated afterwards.

The question is what made the mistake easy to make: what the interface allowed, what the alert did not say, what the runbook omitted. That is not absolution — it is where the fixes are. A person can be careful tomorrow; a system that permits the error will produce it again.

Naming human error ends the investigation at exactly the point it should begin, because it answers who and skips why it was possible. Every time it appears as a root cause, there is an unasked question about the system that let one person's slip reach production.

Afterwards the signal is obvious, because you know which of the hundred signals mattered. Judging the decision on what was knowable at the time is a deliberate correction against that, and it is hard to hold — which is why writing what was on the screen at each point is worth the effort.

An unowned follow-up is a sentence, and a postmortem full of them makes the document the deliverable instead of the fix. Each item needs a name and a date, and fewer real items beat a comprehensive list nobody is accountable for.

Deciding beforehand which events get a postmortem keeps the choice from becoming a judgment about whose incident was serious enough. Agreed criteria also mean nobody has to argue for one while still tired, which is when the argument is least likely to be won.

A five-whys line produces one tidy story, and complex failures do not have one — they have several conditions that all had to hold at once. Stopping at the first chain hides the other conditions, each of which is also a place the failure could have been prevented.

Whether a rotation is sustainable is arithmetic, not attitude: too few people and someone is paged while already exhausted, which is when mistakes happen and when people start leaving. Treating it as a staffing number makes it a decision someone owns, rather than a burden that quietly redistributes.

A page nobody can act on trains people to ignore pages, and that training generalizes to the ones that matter. Deleting a noisy alert feels like reducing coverage and is usually the opposite. If the alert is genuinely important and not actionable, the missing thing is a runbook.

Setting an objective below 100% turns reliability into a quantity you can spend, which is what makes the conversation between shipping and stability concrete instead of ideological. The budget is the permission to take risk; without one, every outage is an argument and every change is suspect.

What happens when the budget is exhausted has to be decided while nobody is spending it, because afterwards the decision is about a specific team's specific feature. Agreeing it in advance is what makes it a policy rather than a negotiation you lose under pressure.

Four properties together: manual, repetitive, automatable, and scaling with the service. The last one is the sharp edge — work that grows as you grow will eventually consume the team, while genuinely one-off manual work is just work. Measuring toil is what makes the case to remove it.

Capping the share of time spent on operations protects the engineering time that would eliminate it. Without a cap, load rises to fill the capacity and the automation is permanently next quarter. The cap has to be enforced by someone with the authority to push work back.

A service only one person can rescue is a single point of failure that takes holidays, and celebrating the rescue entrenches it. The remedy is unglamorous: documentation, shared on-call, and deliberately routing the next incident to someone else while the expert stays quiet.

A project that is green until it is suddenly red was never green — the status was a summary of intent rather than of state. The problem to fix is the reporting: amber has to be survivable, or people will keep choosing green until the evidence is undeniable.

Escalating a problem alone transfers work upward and invites a decision made with less context than you have. Bringing two or three options and the one you would take keeps the judgment where the information is, and makes the escalation a decision rather than a request for rescue.

Stakeholders decide in dates, risk and money; the architecture is the reasoning that produced your answer, not the answer itself. Presenting the reasoning asks them to do your job. Lead with what it means for the things they own, and keep the technical case ready for the follow-up question.

Escalating jointly with the peer lead gets the blocker moved and leaves the relationship intact; escalating around them gets the same decision and costs the working relationship you still need next quarter. The joint version is slower by one conversation and is almost always worth it.

A dashboard anyone can read at any time beats a report only you can produce, because it removes you from the loop and removes the temptation to shade the summary. It also changes the meeting: people arrive having seen the state rather than hearing it for the first time.

A flat refusal invites escalation and a silent yes creates a debt someone else discovers. Naming what would have to move — which date, which scope, which other commitment — turns it into their decision with real information, and it is the form of no that gets accepted.

A ladder is about the scope and ambiguity a person handles, not time served — which is why a strong engineer can stay at one level for years without anything being wrong. Ladders written in terms of tenure or output quietly promote for patience and produce levels that mean nothing.

Promotion confirms someone is already operating at the level rather than betting they will grow into it. Promoting on potential is generous, common, and sets the person up to be under water in public. The kind version is to give the scope first, then recognize it.

Managers apply the same words differently, and without calibration a rating says as much about the manager as the engineer. Comparing across managers is what makes exceeds mean one thing — and it is also where systematic generosity or harshness becomes visible to the people doing it.

Four distinct jobs under one title: leading a team technically, holding architecture across many, going deep on the hardest problem, or operating as a leader's right hand. Expecting one person to be all four is the commonest source of an unwritable staff role and an unhappy staff engineer.

Advice is cheap and given freely; sponsorship spends the sponsor's own credibility in rooms the person is not in. That asymmetry is why mentorship is distributed widely and sponsorship narrowly, and why who gets sponsored is worth auditing rather than trusting to instinct.

The coordination, onboarding and unblocking that makes a team function is often invisible at promotion time and unevenly assigned — disproportionately to women and to the people most willing. Both halves need attention: count it when it is done, and distribute it deliberately rather than letting it settle.

Once a measure becomes a target, behavior adapts to the measure rather than the thing it stood for, and the correlation that made it useful is exactly what breaks. It is not an argument against measuring — it is an argument against tying consequences to any single number.

Commits, lines and points count activity, are trivially inflated, and say nothing about whether the right thing was built. They also ignore the system, which is where most of the variance actually is. The predictable outcome of reporting them is more of the measured activity and less of the work.

Features shipped is output and is fully under engineering's control, which is why it gets reported. The outcome is what changed for a user or the business, and it is the thing the work was for. A team optimizing output can ship steadily while nothing improves.

Five dimensions, and the instruction is to never report one alone — activity without satisfaction hides burnout, performance without communication hides a team carrying the load. The framework's value is the requirement to look at several at once, which is what stops any one becoming a target.

The original variance studies compared people working in different environments with different tooling and problems, so environment and person were confounded. The finding that survives is that variance is large; the per-person multiplier does not follow from it, and it is quoted as though it does.

A decision made on a call exists only for the people on it, and everyone else meets it later as an unexplained fact. Writing it down is what makes it reviewable, searchable and survivable when people leave — and the cost is a few minutes while the reasoning is still fresh.

DORA's finding is that good internal documentation multiplies the effect of every other capability rather than adding to it. That reframes documentation from hygiene to leverage, and it means a team with weak docs gets less from every other investment it makes.

With one person remote the room becomes the meeting and they become an audience — side conversation, whiteboard, and the half-sentence that changed the decision all happen without them. Either everyone dials in individually or the asymmetry is accepted; there is no version where it is fine.

Past a few overlapping hours, the process has to change — more written decisions, fewer synchronous dependencies, explicit handover. Teams usually try to keep the old process and absorb the gap by working late, which works for a while and is paid back in attrition.

Visibility gets mistaken for contribution, and the bias shows up in ratings written by people who genuinely believe they are being fair. The correction is structural: judge against written evidence of outcomes rather than impressions, and check whether the remote half of the team is rated differently.