Navigate Ways of Working
← Index

Guides

Cheatsheets

Guide

Team Structure & Roles

Every role defined: purpose, responsibilities, key relationships, and what the role explicitly does not do. Includes career progression, level expectations, and promotion mechanics.

1. Organisation Structure

Organisation Chart

Squad Composition

Product Squads

RoleRatioReports To
PM1 per squadHead of Product
Lead Dev1 per squadHead of Eng
QA1 per squadHead of Eng (via Lead Dev)
Dev3-6 per squadLead Dev

Platform Squad

RoleRatioReports To
PM1 per squadHead of Product
Lead Dev1 per squadHead of Eng
QA1 per squadHead of Eng (via Lead Dev)
Dev3-4 per squad (platform squads tend smaller)Lead Dev

Unattached Roles

RoleRatioReports To
Staff Engineer1 per orgHead of Eng
PM Discovery & Stakeholders1 per orgHead of Product
PM Analytics & Experimentation1 per orgHead of Product

2. Role Definitions

Head of Product

Purpose: Owns what gets built and why. See the Product-Engineering Interface Cheatsheet for how this role interacts day-to-day with engineering.

Responsibilities:

  • Roadmap ownership and prioritisation
  • Stakeholder alignment and communication
  • Final call on what gets built and in what order
  • Final call on priority conflicts between squads or stakeholders
  • Protecting squads from executive drive-by requests
  • Joint quarterly planning with Head of Eng
  • Arbitrating cross-squad prioritisation conflicts
  • Managing and developing all PMs

Key relationships:

  • Head of Eng: Weekly 1:1 (most important meeting in the org). Shared accountability for outcomes. Head of Product owns “what,” Head of Eng owns “how.” Neither overrides the other’s domain.
  • PMs: Direct reports. Sets product strategy they execute within their squads.
  • Stakeholders: Primary interface for demand management. Makes trade-offs visible (“we can do that, but X slips”).
  • CTO/CEO: Escalation point for unresolvable disagreements with Head of Eng.

Does not:

  • Dictate how things are built
  • Override technical judgment
  • Approve or reject engineering allocation (15–25%)
  • Assign work to individual developers

Head of Engineering

Purpose: Owns how things get built and the health of the engineering organisation.

Responsibilities:

  • Technical strategy
  • Delivery health across all squads
  • Hiring and retention
  • Engineering culture
  • Security strategy (brings in external expertise if needed)
  • Owns the engineering allocation (15–25% of capacity for tech debt, reliability, tooling)
  • Joint quarterly planning with Head of Product
  • Managing and developing Lead Devs and Staff Engineer
  • Reviewing delivery dashboards weekly
  • Final escalation for severe customer-facing incidents

Key relationships:

  • Head of Product: Weekly 1:1. Shared visibility on dashboards. Mutual respect for domain authority. Disagree directly, never through reports.
  • Lead Devs: Direct reports. Grows them through regular 1:1s and observation of squad dynamics. Receives incident escalations and retro themes.
  • Staff Engineer: Direct report. Partners on technical strategy and architecture direction.
  • CTO: Reports delivery health and engineering performance monthly.

Does not:

  • Decide what gets built or in what order (that’s Head of Product)
  • Override product prioritisation
  • Attend squad retrospectives (people don’t raise real issues in front of leadership)

Staff Engineer (1 per org, no squad)

Purpose: Technical leadership across the entire engineering organisation. Force multiplier through architecture, standards, and AI adoption.

Responsibilities:

  • Architecture decisions and cross-squad consistency
  • AI playbook ownership — defines how AI tools integrate into workflows
  • Security standards and patterns (auth, encryption, input validation, API security)
  • Facilitates monthly cross-squad architecture reviews
  • Early warning system for cross-squad dependencies and code-level collisions
  • Defines patterns once so squads follow consistently
  • Raises the technical bar through reviews that teach, ADRs that explain reasoning, and cross-squad pairing
  • Sounding board for Lead Devs on complex technical decisions
  • Reviews shared platform code/API changes before merge

