Team Structure & Roles

Reading this with a small team? The structure below describes the full model at roughly 25–40 people. If you are smaller than that, start with Flexing Down for Smaller Headcounts, which covers collapsing roles into fewer, more senior people: which combinations work, which one to resist, what never collapses however small you are, and when to split roles back out.

1. Organisation Structure

Squad Composition

Product Squads

Role	Ratio	Reports To
PM	1 per squad	Head of Product
Lead Dev	1 per squad	Head of Eng
QA	1 per squad	Head of Eng (via Lead Dev)
Dev	3-6 per squad	Lead Dev

Platform Squad

Role	Ratio	Reports To
PM	1 per squad	Head of Product
Lead Dev	1 per squad	Head of Eng
QA	1 per squad	Head of Eng (via Lead Dev)
Dev	3-4 per squad (platform squads tend smaller)	Lead Dev

Unattached Roles

Role	Ratio	Reports To
Staff Engineer	1 per org	Head of Eng
PM Discovery & Stakeholders	1 per org	Head of Product
PM Analytics & Experimentation	1 per org	Head of Product

Smaller organisations run the same operating model with roles collapsed into fewer people. See Flexing Down for Smaller Headcounts.

---

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. Flexing Down for Smaller Headcounts

The structure above describes the full model: two or more product squads, a platform squad, and unattached specialists. That’s roughly 25–40 people. Most organisations are smaller than that, and many will never need to be that big.

A smaller organisation runs the same operating model with fewer people holding more of it. Roles are bundles of responsibilities, not job titles that must map one-to-one onto bodies. Collapse the bundles. Do not drop the responsibilities, and do not leave it vague who holds them.

The test for any collapsed role is simple: can everyone name the single person accountable for each responsibility? If the answer is “the team” or “whoever picks it up,” the responsibility has been dropped, not collapsed.

Reference Shapes

Shape	Size	Structure
Full model	25–40	As documented above. Multiple product squads, platform squad, Staff Engineer, specialist PMs.
Two squads, no platform	14–20	Platform work becomes an allocation inside both squads, co-ordinated by the Staff Engineer. Specialist PMs collapse into Head of Product.
Single squad	7–12	One PM, one Lead Dev, 4–8 Devs. Staff Engineer collapses into Lead Dev. Heads of Product and Eng collapse into one leadership role (often the CTO or a founder). QA becomes a named quality owner inside the squad.
Half squad	4–6	A PM and a Lead Dev pair running everything with 2–4 senior Devs. No platform function, no dedicated QA, no Staff Engineer. Architecture guidance comes from outside (advisor, fractional CTO, non-exec).
Founding team	1–4	One person owns product, one owns engineering. Sprints are dropped entirely in favour of continuous flow: see the Founding Team Operating Model. Everything else is deferred, deliberately and in writing.

These are reference points, not a ladder you must climb. Pick the smallest shape that covers the responsibilities and move up only when a trigger fires.

The first four shapes run the sprint-based process with the roles collapsed. The founding-team shape does not: at that size the cadence itself is the overhead, and the Founding Team Operating Model is a separate strand built around a kanban queue and an orchestration board rather than a compression of this one.

Which Roles Collapse Cleanly

Collapse	Verdict	Notes
Staff Engineer → Lead Dev	Clean	With one squad there is no cross-squad consistency problem to solve. The architecture, patterns, and AI playbook ownership move to the Lead Dev.
Staff Engineer → Head of Eng	Clean	Both are org-wide technical scope. Works while the Head of Eng still has time to be hands-on; stops working once they’re managing more than two squads.
PM Discovery + PM Analytics → PM / Head of Product	Clean	Discovery and measurement become part of the PM’s week rather than someone else’s job. Protect the time explicitly or it is the first thing to vanish.
Platform squad → allocation inside product squads	Clean	Keep the engineering allocation percentage. The work doesn’t shrink just because the squad owning it does.
QA → Dev (with a named quality owner)	Workable	Test automation becomes a first-class part of every Dev’s work, and one person owns quality strategy, CI gates, and production quality monitoring. Works with senior Devs. Fails quietly with junior ones.
Head of Product + Head of Eng → one leader	Workable	Common and sensible below ~12 people. The cost is that the what vs how tension now happens inside one head. Breaks earlier than most people expect, usually the moment there are two squads with competing priorities.
Lead Dev → Head of Eng	Workable	Fine for a single squad. With two squads this becomes a manager who is also the technical authority in both, which is where delivery health stops being monitored because the monitor is busy delivering.
PM → Lead Dev (one person owning both)	Resist	See below.

