Separate What a Role Requires from What Is Merely Useful

This is the full playbook from “Put People Where Their Strengths Matter Most.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

The Critical Roles Template separates what a role requires from what is merely useful. Most job descriptions blur the two, and the blur produces bad-fit hires and bad-fit internal placements. A description listing twenty skills as equal requirements tells you nothing once a real candidate is in front of you.

1. List the critical roles on your team, not the job titles. A role is a function the team needs; a title is the name HR uses. “Incident commander for production systems” is a role. “Senior Backend Engineer” is a title, and it can contain that role or three others nobody has separated. Name the functions first, independent of your org chart: incident response, long-horizon architecture, customer-facing technical communication, security and compliance ownership, mentorship and onboarding.
2. List the must-have skills for each role. A must-have is a skill whose absence makes the role fail, whatever else the person brings. For an incident commander, that skill might be the ability to make an irreversible decision on incomplete information in minutes rather than hours. For a compliance-facing architect in a regulated environment, it can be direct experience with the specific regulatory framework governing your data; a similar framework does not count. Be strict. Name more than four or five and you have written a wish list.
3. List the good-to-have skills separately and visibly. A good-to-have makes a person better in the role, but its absence does not make the role fail. Deep familiarity with one cloud provider is usually good-to-have; reasoning about distributed-systems tradeoffs is usually the must-have beneath it. The separate list forces you to admit that some of your screening criteria are optional. Skip that admission and you narrow your options for nothing.
4. Map your roster against the table, role by role rather than person by person. For each role, identify who has the must-haves. If nobody does, you have a hiring gap, not a coaching gap, and internal development will not close it on any reasonable timeline. If someone has the must-haves but sits in a different role, you have found a positioning opportunity, often the most valuable result of the exercise, because the capability is already on the payroll and merely misallocated. Most organizations go shopping for advantage they already employ.
5. Review the table every two quarters. Must-haves shift with your product, your regulatory environment, and your scale. On a five-person team, broad competence across the whole stack is a must-have for the only backend engineer, because nobody else can cover it. On a twenty-person team it drops to good-to-have, because specialists own narrower parts.

Try this with AI.

“Here are the must-haves I wrote for this role. Interrogate each one: which would genuinely make the role fail if it were missing, and which am I listing only because that’s how the last person in the seat happened to work?”

On a five-person team, positioning is almost entirely about breadth: you need generalists who can cover several critical roles each, and your biggest risk is over-specializing someone into a role the team can’t afford to have single-threaded.

At twenty people you can build real specialists: a dedicated incident commander, a dedicated architecture owner. You also inherit a failure mode that doesn’t exist at five: roles that overlap unclearly, two people each convinced they own a decision the other one also owns. That’s a positioning failure as much as an understaffing one.

At a hundred people, the critical-roles table stops being something one CTO can hold in their head. Engineering managers maintain it for their own sub-teams while the CTO audits consistency across them. That is itself a positioning decision: the CTO’s own must-have at that scale shifts from knowing every engineer’s strengths to building managers who do. The table stays the same; the person who keeps it current changes.

All of the playbooks are listed on the playbooks page.