Key relationships:

  • Lead Devs: Peer-level technically. Provides guidance on cross-cutting concerns. Reviews their technical decisions on shared infrastructure. Available as sounding board.
  • Head of Eng: Partners on technical strategy. Receives direction on investment priorities.
  • Product squad devs: Pairs across squads to spread knowledge. No management authority but significant technical influence.
  • Platform squad: Close collaboration on shared tooling, AI infrastructure, and developer experience.
  • CTO: Reports progress, tech debt and architeural decisions to CTO, at least monthly and more often if required.

Does not:

  • Manage people (no direct reports)
  • Own a squad’s delivery
  • Have authority over squad-level technical decisions (that’s the Lead Dev)

Lead Dev (1 per squad)

Purpose: Technical authority within a squad. Accountable for squad’s technical output and the growth of its developers.

Responsibilities:

  • Technical design review for all squad work (the implementation plan conversation)
  • Matching work to people — who needs the stretch, who has domain knowledge, who’s overloaded
  • Facilitating refinement sessions
  • Managing the engineering allocation within the squad
  • Running incident reviews for squad-owned services
  • Onboarding new squad members (first-week schedule, codebase walkthrough, oversight transition)
  • Post-merge code review for learning and consistency
  • Growing developers through 1:1s (fortnightly minimum), deliberate work assignment, and feedback in the flow of work
  • Sponsoring developers for stretch opportunities
  • Implicit secondary on-call for the squad
  • Confirming technical readiness for releases
  • Surfacing retro themes to Head of Eng (themes, not specifics)
  • Recommending promotions to Head of Eng

Key relationships:

  • PM (same squad): Daily working partnership. PM owns the problem, Lead Dev owns the solution. The middle ground is resolved through constant, low-friction dialogue. Neither overrides the other. See the Product-Engineering Interface Cheatsheet for practical guidance.
  • QA (same squad): Collaborates on quality strategy. QA’s voice in “is this done?” is heard and documented, even if overruled.
  • Devs (same squad): Direct reports. Responsible for their growth, feedback, and work assignment. Adjusts oversight by experience level.
  • Staff Engineer: Consults on cross-cutting work, shared infrastructure, and when Lead Dev needs a sounding board.
  • Head of Eng: Direct report. Receives coaching on squad management and technical leadership.
  • Other Lead Devs: Peers. Collaborate at monthly architecture reviews and quarterly cross-squad retros.

Does not:

  • Decide what gets built or priority order (that’s the PM)
  • Act as a permanent gate on all code (post-merge review, not pre-merge approval)
  • Assign themselves all the hard work (develops others by giving them stretch assignments)

PM (1 per squad)

Purpose: Owns the problem space for their squad’s product area. For how product tiers and the intake process work, see the Product Process guide.

Responsibilities:

  • Problem statements, success criteria, and constraints for refinement
  • Backlog ownership; the only person who can add items to the squad’s backlog
  • Sprint goal definition
  • Prioritisation of squad work (within Head of Product’s strategic direction)
  • Release timing decisions (when to flip feature flags)
  • Stakeholder communication on progress and trade-offs
  • “Saying no” or escalating to Head of Product for air cover
  • Injecting unplanned work into sprints (only after consulting Lead Dev on capacity)
  • Collaborating with QA on acceptance criteria
  • Providing visibility to stakeholders (now / next / later / not planned)

Key relationships:

  • Lead Dev (same squad): Daily working partnership. PM presents problems, Lead Dev assesses feasibility. Solution design is a conversation.
  • QA (same squad): Collaborates on acceptance criteria at refinement. QA informs release readiness.
  • Head of Product: Direct report. Receives strategic direction, escalates priority conflicts, gets air cover for saying no.
  • Other PMs: Weekly 15-min sync with platform PM to align on cross-squad priorities.
  • Stakeholders: Manages expectations. Routes requests through the intake funnel.

Does not:

  • Write implementation details or technical specs
  • Assign work to individual developers
  • Approve or reject the engineering allocation
  • Override QA’s quality concerns without acknowledging the risk

Platform squad PM additionally:

  • Owns internal developer experience and shared services prioritisation
  • Balances platform roadmap against product squad requests
  • Manages the platform squad’s intake queue

