Scaling People

Essential Operating Principles

There is no single correct way to run a team. That is exactly the risk: without a deliberate operating philosophy, management defaults to whatever a leader's instincts happen to produce that day, which is inconsistent by definition. Four operating principles anchor everything that follows in the book, and each one recurs across every framework that comes after it.

Build self-awareness to build mutual awareness

A manager who cannot clearly name their own strengths and blind spots cannot build a team that complements them, and cannot tell that team what to actually expect from them either. Self-awareness here is not a soft, reflective exercise; it is a practical prerequisite for building around real gaps instead of pretending they do not exist.

That includes knowing your own defaults under stress: whether you tend to over-control, avoid conflict, or move too fast for the people around you. A team that knows a manager's patterns can compensate for them; a team left guessing cannot.

Say the thing you think you cannot say

This is the book's most repeated line, and it names a specific, common failure: managers routinely sit on an uncomfortable truth (a project that is not working, a hire who is not succeeding) hoping silence is kinder than saying it out loud. It rarely is. Avoidance almost always makes the eventual conversation harder, later, and with more damage already done.

A manager's real job is not to avoid disappointing people. It is to disappoint them at a rate they can actually absorb, which requires saying the hard thing while it is still small enough to fix, rather than waiting until it has grown into a crisis everyone can see.

Distinguish management from leadership

Leadership sets direction and gets people to believe in it. Management is the operational discipline, goals, structure, hiring, feedback, that actually gets an organization there. Conflating the two is a common promotion mistake: handing a compelling individual leader a management role they have never built the muscles for, or expecting a strong operational manager to also carry an organization's emotional vision.

Return to your operating system when pressure hits

The fourth principle sets up everything the rest of the book builds toward. When things get chaotic, the instinct is to improvise harder. The better move is returning to a documented operating system built in a calmer moment, precisely because pressure is the worst possible time to be inventing process from scratch.

A related trap belongs here too: handing out an inflated title early to close a candidate feels harmless in the moment, but it reliably backfires once the organization outgrows what that title was ever meant to signal, leaving a manager stuck negotiating a demotion in slow motion.

For a product manager, the "say the thing" principle is the sharpest test. A PM who quietly knows a roadmap commitment will not land, but stays silent through another sprint review hoping it resolves itself, is doing exactly what this chapter warns against: trading a small, early, awkward conversation for a larger, later, more damaging one.

Core Framework 1: Foundations and Planning for Goals and Resources

The fourth operating principle, returning to a documented system, only works if that system actually exists in writing. This chapter builds it: an operating system made of founding documents that make a company's why, what, and how explicit and referenceable, instead of living only in a founder's head.

Three documents: why, what, and how

• Mission: answers why the company exists, including its founding story, the origin narrative employees can retell in their own words to explain their own purpose for being there.
• Long-term goals: answer what the company is building toward. A horizon framework separates today's core business (Horizon 1) from emerging bets already underway (Horizon 2) and longer-range future opportunities not yet funded (Horizon 3), so ambition does not flatten into one undifferentiated list of priorities.
• Operating principles: answer how work actually gets done, deliberately swapped in for the vaguer language of "values." Where values tend to be abstract nouns (integrity, excellence), operating principles are written as specific behavioral commitments, concrete enough that an employee can point to a real decision and say whether it honored the principle or not.

Each document answers a different failure mode. A company without a stated why drifts toward chasing whatever opportunity looks attractive that quarter. A company without a stated what optimizes for short-term wins at the expense of the future it claims to want. A company without a stated how relies on lucky cultural fit instead of teachable behavior.

The distinction matters because vague values are unfalsifiable. Nobody can be held to "we value excellence." Someone can absolutely be held to a written principle like "we ship in small increments and get real user feedback before committing further," because that principle predicts a specific behavior a team can check itself against.

An operating cadence that makes the documents real

Founding documents only matter if the company actually runs by them, and Johnson describes a practice from her time at Stripe: a written Sunday-night update, a short note covering the past week's key results and the coming week's priorities, that structures the following Monday's leadership meeting before anyone has spoken a word out loud.

Written communication itself functions as a management lever, not just a formality. It gives everyone the same starting information, it forces a higher standard of thinking than talking off the cuff usually produces, and it avoids re-explaining the same context meeting after meeting to whoever missed the last one.

The same documents have to keep working as headcount grows by orders of magnitude, not just at founding size. Stripe's own operating system was built and refined across a stretch where the company grew from under 200 employees to more than 6,000, and the documents had to stay legible the whole way.

OKRs sit on top, not instead

Objectives and Key Results translate the long-term goals into a single quarter's trackable commitments, reviewed on the same recurring rhythm as the rest of the cadence. They are not a separate system bolted on afterward; they are the mechanism that keeps the founding documents from becoming a poster on the wall nobody actually revisits.

The underlying argument is that none of this machinery is bureaucracy for its own sake. It is what lets a founder's early clarity keep functioning at scale, past the size where they can personally review every decision.

