Scaling Leadership: From Managing People to Managing Systems
Topic: Scaling Leadership·4 Principles
"What got you here won't get you there." — Marshall Goldsmith
This week's premise: Leading 5 people well and leading 50 people well are not the same job scaled up—they are two different jobs. At 5, you create impact through hands-on work and high-frequency contact; at 50, everything you touch personally dilutes your leverage. The real pain of scaling is four invisible leaks: your attention doesn't stretch (still managing people when you should manage systems), org structure is quietly deciding your architecture (Conway's Law), your words decay one layer at a time, and culture doesn't replicate on its own. Four principles, one patch each—turning you from "the busiest person" into "the one who makes others do the right thing."
PRINCIPLE 01
From Managing People to Managing Systems: Your Output = Your Org's Output
From Managing People to Managing Systems
LeverageSystems ThinkingDelegation
Principle + Quote
The first mental switch of scaling: your output is no longer what you do with your own hands—it is the output of your organization plus the neighboring organizations you influence. Stop asking "how much did I do today," ask "which thing I did moved the most people's output"—one high-leverage move (hiring the right person, fixing a process, clarifying direction) beats ten hands-on tasks.
"A manager's output = the output of his organization + the output of the neighboring organizations under his influence."— Andy Grove, High Output Management, Ch.3
Scene: From Firefighter to Fire-Suppression System
Context: BigCat's team grew from 6 to two squads of 16, but you still want to review every PR and jump on every incident. Reports start routing around you, because "waiting for BigCat takes three days."
✗ Still managing people (doesn't scale)
"Wait for me to review this Friday before merging." "Call me when prod breaks—I'll look." "I'll make that call." —You've become the bottleneck. The harder you work, the more the team depends on you, and the bigger it gets the more it clogs.
✓ Managing systems instead (scales)
Replace "me" with "a mechanism": "I'll stop reviewing every PR. Let's define three must-see-me red lines (schema changes, auth changes, cross-team APIs); everything else, you pair-review."
"Incidents no longer wait for me—we write an on-call runbook and escalation path. Whoever's on call decides first; afterward we do a blameless review to improve the system."
"My output this week isn't code—it's standing up these two mechanisms. They'll review for me all year."
High-Leverage Self-Check
Can only I do this? Or am I "fastest/most comfortable" so I won't let go? (Latter = delegate.)
Am I solving "this one problem," or building a mechanism that solves "problems like this" automatically?
Did I do one thing this week that moved 10+ people's output (hiring, process, direction, unblocking)?
If I vanished for two weeks, where would the team stall? That choke point is your next thing to systematize.
Is the ratio of "hands-on work" to "raising org capability" on my calendar shifting as we scale?
Pitfalls + A Note for Women Leaders
Mistaking "busy" for "valuable." After scaling, your busiest moments are often your lowest-leverage ones.
Delegation = dumping. Delegation gives decision rights + context + a safety net, not tossing a mess over the wall.
Delegating tasks but not judgment. Reports never grow decision muscle; you stay the bottleneck forever.
Female Leader's Note
The most easily ignored work in scaling is "glue work" (Tanya Reilly, Being Glue)—the coordination, documentation, and cross-team alignment that hold projects together. It is precisely the systems work required to grow an org from 6 to 16, yet it's often treated as "chores," falls disproportionately on women, and never makes it into promo packets. Counter-move: make it visible as systems output—say "I built the cross-team release protocol / incident process," not "I helped everyone coordinate." It's architecture, not chores.
This Week's Exercise + Reflection
Exercise: List 5 things you did by hand this week; for each, ask "how many people's output did this move?" Take the lowest-leverage one and delegate or systematize it this week.
Reflection: The thing I won't let go of—is it because others truly can't do it, or because letting go would make me feel "useless"?
PRINCIPLE 02
Org Design: The Org Chart You Draw Is Your Future Architecture Diagram
Org Design — Conway's Law Is Not Optional
Conway's LawTeam TopologiesCognitive Load
Principle + Quote
Org structure isn't an admin problem—it's a technical architecture problem. A system's shape inevitably grows into a mirror of the team's communication structure (Conway's Law). So designing team boundaries = designing software boundaries in advance: to get an architecture, first organize teams into that shape; and keep each team's responsibility within its cognitive load (Team Topologies).
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."— Melvin Conway, How Do Committees Invent?, 1968
Decision Map: How to Split Teams · When to Split
Scene: The Conversation Before Splitting
Context: Your 12-person team carries three product lines and keeps slowing down. Your boss asks, "Should we add headcount?"
"The problem isn't hands—it's boundaries. These three lines are too tightly coupled; change one, everything moves. I propose splitting into two stream-aligned squads, each owning one value stream end-to-end, decoupled by clean API contracts."
"After the split each squad is 6, cognitive load stays manageable. Then judge which squad is truly short—likely just 1, not 4. Org design first; hiring is the result, not the starting point."
Org-Design Decision Checklist
What architecture do I want? Are team boundaries already cut to match it? (Inverse Conway.)
Can each team state "what we own" in one sentence? Can't = fuzzy boundaries.
Is the team's cognitive load overloaded? (Too many domains / too many deps = narrow or split.)
After the split, does cross-team work run on clean interfaces, or on "human alignment meetings"?
Before adding people, did I first ask "is this a structure problem or a headcount problem"?
Pitfalls
Drawing the org chart for politics. Cut teams by someone's clout and the architecture grows deformed; engineers pay the debt.
Endlessly growing one team. A 1:12 manager can't do quality 1:1s or hold deep technical judgment.
Splitting without clear boundaries. A split with no API contract just moves coupling from code into the meeting room.
Frequent reorgs. Each reorg costs a 3–6 month adaptation tax—don't treat it as a cheap tool.
This Week's Exercise + Reflection
Exercise: Draw your team's current communication structure, then draw your system's architecture, and overlay them—where do they misalign? That's Conway's Law collecting its tax.
Reflection: My last org change—was it to make the architecture healthier, or to smooth over a people problem? If the latter, who pays the cost?
PRINCIPLE 03
Communication Dilution: You Say It Once, the Front Line Hears It Seventh-Hand
Communication Dilution — Say It Until You're Sick of It
Over-communicateWrite It DownContext
Principle + Quote
Information decays one layer at a time, and by the time it reaches the front line your "clear direction" is unrecognizable. Scaling leaders must accept a counterintuitive fact: the moment you think you've said it too much is when employees have just heard it. Two counter-moves—repeat until you're sick of it, and write key decisions as structured prose so they don't rely on word-of-mouth.
"We don't do PowerPoint... Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting."— Jeff Bezos, Amazon 2018 Shareholder Letter
Decision Map: The Decay Funnel of a One-Line Direction
Scene: Keeping Direction Intact All the Way Down
Context: You said "Q3 focuses on stability" at the all-hands; two weeks later one squad is still cranking out features.
✗ "Didn't I already say this?"
"I clearly said focus on stability at the all-hands—how did you not hear it?" —Saying it once ≠ landing it. Blaming the front line only makes people less willing to admit "I didn't hear it clearly."
✓ Redundancy + writing + have them restate
Write it down: a one-page "Q3 Direction" memo that explicitly lists what we won't do (the trade-off is what gets rounded off first). Send it to every channel.
Confirm in reverse: "In your own words, what did we give up for stability this quarter?" (Have them restate the trade-off, not nod.)
Repeat: deliver the same direction at least 5 times—all-hands, weekly, 1:1, Slack—wording varies, core doesn't. You're sick of it; the front line just heard it.
Anti-Dilution Checklist
Key decisions—did I put them in writing (not just say them verbally in a meeting)?
In my direction, is "what we won't do" as clear as "what we will do"?
Did I have a report restate it in their own words once, to detect drift?
The same key message—did I repeat it across ≥3 channels, ≥5 times?
Bad news—did I deliver it personally, early, and directly, not let it filter and warp layer by layer?
Pitfalls
Assuming "said it once" = landed. The bigger the scale, the closer single-pass reach gets to zero.
Saying only what to do, not what not to do. "Focus" without a trade-off becomes "do everything" by the bottom.
Fearing repetition looks tedious. Your boredom with a message far exceeds employees' familiarity—keep repeating.
Letting HR/email carry the bad news. Filter layers warp it, and the team remembers you "didn't dare say it yourself."
This Week's Exercise + Reflection
Exercise: Pick a direction you assume everyone gets, and randomly ask 3 front-line members "say what this is in your own words." Compare their answers to your intent—the gap is your dilution rate.
Reflection: When a message drifts, is my first reaction "they didn't listen" or "I didn't land it"? That attribution decides whether I keep hitting the same pit.
PRINCIPLE 04
Scaling Culture: Culture Is How People Decide When You're Not There
Scaling Culture — What Happens When You're Not in the Room
CultureModelingInstitutionalize
Principle + Quote
At 10, culture = the founder's shadow, spread by personal contagion. At 100, the majority are beyond your shadow's reach, and culture can only be carried by institutions—what you rewarded, what you punished, who you hired, who you let go, what you tolerated. The words on the values wall don't count; your behavior and your incentive system are the real culture.
"Culture is how a company makes decisions when you're not there. It's the set of assumptions your employees use to resolve the problems they face every day."— Ben Horowitz, What You Do Is Who You Are
Scene: Culture Is Defined by Behavior, Not Slogans
Context: Your team's values say "Quality First." But last quarter someone who rushed to ship, buried tech debt, yet delivered on time got the top rating; another who insisted on paying down debt and slipped a week was marked "slow."
✗ Slogan vs. incentives diverge
You keep saying "we value quality" at the all-hands. —The team watches performance outcomes, not your slides. The real culture now reads "quality first in words, rush-and-ship gets rewarded," and next quarter everyone will rush.
✓ Define culture with behavior and incentives
Align incentives: publicly recognize the debt-paying, week-late person—"They made the right but unpopular trade-off; that is what 'quality first' means." Make the rewarded behavior = the value you claim.
Design culture carriers: institutionalize "quality" into systems—code-review gates, a tech-debt budget, blameless incident retros. Culture can't rely on inspiration; it must run on its own when you're not there.
Scaling-Culture Checklist
The person I last promoted/recognized—did they truly embody the value I claim? (Incentives = real culture.)
What's the worst behavior we tolerate? That is the team's actual behavioral floor.
Are values turned into executable mechanisms (hiring bar, review rules, rituals), not just a poster?
Within a new hire's first 30 days, by what concrete practices do they learn the culture, not "osmosis"?
When a decision happens without me, dare I predict how the team will choose? Dare = culture has landed.
Pitfalls
Thinking written values = having a culture. Culture is what you reward and punish, not what you posted.
Tolerating the high-performing "asshole." Keeping one values-violating star tells everyone values can be bought out with results.
Expecting culture to spread on its own. Past 50 people, an undesigned culture grows into a shape you didn't want.
The leader making an exception for themselves. Every exception you make is a culture "re-training" for everyone.
This Week's Exercise + Reflection
Exercise: List 2 people rewarded and 2 sidelined last quarter, with reasons, and check them against the values you claim—do the real culture and the slogan match? The mismatches are the incentive misalignments to fix next quarter.
Reflection: When did I last turn a blind eye to a values-violating behavior for the sake of "results"? What rule did the team learn from my silence?
Going Deeper
Can "from managing people to managing systems" go too far and become cold, process-only management?
Yes—this is a real trade-off. Systematizing solves the "repeatable, standardizable" problems; but human motivation, trust, and career anxiety can't be carried by process—they need you present in person. The healthy move is to tier it: systematize the standardizable (review rules, on-call, decision flows), and pour the freed-up energy doubly into the non-systematizable—high-quality 1:1s, career conversations, trust repair. Systems exist to free you for what only a person can do. Warning sign: you start using "check the data / check the process" to avoid talking to a specific person about a specific hardship.
Do small teams (<10) even need this, or does forcing it just add bureaucracy?
Mostly the latter—don't over-optimize early. Under 10, high-frequency contact is enough to carry culture and communication, and forcing six-page memos or formal org design just slows you down. But two things are worth doing early: one, the habit of writing key decisions down (cheap, and the foundation for future anti-dilution); two, aligning incentives with values (a misalignment at 10 becomes a disaster amplified at 50). The rest—org design, formal communication mechanisms—add them once you feel "the message isn't landing." That pain point usually shows up between 15–25 people.
If Conway's Law says architecture mirrors org, do you set architecture first or org first?
Use the "Inverse Conway Maneuver": work backward from the target architecture to the org structure, deliberately cutting teams into the shape you want the system to grow into, so the law works for you instead of taxing you. But be honest about two things: one, this needs sufficiently clear architectural intent—in early exploration the architecture isn't settled, so don't rush to freeze the org; two, reorgs are costly, so this move only fits architecture directions worth a long-term bet, not frequent tweaks. Principle: when the direction is clear and worth long-term investment, use org design to "lock" it in.
In big companies a tech lead manager often can't decide org structure—does this still apply?
Yes, but play "influence" rather than "decide." You may not change the org chart, but you can change the de facto collaboration boundaries: define clean API contracts, make clear who owns what, set up cross-team liaisons—this "soft org design" needs no HR sign-off. Meanwhile, take the structural problems you observe (Conway misalignment, cognitive overload, a 1:12 manager who can't cope) and make the case with delivery lead-time data to whoever can change the structure, and you move from "enduring the structure" to "influencing" it. Making the case upward that "this is a structure problem, not an effort problem" is itself a high-leverage move.