The Collapse to Resist

PM and Lead Dev in the same person is the one to avoid, even when the headcount maths says you can afford it.

The most valuable disagreement in this model is the daily one between the person who owns the problem and the person who owns the solution. It is where scope gets challenged, where “do we actually need this?” gets asked, and where feasibility pushes back on ambition. One person holding both sides will resolve that tension silently, and almost always in favour of whichever side they find more interesting. Technical founders build elegant things nobody asked for. Commercial founders promise things that cannot be built twice.

If it genuinely cannot be avoided:

• Make the tension external. Name someone outside the work (an advisor, a peer founder, the other half of the leadership pair) whose standing job is to challenge scope before it enters a sprint.
• Write the problem statement and success criteria down before thinking about the solution, and timestamp them. The artefact is the only thing preventing retrospective justification.
• Re-read the interface cheatsheet and treat its anti-patterns as a self-review checklist, not a description of other people.
• Treat it as the first role to split out when headcount allows.

What Never Collapses

However small the team, these survive:

• A single-threaded owner for what, and a single-threaded owner for how. If one person wears both hats, they wear them visibly and separately, and they say which one they are wearing.
• Someone other than the author confirming it works. Not a process, not a gate, just a second pair of eyes before customers are the ones who find out. With no QA function this is a peer Dev, and it is non-negotiable.
• A named person accountable for production out of hours. A two-person rotation is punishing but honest. “Nobody” is neither.
• Someone whose job explicitly includes the growth and wellbeing of the people. This does not collapse into “we’re all adults here.” One person owns 1:1s and career conversations even if they also write most of the code.
• An escalation point outside the team. If every escalation path terminates at the same person who made the original decision, escalation is decoration. Write down who the external backstop is (CTO, founder, board member, advisor) before you need them.

Fewer, More Senior People

Flexing down is not the same work spread thinner. It is a different staffing bet, and it only pays off if you make it deliberately.

Trade headcount for seniority. Co-ordination cost grows faster than headcount; capability does not. Five genuinely senior people will out-deliver twelve mixed-level people in a small organisation, because most of what the extra seven need is each other’s attention. At small scale, the right move is almost always fewer people at a higher level rather than more people at a lower one.

What “senior” has to mean here. Not years served, and not depth in one framework. In a collapsed-role organisation a senior IC:

• Takes ambiguous work and returns a plan, not a list of questions
• Carries a responsibility bundle rather than a task queue, owning the outcome including the testing, the deployment, the monitoring, and the cleanup
• Knows which defaults can be broken and asks before breaking them, rather than drifting
• Does not need the process to tell them what good looks like, which is exactly why a smaller team can run a lighter process

AI leverage raises breadth, not judgment. AI tooling is what makes it credible for one person to cover feature work, test automation, infrastructure, and documentation. It compresses the mechanical parts of each bundle, which is why the role collapses above are viable now in a way they were not a few years ago. It does not turn a mid-level Dev into a Staff Engineer. Leverage multiplies judgment; it does not supply it.

Be honest about the costs. They are real and they compound:

Cost	Reality	Mitigation
Thin bus factor	One person is the only one who understands a critical area	ADRs and runbooks matter more at small scale, not less. Written context is the only redundancy you have.
No bench for growth	Junior people have nobody to learn from and no safe work to learn on	Be honest that you are not a training organisation at this size. Hire juniors when there is someone with the capacity to grow them, not before.
Absence hurts disproportionately	Holiday, illness, or a resignation removes a whole function	Deliberate pairing on the highest-risk areas. Accept a slower pace during absence rather than pretending the capacity exists.
Seniority costs money	The maths only works if compensation reflects the level	Pay for it. A small team of senior people on mid-level compensation is a small team of senior people who are leaving.

Process That Flexes With It

The operating model compresses alongside the structure. What changes is ceremony and cadence, not discipline.