For a PM, the operating-principles idea translates directly into how a product team writes its own working norms. A written principle like "we default to a two-week validation spike before a full build" is checkable in a way "we're user-obsessed" never will be, and it is the difference a new PM manager should aim for when documenting how their team actually operates.

Core Framework 2: A Comprehensive Hiring Approach

Hiring is the mechanism that turns a written operating system into an actual organization made of real people. Treating it as an engineered pipeline, built and refined over time, produces far more consistent results than treating it as a scramble that starts over from zero every time a role opens.

Engineering the pipeline before a role even opens

• Write transparent job descriptions grounded in the real hard and soft skills shared by a team's actual best performers, not a generic wish list designed to sound impressive to candidates.
• Revisit strong past applicants who were passed over for timing reasons rather than fit, instead of treating every search as starting from a blank slate.
• Treat referrals as a structured, high-signal source of candidates to actively cultivate, not an informal afterthought that happens to arrive on its own.

A rubric and a committee, not one interviewer's gut

Every candidate for a role is evaluated against the same standardized rubric, rather than letting each interviewer freelance their own questions and their own private bar. A shared rubric produces more comparable signal across interviewers and is fairer to the candidate as a result.

Stripe also used a role modeled on Amazon's "Bar Raiser" concept, a specially trained interviewer who joins panels across different teams specifically to protect a consistent hiring bar, independent of how badly any one hiring manager wants to fill the seat. Final decisions route through a hiring committee that weighs the accumulated evidence together, rather than deferring reflexively to the hiring manager's instinct.

Skill, will, and fit: three separate questions

Instead of collapsing everything into a single "would I hire them" gut call, a candidate gets evaluated along three distinct dimensions.

• Skill: can they actually do the work the role requires, today.
• Will: do they have the drive to push through the role's genuinely hard parts, not just its appealing ones.
• Fit: do they fit this specific team and this specific role, a narrower and more useful question than a vague sense of general culture fit.

Separating the three matters because a candidate can be strong on one and weak on another; collapsing them into one impression hides exactly the tradeoff a hiring committee needs to see clearly.

Promote from within or hire from outside

The chapter closes on a real tradeoff, not a default answer. Internal promotion preserves institutional knowledge and signals a real growth path to the rest of the team. External hiring brings a perspective or a skill the organization does not yet have anywhere inside it. The right call is made role by role, deliberately, not defaulted in either direction out of habit.

For a PM building out a team, the skill/will/fit split is the most portable idea here: a candidate who is clearly skilled but whose "will" seems aimed at a different kind of problem than the role actually offers is a weaker hire than a less experienced candidate whose will and fit are both genuinely strong.

Core Framework 3: Intentional Team Development

Hiring the right individuals is necessary but not sufficient. This framework covers how a manager actually turns a group of well-hired individuals into a team that performs as more than the sum of its parts.

The skill-will matrix

The chapter's central framework, borrowed from consultant Max Landsberg, crosses someone's competence at their job (skill) against their motivation to do it (will) into a two-by-two grid, and each quadrant calls for a different management response.

• High skill, high will: delegate broadly and get out of the way. Heavy oversight here is wasted effort and reads as a lack of trust.
• High skill, low will: a warning sign worth investigating directly. Dig into why motivation dropped before assuming it is a skill problem, since it usually is not.
• Low skill, high will: worth heavy coaching investment, because the underlying drive that makes coaching pay off is already there.
• Low skill, low will: the hardest quadrant, and it often signals a real role or fit mismatch that coaching alone will not resolve.

Delegation tracks consequence and reversibility too

Delegation depth should not be set by skill-will alone. It should also track how consequential and how reversible a given decision actually is. A high skill-will report can still warrant direct manager involvement on a high-stakes, hard-to-reverse call, while a low-stakes, easily reversible decision can be delegated fully regardless of quadrant, because the cost of being wrong is small either way.

Diagnosing and rebuilding, not just assuming health

A team's actual state needs a periodic, deliberate health check rather than an assumption that things are fine by default because nothing has visibly broken yet. That includes restructuring a team as the organization's shape and needs change, and rebuilding deliberately after a reorganization or a wave of departures, rather than letting the resulting shape be accidental.

Trust and inclusion built into the design

Team environment gets built in from the start, not layered on afterward. Offsites are structured around genuine, vulnerable check-ins rather than pure logistics and planning, and diversity and inclusion are treated as a structural part of how a team is designed, not an initiative added on top once the team already exists.

For a PM leading cross-functional collaborators they do not formally manage, the skill-will read still applies: an engineering partner who is highly skilled but currently low-will on a project is a coaching conversation about motivation, not a case for writing tighter specs, which is the wrong fix for the actual problem.

Core Framework 4: Feedback and Performance Mechanisms

The final framework turns the "say the thing you think you cannot say" principle from Chapter 1 into an actual ongoing system, rather than leaving it as a one-off act of individual courage that depends entirely on a manager's mood that week.

