Lesson 0048 · Initiative Lead · Module 3
Run a Small Cross-Functional Initiative Team
A 6–8 person team moves quickly when ownership is shared and decisions are explicit—not when eight specialists each maximize their own queue.
Mission tie-in: team structure is part of system design. The communication paths, decision rights, and ownership model become boundaries and coupling in the software.
Knowledge: one team, distinct accountabilities
A useful initiative cell might be a product manager, product designer, tech lead, and four or five engineers. Testing, data, security, operations, content, and domain experts may be embedded or consulted. Titles vary; the accountabilities must not vanish:
| Accountability | Owns the final call on | Must seek advice from |
|---|---|---|
| Product | outcome, priority, cohort, scope trade | design, tech lead, data, domain, commercial |
| Design | experience coherence, interaction, research method | users, product, engineering, accessibility |
| Tech lead | technical integrity, risk, architecture decisions | engineers, product, design, security, operations |
| Engineers | implementation decisions within agreed boundaries | peers and affected owners |
| Whole team | delivery forecast, quality bar, ways of working | stakeholders carrying consequences |
This is not three lanes handing work to one another. Product, design, and engineering discover together; design works close enough ahead to clarify the next slice, not a quarter ahead producing an inventory of stale screens. Engineers join research and mapping. Product and design join failure, scope, and rollout decisions. The tech lead makes technical work legible in outcome and risk language.
Named decision rights cut cycle time by changing the shape of the dependency graph. A decision with no owner defaults to whoever is most persistent or most senior, and the time to decide becomes a function of calendar availability rather than of information. Naming the decider converts a negotiation into a consultation: advice can be gathered in parallel, asynchronously, from people who never have to be in a room together, whereas consensus must be gathered serially and synchronously. That is the entire mechanism—a join becomes a fan-out. It is also why “who decides” is a kindness rather than a power grab: without it, the quiet expert's advice is worth less than the loud one's.
Low WIP works on arithmetic. Cycle time equals work in progress divided by throughput, so with five items in flight everything finishes roughly five times more slowly than with one. Feedback arrives per finished item, so a team running high WIP is buying less learning per week while feeling maximally busy. This is counterintuitive on purpose: idle people look expensive and idle work is invisible, which is why utilization wins arguments it should lose.
Both fail in identifiable conditions. Decision rights fail when the named decider lacks either the information or the authority to absorb the consequence—then you have named a scapegoat, and people learn to route around the table. WIP limits fail when the items are genuinely independent and blocked externally: six things each waiting on a different vendor are not a flow problem, and capping the board will not make the vendors answer. Fix the dependency map instead.
Optimize for flow, not utilization. Keep one or two slices in progress, swarm when one is blocked, and finish the end-to-end path before starting another. Assign a directly responsible individual (DRI) to move a workstream or decision—not to do all its work or own the code forever. Rotate module work with pairing and review so ownership stays collective and knowledge has redundancy.
| Cadence | Purpose | Artifact changed |
|---|---|---|
| daily, 10 min | flow, blockers, swarming—not status recitation | work board and dependency map |
| twice weekly, 30 min | shape next slice with examples and design | story map and examples |
| weekly, 30 min | review outcome evidence, risks, decisions, forecast | initiative review |
| weekly, 45 min | demo integrated behavior to users or stakeholders | feedback and decision log |
| as needed, timeboxed | resolve one design decision with required advisers | ADR or explicit no-decision |
| fortnightly, 45 min | improve team system and technical health | one owned experiment |
Use one visible source for each fact: initiative frame for why, story map for scope, delivery board for current flow, ADR log for decisions, risk/dependency map for uncertainty, dashboards for evidence. Do not reproduce the same status in slides, tickets, chat, and documents; duplication creates conflicting truth.
Escalate by trigger, not emotion. Examples: external dependency misses its needed-by date; a driver cannot be met inside the agreed scope; a decision crosses another team's ownership; forecast confidence falls below the agreed range. Escalation asks for a decision or resource, states options and consequences, and names the date. “Leadership awareness” is not an outcome.
How the lead actually intervened
Week 8. Five items in flight across four engineers, and every one of them is “nearly done”. The lead does not look at the count—counts always look reasonable. She looks at the age of the oldest item, which is where a board hides its real state. The accessibility fix for the refusal screen is nine days old. It is not blocked on engineering; it is waiting on a decision about how much of the policy reason to show, and nobody owns that decision.
The obvious intervention is a daily blocker-escalation meeting. She rejects it, and the reasoning is worth stealing: the problem is caused by a serial synchronization point, so adding another serial synchronization point to fix it makes the system worse in the same direction. Instead: publish the decision-rights table, cap work in progress at two slices, and add one default—any decision without an owner after twenty-four hours goes to the tech lead, who may hand it back with a name on it.
Ines, the designer, dissents immediately and correctly. A default of “the tech lead decides” will, over a quarter, erode experience coherence—the decisions that fall through are disproportionately the ones about how something feels. The lead does not dismiss it; she changes the table. Experience coherence is Ines's call, with the tech lead as a required adviser rather than a decider, and the twenty-four-hour default routes to whoever owns the category rather than always to engineering. The dissent improved the design of the team, which is what dissent is for.
Over the next four weeks, median slice age fell from nine days to four. What did not change is instructive: the team did not make more decisions per week. It made the same number, with far fewer of them waiting. That is the shape of most flow problems—not capacity, but queueing—and it is why adding a person in week eight would have made it worse.
| Signal | System problem | Intervention |
|---|---|---|
| eight items, each “90%” | Utilization outranks finishing. | Cap WIP; swarm one slice. |
| design handoff every Monday | Discovery and delivery are detached. | Shape examples together continuously. |
| tech lead approves every PR | Authority is a throughput bottleneck. | Publish guardrails; distribute review. |
| same blocker for three days | No owner or escalation trigger. | Name DRI, fallback, deadline. |
- Decision rights mean the tech lead decides technical things alone.
- The table says who closes a decision, not who thinks about it. Advice is mandatory, and a decider whose mind is never changed by advice has a consultation problem that the table will not fix.
- Low WIP means people will sit idle.
- Sometimes, briefly—and that is the cheap resource. Idle work is the expensive one: it ages, it goes stale, it hides risk, and it delays every piece of feedback behind it. Optimizing for busy people guarantees queues.
- Swarming is inefficient because of the coordination overhead.
- The overhead is real and it is being bought deliberately: you pay coordination cost to shorten the feedback loop on the one item that is blocking evidence. It is a bad default and an excellent intervention.
- A DRI owns the code.
- A DRI moves one outcome to a close. If that becomes permanent ownership of a module, you have manufactured a bus factor and removed the reason to rotate and pair.
When this is the wrong move
A formal decision-rights table is bureaucracy for three people who share a desk and can settle anything in a sentence; write it when the team grows, when someone joins, or the first time a decision goes unowned for a week—not before. The full cadence is waste for an initiative with one or two people, where the daily and the shaping session are the same conversation. Objective escalation triggers add nothing when the sponsor attends the standup. And the deepest counter-case: if the team's real problem is that the outcome is unclear, none of this machinery helps. It will produce a beautifully governed team delivering the wrong thing on time.
Skill: choose the team intervention
Four engineers each start a separate item. The lead should:
A DRI is responsible for:
Product and design should work:
Practice: design the team operating system
For a 6–8 person initiative, write decision rights for product, experience, architecture, implementation, quality, and rollout. Set a WIP limit. Name the six canonical artifacts and their owners. Define a one-week cadence and three objective escalation triggers. Delete any ceremony with no decision or artifact to change.
In the lab and the capstone. The lab's phase-4 checkpoint is deliberately larger than one sitting, so it is where a WIP limit and a named decider stop being theory: decide up front which decisions you will record and which you will simply make. The worked artifact is the team charter in the strong capstone packet, where each accountability names both the call it owns and the advice it must seek. Compare with the weak version: a list of roles, a full meeting calendar, and no statement anywhere of who decides when two of those roles disagree.
Reveal: the meeting test
Every recurring meeting should have an input people can inspect, a decision or learning purpose, a changed source of truth, and a shorter asynchronous alternative for weeks when no decision is needed. If its output is “everyone is informed,” a concise written update may be the deeper module.
- In two sentences, explain to a new lead why naming one decider makes a team more collaborative rather than less.
- Look at your team's board today. Find the oldest item, name what it is waiting for, and name who owns that decision—if nobody does, you have found this week's intervention.
- Predict the failure: if a team runs at maximum utilization for a quarter, what happens to the age of its oldest work item, and what will the retrospective blame instead?
Your win
You can establish clear decision rights, collaborative product-design-engineering work, low WIP, useful cadence, resilient ownership, and escalation before pressure improvises them.
Read and watch deeper
- Team Topologies, Skelton & Pais — stream-aligned teams, cognitive load, team APIs, and deliberate interaction modes.
- Accelerate, Forsgren, Humble & Kim — ch. 4, 7, and 8: continuous delivery practices, lean management, and lean product development.
- The Principles of Product Development Flow, Reinertsen — WIP, queues, batch size, and economic decision-making.
- Reference: Initiative Playbook · team charter and cadence.
Ask your agent-teacher to audit the team's calendar and artifact list for duplicated status, missing decision rights, and meetings without a changed output.