PM Discovery & Stakeholder Management (1 per org)

Purpose: Extends Head of Product’s capacity on discovery, roadmap development, and stakeholder engagement.

Responsibilities:

  • User research and customer interviews
  • Competitive analysis
  • Roadmap development support
  • Stakeholder relationship management
  • Demand intake for cross-cutting requests

Reports to: Head of Product

PM Analytics & Experimentation (1 per org)

Purpose: Owns measurement infrastructure and feedback loops across all squads.

Responsibilities:

  • Analytics strategy and tooling
  • Experimentation framework (A/B testing, feature flag analysis)
  • Measuring AI-augmented workflow effectiveness
  • Surfacing product metrics and insights to PMs and leadership
  • Customer feedback synthesis

Reports to: Head of Product

QA (1 per squad)

Purpose: Quality strategy, exploratory testing, and production observability.

Responsibilities:

  • Attends refinement: asks about testability and edge cases, collaborates on acceptance criteria
  • Writes automated tests in parallel with development (not after)
  • Pairs with devs on testability
  • Owns quality gate criteria in CI
  • Exploratory testing for complex or risky changes
  • Production quality monitoring: error rates, regressions, anomaly detection
  • Maintains runbooks alongside squad devs
  • Curates and reviews AI-generated test suites
  • Cross-squad quality standard consistency (with Staff Engineer)
  • Confirms quality as part of release decision

Key relationships:

  • Lead Dev (same squad): Collaborates on quality strategy. Lead Dev ensures QA’s voice is heard in release decisions.
  • PM (same squad): Collaborates on acceptance criteria. Informs release readiness. Has documented voice if overruled.
  • Devs (same squad): Pairs on testability. Works in parallel, not sequentially.
  • Platform squad QA: Peer. Aligns on cross-squad testing standards.

Reports to: Head of Eng (via Lead Dev)

Does not:

  • Have a veto on releases (documented voice, not a gate)
  • Manually gate every PR or commit
  • Write detailed test plan documents (automated tests are the living documentation)

Dev (Senior / Mid-Level, 3-6 per squad)

Purpose: Build, test, and ship features end-to-end.

Responsibilities:

  • Own features end-to-end: design approach, build, test, deploy, monitor
  • Produce implementation plans and share with Lead Dev before coding
  • Commit to main behind feature flags, small and frequent
  • Write and maintain automated tests
  • Participate in refinement (when likely to build the item)
  • Participate in sprint planning (commitment conversation)
  • On-call rotation (weekly, frequency depends on squad size)
  • Write ADRs for significant technical decisions
  • Clean up feature flags within one sprint of full rollout or kill
  • Use AI tooling as standard practice
  • Flag discovered work and scope changes promptly

Key relationships:

  • Lead Dev: Primary technical mentor and coach. Shares implementation plans for review. Receives feedback and stretch assignments.
  • QA (same squad): Pairs on testability. QA writes edge case tests in parallel.
  • PM (same squad): Receives problem context at refinement. Does not receive implementation instructions from PM.
  • Other devs (same squad): Pairs on complex work when warranted. Mentors junior devs informally (for seniors).

Reports to: Lead Dev

3. Relationship Map

Within a Squad

        PM ◄──────► Lead Dev
        │              │
        │              │
        ▼              ▼
       QA ◄──────► Dev(s)
  • PM ↔Lead Dev: daily partnership, problem/solution conversation
  • PM ↔QA: acceptance criteria, release readiness
  • Lead Dev ↔Devs: implementation plans, coaching, work assignment, post-merge review
  • QA ↔Devs: parallel test writing, testability pairing
  • PM →Devs: problem context at refinement (not instructions)

Across Squads

  • Staff Engineer connects all squads technically (architecture, patterns, dependency detection)
  • PMs align weekly with platform PM on cross-squad priorities
  • Lead Devs collaborate at monthly architecture reviews and quarterly cross-squad retros
  • Head of Product ↔Head of Eng is the primary cross-functional alignment point (weekly 1:1)

Escalation Paths