Hypothesis-based coaching, the informal track

Instead of forming a vague impression and delivering it as a verdict, a manager observes a direct report's behavior over time, builds a specific hypothesis about a persistent pattern (not a single one-off incident), and shares that hypothesis tactfully, framed around observable behavior rather than a judgment of the person's character.

The hypothesis gets tested and refined in conversation with the person it concerns, not handed down as a final ruling. That distinction matters: a hypothesis invites the other person to add context or push back, where a verdict just asks them to accept it.

A formal review built from three sources

Formal reviews draw on three separate inputs, blended into one calibrated rating rather than left as three disconnected opinions.

• Self-assessment: a brief written account of accomplishments, real strengths, and one honest growth area.
• Peer feedback: input from people who actually work alongside the person day to day, not just their manager.
• Manager evaluation: the manager's own synthesis, weighed alongside the other two rather than simply overriding them.

Managers also check rating patterns across the organization, comparing scores across different managers and demographic groups, specifically to catch systemic bias before ratings are finalized rather than discovering it afterward when it is much harder to correct.

Compensation follows calibration, not negotiation

Compensation follows from the calibrated performance signal rather than being negotiated ad hoc, conversation by conversation, which would reward negotiating skill instead of actual performance. The entire structure exists so a formal review functions as a confirmation of things a person already heard through ongoing coaching, never as the first time they hear the substance of the feedback.

For a PM, the "never a surprise" standard is a useful gut check on your own 1:1 habits: if a direct report's formal review would contain a single sentence they have never heard from you before that moment, the informal coaching track already failed, regardless of how fair the final rating turns out to be.

You

After walking through an organization's operating system, hiring engine, team structure, and feedback machinery, the lens turns inward, closing the loop back to Chapter 1's first operating principle: self-awareness. Everything built so far assumes a manager capable of running it, and that capability is not a given.

Seniority multiplies the ways things go wrong

Seniority does not make the job easier. More responsibility multiplies the number of ways daily reality can go sideways at once, across more people, more decisions, and more consequences a manager cannot fully see coming. A manager's own energy, self-knowledge, and sense of fulfillment become something to manage as deliberately as an org chart, not a background condition assumed to take care of itself.

That means treating your own patterns under stress with the same rigor Chapter 1 asked you to apply to self-awareness generally: noticing when you default to over-control, when you avoid a hard conversation, and when exhaustion is quietly shaping decisions you would make differently if rested.

Deciding what kind of leader you want to be

Deciding what kind of leader you actually want to be, and what tradeoffs you are willing to accept to get there, is inseparable from managing anyone else well. A manager who has never actually decided this defaults to whatever the loudest pressure in the room demands that day, which is precisely the instinct-driven management the whole book set out to replace with something deliberate.

For a PM, this closing turn is a reminder that the operating principles, hiring rubric, skill-will reads, and feedback habits covered so far only work if the PM applying them is also managing their own energy and blind spots with the same discipline, rather than running a well-documented system on personal fumes.

The Entire Book in One Framework

Every core framework here is the same operating system applied at a different altitude. The founding documents set why, what, and how at the company level. Hiring and team development apply that same system to actual people: choosing who joins, and how they get organized once they do.

Feedback and performance mechanisms close the loop by checking whether the system is genuinely working in practice, not just sitting well-written on paper somewhere. The closing chapter then makes explicit what was implicit the whole way through: the system has to include the manager too, not only the organization that manager is building.

The book is easy to misread as a manual for adding process and paperwork to a growing company. The real argument runs closer to the opposite: documents and cadence exist to preserve a founder's early clarity and directness at scale, not to slow it down or bury it under procedure.

10 Most Important Takeaways

• Write your own operating principles as specific behaviors, not abstract values, so people can point to a real decision and say whether it honored one.
• When something is wrong, say the specific thing you are avoiding saying, sooner rather than later.
• Separate leadership (direction, vision) from management (systems, feedback, structure) as two distinct skills you may need to build separately.
• Build founding documents around three questions: why (mission and founding story), what (long-term goals across time horizons), and how (operating principles).
• Treat hiring as an engineered pipeline, transparent job descriptions, a standardized rubric, a hiring committee, not one person's gut call.
• Evaluate candidates on skill, will, and fit to the specific role, not a single yes-or-no impression.
• Use the skill-will matrix to decide how much to delegate and what kind of support, autonomy or coaching, each person actually needs.
• Match delegation depth to a decision's consequence and reversibility, not to someone's skill-will quadrant alone.
• Practice hypothesis-based coaching: observe a real pattern, form a specific hypothesis, and share it around behavior, not character.
• Build formal reviews from three sources, self, peers, and manager, checked for bias, so the rating is never a surprise.

The single deepest idea in the book may be this: management is not a personality trait some people happen to have. It is a system of documents, cadences, and habits deliberate enough that anyone can learn to run it, and the real skill is returning to that system precisely when pressure makes improvising feel tempting instead.