Below five people, compressing stops being enough and the cadence goes altogether: that is the Founding Team Operating Model. The table below is for the shapes above that.

Keep, unchanged	Compress	Drop until you need it
Trunk-based development behind feature flags	Refinement and sprint planning into one session	Cross-squad dependency process
The implementation plan conversation (it becomes a ten-minute chat, not a document)	Monthly architecture review into an ad-hoc session with an external advisor	Cross-squad prioritisation arbitration
Tiering of work before it enters a sprint	Retrospectives into one team retro	Separate platform intake queue
Incident review for anything customer-facing	1:1s to fortnightly, never less	Promotion approval chains: the one leader decides
Written decisions (ADRs) and runbooks	Metrics to the handful that change a decision	Formal competency frameworks
The engineering allocation percentage

The failure mode is not keeping too much process. It is quietly dropping the written artefacts (problem statements, implementation plans, ADRs) because “we all know what we’re doing.” At four people you do. At nine, with two of the original four gone, you don’t.

When to Split Roles Back Out

Collapsed roles are a position, not a permanent state. Split one out when a trigger fires, not when the headcount budget happens to allow it:

Trigger	Split out
A second product area appears with its own stakeholders and its own roadmap	PM, then a second squad
More than ~8 Devs reporting to one Lead Dev	A second Lead Dev
The on-call rotation is thinner than four people	Devs, before anything else
Platform and tooling work is consistently losing to feature work	Platform capability (one person before a squad)
Two or more squads are solving the same problem differently	Staff Engineer
Quality issues are being found by customers rather than by the team	Dedicated QA
Problem/solution trade-offs are being made without anyone noticing them being made	The PM / Lead Dev collapse, urgently
The collapsed-role leader is the blocker in most decisions	Whichever half of their role hands off most cleanly

When growth does allow a hire, split the role that is both the current bottleneck and the cleanest to hand over. Splitting the messiest role first feels urgent and usually produces two confused people instead of one busy one.

Small-Team Anti-Patterns

• Collapsing roles without saying so. “We don’t really do titles” means nobody knows who decides. Write down who holds which bundle, even if the answer is “all of them, for now.”
• Keeping the full ceremony at a quarter of the size. Four people do not need a sprint review, a planning session, a refinement session, and a retro every two weeks. Compress the meetings; keep the artefacts.
• The leader who is also the best IC taking all the hard work. It is the fastest path to delivery in week one and the reason nobody has grown by month six. Already an anti-pattern at full scale; at small scale it is near-irresistible.
• Hiring to the org chart instead of to the bottleneck. The full model is a destination, not a shopping list. Hire against the triggers above.
• Calling it “flexing down” when it is actually under-resourcing. Flexing down means fewer, more senior people covering the same responsibilities to the same standard. If the standard is slipping, you have not flexed down. You are under-staffed, and the honest response is to cut scope, not to quietly cut quality.

---

4. 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

Situation	First Step	Escalation
Technical disagreement within squad	Lead Dev decides	Staff Engineer consulted
Priority conflict within squad	PM decides	Head of Product
Priority conflict between squads	PMs discuss	Head of Product arbitrates
PM and Lead Dev disagree on approach	Conversation between them	Head of Product + Head of Eng
Executive-driven interruption	Head of Product takes the call	Head of Product makes trade-off visible
Technical risk concern	Lead Dev raises with PM	Head of Eng if unresolved
Quality concern overruled	QA documents risk	Lead Dev acknowledges; pattern tracked
Head of Product ↔Head of Eng disagree	Direct conversation in 1:1	CTO/CEO (should be rare)

---

5. 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.

Mechanism	Frequency	Purpose
1:1s	Fortnightly minimum	Career conversations: “What do you want to get better at? Where do you feel stretched vs comfortable?” Not status updates.
Deliberate work assignment	Every sprint	Growth through stretch assignments with support, not training courses
Feedback in the flow of work	Continuous	Implementation plan conversations, post-merge review, pairing: delivered in context, not saved for quarterly reviews
Sponsorship	As 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:

Promotion	Recommended By	Approved By
Dev →Senior Dev	Lead Dev	Head of Eng
Senior Dev →Lead Dev	Head of Eng	CTO
Senior Dev →Staff Engineer	Head of Eng	CTO

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