SituationFirst StepEscalation
Technical disagreement within squadLead Dev decidesStaff Engineer consulted
Priority conflict within squadPM decidesHead of Product
Priority conflict between squadsPMs discussHead of Product arbitrates
PM and Lead Dev disagree on approachConversation between themHead of Product + Head of Eng
Executive-driven interruptionHead of Product takes the callHead of Product makes trade-off visible
Technical risk concernLead Dev raises with PMHead of Eng if unresolved
Quality concern overruledQA documents riskLead Dev acknowledges; pattern tracked
Head of Product ↔Head of Eng disagreeDirect conversation in 1:1CTO/CEO (should be rare)

4. Career Progression

Two Parallel Tracks

IC Track                    Management Track
─────────                   ────────────────
Principal Engineer          Head of Eng
        │                        │
Staff Engineer              Lead Dev
        │                        │
Senior Dev ◄──────────────► Senior Dev
        │                        │
      Dev                      Dev

Tracks are parallel in seniority and compensation at equivalent levels. Senior Dev and Lead Dev are peers. Staff Engineer and Head of Eng are peers. Switching between tracks is explicitly allowed and is not a demotion.

Level Expectations

Dev (Mid-Level)

  • Delivers well-defined features independently
  • Comes to Lead Dev with implementation plan
  • Writes solid code, tests, and documentation
  • Participates in refinement
  • Handles on-call competently

Senior Dev

  • Takes on ambiguous work with less guidance
  • Implementation plan conversations with Lead Dev are peer-level discussions
  • Mentors mid-level devs informally
  • Identifies and raises technical risks proactively
  • Leads complex multi-sprint features end-to-end

Lead Dev

  • Accountable for squad’s technical output and developer growth
  • Success measured by squad output, not personal output
  • Owns implementation plan reviews, work-to-people matching, refinement facilitation, engineering allocation, incident reviews
  • Grows developers through 1:1s, deliberate assignment, and in-context feedback

Staff Engineer

  • Scope is the entire engineering org, not a single squad
  • Owns architecture decisions, AI playbook, cross-squad consistency
  • No direct reports but significant technical influence
  • Facilitates monthly architecture reviews
  • Defines patterns that squads follow

Head of Eng

  • Job is organisational effectiveness, not technical decisions
  • Owns technical strategy, delivery health, hiring, engineering culture
  • Manages Lead Devs and Staff Engineer
  • Reports upward on engineering performance

How Growth Happens

Lead Devs are responsible for growing their squad’s developers. This is a first-class responsibility, not a spare-time activity.

MechanismFrequencyPurpose
1:1sFortnightly minimumCareer conversations: “What do you want to get better at? Where do you feel stretched vs comfortable?” Not status updates.
Deliberate work assignmentEvery sprintGrowth through stretch assignments with support, not training courses
Feedback in the flow of workContinuousImplementation plan conversations, post-merge review, pairing — delivered in context, not saved for quarterly reviews
SponsorshipAs opportunities arise”I’m going to advocate for you to take on this project” — not just mentoring (“let me help you think through this”)

Head of Eng grows the Lead Devs through regular 1:1s and observation.

Staff Engineer raises the bar through architecture reviews that teach, ADRs that explain reasoning, and cross-squad pairing.

Promotion

Process: No elaborate competency matrices. The question: “Is this person already consistently operating at the next level?” If yes, promote. If not yet, define the development needed and revisit in 3–6 months.

Approval:

PromotionRecommended ByApproved By
Dev →Senior DevLead DevHead of Eng
Senior Dev →Lead DevHead of EngCTO
Senior Dev →Staff EngineerHead of EngCTO

Promotions happen when earned, not on a fixed annual cycle.

Anti-Patterns to Avoid

  • Informal “tech lead” roles without title or compensation — if someone is doing Lead Dev work, give them the role
  • Promoting the best coder to Lead Dev — technical excellence is necessary but not sufficient; use the IC track for people who don’t want to or can’t develop others
  • No career conversations until someone threatens to leave — the 1:1s exist to prevent this
  • Treating growth as conference attendance — 90% of growth happens through progressively harder work with good feedback
  • Always giving hard work to the same senior — juniors don’t grow, senior becomes single point of failure