Scale an Engineering Team from 5 to 20

Proof required

Share the risk document, at least 500 words. For each of five bottlenecks, give the current state and the fix. Say what breaks at double size. Share anonymised interview notes with at least one direct quote per person. Write 200 words on the bottleneck that surprised you most.

What gets checked

• Bottlenecks are specific. 'I sign off all API design and block two squads' is specific.
• Each person has at least one direct quote. Paraphrases don't count.
• Each fix is a system, not an event. An ADR process beats 'improve communication'.

Common mistakes

• Skipping the interviews. Managers miss their own bottlenecks because they're inside them.
• Ranking by ease of fixing, not severity. The hardest one is usually the most important.

Resources

Arena

What a verifier looks for

• Could each bottleneck brief a new hire? 'Process needs work' can't; a named failure can.
• Ask them to read one quote that surprised them. No surprising quote means they ran a survey.
• Ask which bottleneck is their own fault. A good audit names one.
• Check each fix is a system. A fix that needs the manager ongoing isn't a fix.

You'll sign in first, then come straight back here.

Proof required

Share the design document with diagrams, at least 600 words. Include the org chart by role and what each sub-team owns. Show how they decide together and how often they meet. Share anonymised notes with at least three concerns the team raised. Write 200 words on how you'll resolve the most serious one.

What gets checked

• The org chart shows roles, not names. It must work for people who haven't joined yet.
• Each sub-team owns named systems or domains. Overlaps are named, with a way to resolve them.
• The three concerns are specific, like shared infrastructure falling between two sub-teams.

Common mistakes

• Designing around current people, not current systems. It breaks when anyone leaves.
• Finalising without showing the team. Their known concerns become your future incidents.

Resources

What a verifier looks for

• Can you tell what each sub-team owns from the document alone? If not, there are gaps.
• Ask who owns the deployment pipeline. 'Shared' with no process means nobody.
• Ask what happened in the room when the biggest concern came up.
• Ask what they'd do if a new VP wanted a different structure in six months.

You'll sign in first, then come straight back here.

Proof required

Share the anonymised hiring log, Candidate A onwards. Show every final-round candidate, the decision and a one-sentence reason. For the five offers, show the deciding factor. Write 250 words on whether your idea of a strong candidate drifted, and when.

What gets checked

• The log covers every final-round candidate, not just the hires.
• Each reason is specific, like 'strong design, couldn't explain debugging trade-offs'. Not 'not the right fit'.
• The reflection is honest. If time pressure lowered the bar, call it drift.

Common mistakes

• Hiring for 'culture fit' without defining it. Write the reason before the offer goes out.
• Letting urgency lower the bar. The fifth hire is the riskiest; address it in the reflection.

Resources

What a verifier looks for

• Count final-round candidates who didn't get offers. Zero means the log is incomplete.
• Could someone else apply each reason? 'Not quite right' can't be replicated.
• Ask what they'd change if they ran it again tomorrow.
• Ask whether hire five was as strong as hire one. The honest answer tells you most.

You'll sign in first, then come straight back here.

Proof required

Share your decision table: decision type, who decides, and the fallback if they're away too. Share your return notes. List decisions made and by whom, and decisions delayed and why. Add any incidents with how long they took. Write 200 words on your delegation score and what the delays show.

What gets checked

• Two weeks in a row. Most gaps appear in week two.
• At least ten decision types, named, like 'approve a vendor contract under $X'.
• Every delayed decision has a reason. Uncertainty about authority is a gap in the table.

Common mistakes

• Checking in while away. One message tells the team you're still available.
• Delegating everything vaguely. Each decision type needs a named person or role.

Resources

What a verifier looks for

• Confirm two weeks in a row. Evidence can be an out-of-office, a status or a teammate.
• Count decision types. Under ten is too coarse. Ask who merges a breaking change at 5pm Friday.
• For each delay, ask why it waited. It should point to a gap in the table.
• Ask what they'd change before the next absence. 'It worked fine' is a warning sign.

You'll sign in first, then come straight back here.

Proof required

Write a 500–700 word retrospective. Cover the goal and success criteria, and what each sub-team owned. Cover the three biggest cross-team blockers and how they were solved. List each time you got pulled in and the fix you made. Say whether you hit the criteria. A sub-team lead must verify this proof on Powstik.

What gets checked

• Each pull-in names the fix that followed. Example: a data contract both teams now sign.
• A sub-team lead verifies it on Powstik before you submit. Your own account isn't enough.
• Success criteria were set at the start, as the retrospective's opening shows.

Common mistakes

• Calling a one-team project cross-team. Answering questions for another team doesn't count.
• Writing the pull-in log at the end from memory. Write it as it happens.

Resources

What a verifier looks for

• Does each pull-in have a fix? Without fixes, it's a list of times they managed.
• Ask the verifying lead whether the manager stayed out of execution. It should match the log.
• Were the criteria measurable? 'p95 under 200ms for 30 days' is measurable; 'ship it' isn't.
• Ask what they'd change next time. 'Communicate better' isn't an answer.

You'll sign in first, then come straight back here.