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.
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.
| 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. |
Skill: choose the team intervention
Six engineers each start one 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.
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.
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. 3, 7, and 8: continuous delivery, lean management, and 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.