Part 5: People. How We Develop, Lead, and Support

People practices create organisational capability from the many individual abilities within the organisation. The four preceding parts are inert without them: a structure is only as adaptive as the people who staff it, and a process only as honest as the people who feel safe enough to tell the truth inside it.

Leaders, Not Managers; Coaches, Not Bosses

We think of leadership as coaching: developing people to their fullest potential, not directing their work. Engineering Coaches do not tell teams what to do or how to do it. They seek to develop all people on the team to be the best versions of themselves.

Managers are builders first. They share the full Builder Core with their teams and are expected to maintain fluency in AI Orchestration, Domain Insight, Communication, and Quality Thinking. The management specialisation covers what is unique to leading people through transformation, not a separate track divorced from the work. There is a single Management specialisation regardless of whether the team is engineering-leaning, product-leaning, or mixed.

See Appendix B for a detailed Manager vs Coach comparison.

Comb-Shaped Skills

Rather than narrow specialisation (“front-end developer,” “tester”), we develop comb-shaped skills: deep expertise in key areas and broad competence across the stack. This eliminates single points of failure and enables true cross-functional teamwork (see Part 2 for how this enables broader scope mandates).

The growth-map model gives this a concrete structure: all roles develop the shared Builder Core plus capabilities in their specialisation wing. The Builder Core is the comb, the shared breadth that every team member develops. Specialisation wings are the teeth, the deep expertise that makes each person distinctively valuable.

Developing comb-shaped skills is a deliberate investment, not something that happens by accident. Engineering Coaches and leaders should actively create opportunities for Builders to work outside their primary expertise: pairing a backend developer with a frontend task, rotating testers into deployment work, encouraging architects to write production code. AI tools dramatically accelerate this multi-learning; they lower the barrier for a developer to become competent in an unfamiliar area without years of traditional apprenticeship. We lean into this aggressively. The healthcare.gov rescue showed what a small team of multi-skilled developers can do against a large army of specialists; that is the capability we are building toward.

Hiring: Generalists Over Specialist Backfill

The narrowly defined specialist role rested on an assumption AI has dissolved. We hire for breadth, judgment, and taste, and we backfill a specialist vacancy only after asking whether the role should still exist.

A narrowly defined specialist role only makes sense when expertise is scarce, hard to acquire, and demand for that exact skill is effectively unlimited (Krivitsky et al., 10X Org). With AI available as an always-on, infinitely patient teacher, the scarcity assumption no longer holds, and making a specialist dramatically faster only pays if someone needs the extra output. Nobody needs a thousand times more databases.

• Our default hire is a multi-skilled generalist who can define an outcome, specify the constraints, choose which work goes to AI and which stays human, and verify what comes back. Good taste now matters as much as execution skill. This is the Builder Core bar from Part 4, stated as a hiring filter.
• Before backfilling any specialist vacancy, ask: does this role still depend on the narrow-specialist assumption AI has dissolved? If a generalist with AI covers the work, redesign the role rather than refilling it.
• Deep expertise still earns its place as the teeth of the comb, hired where the domain genuinely demands it (security, actuarial, regulatory), rather than as the default shape of every requisition.

Go See (Gemba)

We practice “Go See” to avoid second-hand or filtered data. Leaders and team members regularly observe real user interactions, experience the product firsthand, and review raw information. When observing work or reviewing incidents, remember that those involved did not know the outcome. “Go See” means seeing the world as operators saw it at the time, not judging their decisions with our hindsight. Careful use of LLMs can extend Go See, helping leaders scan large datasets, identify patterns in incident data, or synthesise feedback from across the organisation at a scale manual review cannot match.

Growth Maps

Our growth maps define the competencies, levels, and development pathways for all roles. They connect individual growth to the organisational values described in Part 4. For a current view of team composition, roles, and structure, see the canonical Teams sheet.

Psychological Safety: The Foundation for Learning

For our teams to deliver their best work, they must feel safe to take interpersonal risks: asking questions, admitting mistakes, offering ideas, and raising concerns without fear of embarrassment or retribution.

Silence is often the psychologically rational choice. Amy Edmondson’s research names the mechanism: people run a quiet cost-benefit calculation every day, and silence benefits the self immediately and with certainty, while speaking up benefits the organisation later and uncertainly (The Fearless Organization, 2019). Nobody wants to look ignorant, incompetent, or disruptive, so questions, admissions, and suggestions are the first things to disappear. “No one was ever fired for silence.” Because silence is individually rational, creating voice requires organisational investment. Edmondson is equally direct about where the duty sits: insisting on individual acts of courage puts the onus on individuals without creating the conditions where the expectation is likely to be met. Leaders own the conditions.

High performance requires both high psychological safety AND high standards.

Edmondson’s two-by-two makes the point: high standards with low safety produces an Anxiety Zone, where people work hard but hide problems; high safety with low standards produces a Comfort Zone, pleasant and stagnant; only high safety with high standards produces the Learning Zone, where candour and ambition hold together. Her framing is worth quoting: psychological safety “takes off the brakes,” but it “is not the fuel that powers the car.” For example, our extensive Definition of Done creates high standards. Without matching psychological safety, we risk creating an Anxiety Zone where people are afraid to admit they’re struggling.

What psychological safety is NOT:

• It is not lowering standards or being “nice”
• It is not avoiding conflict or difficult conversations
• It is not protecting poor performers from feedback

What psychological safety IS:

• Candour about problems, concerns, and mistakes
• Productive disagreement and debate
• Experimentation and learning from failure
• Questions treated as contributions, not challenges

Leader behaviours that create safety:

Creating psychological safety is not optional. It is a core leadership responsibility for all leaders (Engineering Coaches, PMs, VSOs, VPs, CTO).

• Model vulnerability: admit your own mistakes first; leaders who appear perfect create fear
• Demonstrate situational humility: say “I don’t know, what do you think?”
• Speak last in discussions to avoid anchoring the team’s thinking
• Invite input explicitly: “What am I missing?” “Who sees this differently?”
• Respond productively to all contributions: express appreciation for concerns, especially uncomfortable ones. The moment after someone shares bad news is the moment the whole team is watching; thank them before anything else.
• Never punish messengers: create safety for bad news; silence is the most dangerous signal
• Watch for signs of silence: long pauses, excessive deference, “just kidding” additions

If your team isn’t raising concerns, something is wrong. Investigate the silence. For a periodic check, Edmondson’s validated seven-item survey (mistakes held against you; able to bring up problems; safe to take risks; easy to ask for help; and so on) works as an anonymous team pulse, and trends matter more than any single reading.