Home/Insights/The GEAR Model

The GEAR Model: Design Your Org Around What It Needs, Not What It's Called

The Argument in Brief

Most org charts are drawn around what each box is called - a Sales department, an Engineering department, a hierarchy of titles. That shape optimizes for control. It answers "who reports to whom," but not the question the business actually lives or dies on: how fast can we turn a need into a result.

GEAR is a needs-first operating model. You design the organization around four needs every scaling company shares - Growth (sell more), Efficiency (spend less), Agility (move fast), and Resilience (stay adaptive) - each with a single accountable owner, served by small autonomous pods, with fast decision rights and one shared scoreboard. This piece includes the org chart, the decision-and-delivery flow, and a six-step rollout you can own yourself. It is grounded in Bain, McKinsey, Team Topologies, DORA, Cagan, and Galbraith.

Author: May Mor - Efficiency Leader. M.Sc in AI, former Technical PM at a digital bank (built the onboarding that scaled an R&D team from 30 to 150 developers) and an AI-native adtech company. Currently running organizational reviews across regulated and operationally complex industries, and advising early-stage startups as consultant and board member.

The Org Chart Optimizes for the Wrong Thing

The default org chart is drawn by function and title: a Sales department, a Marketing department, an Engineering department, an Operations department, each stacked into a hierarchy. That shape does one thing well, which is control. It answers "who reports to whom." It does not answer the question the business actually lives or dies on: how fast can we turn a need into a result.

As a company scales, the functional chart quietly works against it in three ways. Decisions slow down, because every cross-functional call has to climb one silo and descend another. Roles get drawn across contradictions, because a title like "Product Manager" is defined by an outcome rather than by a coherent capability. And the scoreboard fragments, because each function watches its own local metric while no one owns the number the company is really trying to move. None of this shows up on the chart. All of it shows up in the results.

Melvin Conway named the deeper version of this in 1967: systems end up mirroring the communication structure of the organizations that build them. If the org is drawn as rigid silos, the product, the process, and the speed will be too. So the design of the organization is not an HR question sitting downstream of the strategy. It is part of the strategy.

Four Needs, Not Fifteen Departments

GEAR reframes the organization around four needs that every scaling company shares. Each becomes a first-class outcome with a single accountable owner, rather than an accident that emerges from the sum of the departments.

G
Sell more

Growth

Everything that finds, wins, and expands revenue. Owns the number the company is actually trying to grow.

E
Spend less

Efficiency

Everything that removes cost, rework, and friction. Owns margin and the operational leakage no report shows.

A
Move fast

Agility

Everything that turns a decision into shipped value. Owns cycle time and how quickly the company acts on what it learns.

R
Stay adaptive

Resilience

Everything that keeps the company alive and relevant through change: data, renewal, capability, and the next bet.

GEAR is not four new departments. It is an overlay that tells you what the structure is for, and then lets you staff each need with small, cross-functional teams instead of tall functional stacks. This is the same instinct behind McKinsey's five trademarks of agile organizations, whose center of gravity is a network of empowered teams running rapid decision-and-learning cycles on a stable backbone, rather than a rigid hierarchy.

SHARED NORTH STAR + SCOREBOARD the correct KPIs, where planners and executors meet GROWTH owner sell more EFFICIENCY owner spend less AGILITY owner move fast RESILIENCE owner stay adaptive GROWTH POD Closer Demand / brand RevOps small, cross-functional EFFICIENCY POD Ops lead Finance Automation / AI owns margin and rework AGILITY POD Product (discovery) Engineers Designer a stream-aligned team RESILIENCE POD Data / insight R&D / next bet People / enablement keeps the company adaptive PLATFORM & ENABLING TEAMS shared services and coaching that lower every pod's cognitive load The founder covers the missing style most often the Operator the visionary founder is not, hired against the gap rather than cloned
Figure 1. A needs-first org chart. Four need-owners, each fronting a small autonomous pod, all sharing one scoreboard and one platform layer. Structure is drawn around outcomes, not titles.

Who Decides, Who Delivers

Structure only pays off if decisions move through it quickly. Bain's research across roughly 800 companies found a 95% correlation between how well an organization makes and executes its key decisions and its financial performance. Speed and quality of decisions are not a nice-to-have; they track the results. So GEAR pairs the org chart with an explicit decision-and-delivery flow.

The principle is one owner, small team, clear guardrails. Each need has a single accountable owner (Amazon's "single-threaded leader"), who decides within pre-agreed guardrails and only escalates when a call genuinely crosses two needs. Delivery happens inside small, autonomous pods that can act without waiting on three other teams, which DORA's research identifies as one of the strongest predictors of delivery performance. And every loop closes on the shared scoreboard, so the decision and its result are visible in the same place.

SIGNAL market / customer / data NEED-OWNER routes it to the right need Crosses a need? yes Owners align (fast huddle) no OWNER DECIDES within guardrails, no committee POD DELIVERS small, autonomous, no waiting SCOREBOARD CHECK planners and executors read the same correct KPIs, and the learning loops back learn
Figure 2. The decision-and-delivery loop. A signal becomes a fast decision (owner decides unless it crosses a need), the pod delivers, and the result closes on the shared scoreboard before the next loop.

Design Each Seat for One Mind

A needs-first structure only stays fast if the seats inside it are coherent. The most common way a seat goes wrong is that it is defined by an outcome ("own the product") rather than a capability, so it quietly bundles two opposite minds - a planner and an executor - into one chair. No one is strong at opposing things at once, so every hire is good at one half and weak at the other, and the company misreads a role-design problem as a people problem. Product Manager is the textbook case; Engineering Manager, Head of Sales, and the full-stack growth marketer are the same shape.

Two types matter most as a company scales, and they pull in opposite directions - the gas pedal and the brake. The Visionary generates direction, spots the opportunity, and starts things (Adizes' Entrepreneur; Belbin's Plant and Shaper) - almost every founder is one. The Challenger can stop a bad bet, change direction, mitigate the risk, and play bad cop when everyone else has fallen for the plan (Adizes' Administrator; Belbin's Monitor Evaluator). A healthy company runs both, in tension, on purpose. The most common scaling failure is a company that is all gas and no brake: a Visionary founder with no one whose job is to say "not yet, and here is why" - which is exactly why a standing devil's-advocate function is not negativity but the missing brake, installed deliberately. A third type goes missing just as often: the Finisher, who drives the last mile to done while the Visionaries are three ideas ahead.

The redesign move

The fix is never a second hire into the same broken seat. In order of leanness: re-scope the seat to one mind and give the conflicting half to tooling or a complementary teammate; pair two partial fits you already have; or split into two seats only when volume truly justifies it, because every split adds a handoff. I unpack the psychology of why these roles are genuinely unfillable - and the split, pair, and scope moves in full - in The Unicorn Trap.

The caution runs the other way too. Splitting a seat is never free: every handoff loses context, and an organization that shatters every role into narrow specialisms trades the unicorn problem for a fragmentation problem, where everyone optimizes their own half and no one owns the whole outcome. So the goal is not to specialize everything. It is to design each seat for a coherent capability while protecting end-to-end ownership - pairing where two modes are genuinely needed, and reserving the rare people who hold both for the seats that truly demand integration.

But How Do People Get Promoted?

The first fair objection to a needs-first org is that flattening the chart removes the ladder people climb. If there are fewer boxes to move up into, how does anyone get promoted, feel valued, or prove to a future employer that they grew? The answer is to replace the title ladder with a clearer signal, not to remove the signal.

Give people a level, not just a title - the score. Define advancement by scope and impact rather than by headcount managed: you contribute, then you own a component, then you own a need end to end, then you set the standard other pods follow. Moving up a level is the promotion, and the level is a score that travels. The best technology companies already run this way - Microsoft's engineering ladder climbs from SDE I to Principal to Distinguished Engineer with no one taking on reports, and at Google a Principal Engineer is paid like a Director. You do not have to invent grander titles. You need a level and a documented record of what the person owned, which is what a future employer actually reads. "Owned the Efficiency need, cut cycle time by a third in two quarters" is more legible than "Senior Manager II."

Offer two tracks, at equal pay. Let people advance by deepening mastery and scope as an owner, or by managing people, at the same levels and the same compensation bands, so a lead who owns a need and a manager who runs a team sit on the same rung. Moving between them is a lateral choice, not a demotion, and people stop becoming reluctant managers just to earn more.

Scale it to your size. A thirty-person company does not need a ten-rung ladder. Three or four honest levels, defined by the scope of the need a person can own, is enough, and far better than the invisible pecking order a flat org drifts into when no one defines progression at all. The real danger of flatness is not too few titles. It is an unspoken hierarchy that no one can see or argue with.

Who owns this: make People an enabling team

In a needs-first org, the People function is not a control department that approves headcount and files paperwork. It is an enabling team, in Team Topologies terms, that owns the operating system for people: the level framework, the recognition rituals, and the development that moves someone from owning a component to owning a need. When "everyone owns culture," no one does, so give the people system a single accountable owner, the same way every other need has one. The full people operating system that owner runs - hiring, onboarding, leveling, performance, recognition, and exits - is its own piece: The People Operating System. How that owner communicates the feedback and recognition that make advancement feel real is its own craft; I wrote about it in what NVC taught me about leading teams under pressure, and about developing people past their ceilings in The Performance Paradox.

Hire the Need, Not the Job Description

If you organize around needs, you hire around them too. A typical job description is a list of tasks and a title, which is exactly how contradiction roles get written: a wish list no single mind can fill. Hire for the outcome the seat must produce instead of the tasks you imagine it doing.

Some companies already run this way. Haier reorganized into roughly four thousand microenterprises, each formed around a specific user need, and pushed decision, hiring, and profit rights down to the front-line team, so people are brought in to close a market gap rather than to fill a box. Netflix hires for the problem and pays top of market for the capability to solve it. The unit of hiring is a need or an outcome, not a rigid role.

How to build the process:

  1. 01

    Write a scorecard, not a job description

    Geoff Smart and Randy Street's method defines a seat by its mission, three to six measurable outcomes it must produce, and the competencies to get there - not a task list. You are hiring against "what does this need require," which is the GEAR question.

  2. 02

    Name the one mind the seat needs

    Per the role-design section, specify whether the seat is assessment-first or locomotion-first and hire for it coherently, staffing the complement separately instead of demanding both in one person.

  3. 03

    Predict with work, not talk

    Structured interviews and a real work sample - a paid trial task or a walkthrough of a genuine problem - predict on-the-job performance far better than an unstructured culture chat. Ask what the candidate has owned and what measurably happened.

  4. 04

    Hire the pair on purpose

    When a need genuinely requires two modes, interview two people for complementarity, not two clones, and make their shared accountability explicit.

  5. 05

    Level the hire on day one

    Slot the offer into the level framework so the growth path, the score, is legible from the start.

Here too, the People function acts as an enabling team: it owns the scorecard library, the structured-interview kits, and the leveling, so every pod hires consistently without a central gatekeeper slowing them down. The shift is small to say and large to run - stop hiring people to fill roles, and start hiring them to meet needs. The deeper argument for why the roles themselves must be drawn for one mind is in The Unicorn Trap.

Interview for the Company, Not the Requisition

A growing company usually has five or six needs open at the same time, and interviews every candidate against exactly one of them. Every question is scoped to that requisition. Nobody in the room is asked, and nobody is expected to answer, whether the person in front of them would be excellent somewhere else in the building.

So a candidate who would move Efficiency substantially is assessed only against a Growth seat, scored as a no, and released. Three months later the same company hires an adequate person for the Efficiency need and never connects the two events. The candidate experiences it as rejection. The company experiences it as a normal funnel. Neither notices that a match existed and the process was not built to see it.

This is the same failure as the bundled job description, one layer further on. The requisition is treated as the unit of assessment because it is the unit of budget, and the assessment inherits a boundary that has nothing to do with where the person could contribute. Three changes fix most of it, and none of them require new software.

The second-door question

Every interview ends with one written line from the interviewer, not a conversation in the corridor: if not this seat, which of the four needs would this person move, and what is the evidence. One sentence. It takes thirty seconds and it is the only record that survives the funnel.

A live cross-need pool

Any candidate declined for one need is routed, with that line attached, to whoever owns the other open needs. Most applicant tracking systems already support this and almost nobody configures it, because the workflow was designed around filling a requisition rather than around finding the fit. The owner of each need reviews the pool weekly. That is the entire mechanism.

Interview against the needs, not the title

Ask which of Growth, Efficiency, Agility, or Resilience this person moves, and how they know. That is a structured question set applied identically to every candidate, which is also the format with the strongest evidence behind it: structured interviews reach an operational validity of about .51 against .38 for the unstructured conversation most processes actually run. Interviewing against needs rather than titles improves the prediction and surfaces the second door at the same time. The full validity argument is here.

Pay the Contribution, Not the Label

If levels are defined by the scope of the need a person can own, compensation has to follow the same logic, or the title quietly becomes the pay lever again and everything above unwinds.

Title-based pay has a specific pathology, and every operator recognises it: when you want to pay someone more, the only available instrument is a bigger title. So titles inflate, a hierarchy nobody designed appears on the chart, and within two years the org chart has stopped describing how the work actually flows. The company did not decide to build that structure. It bought it, one raise at a time.

Two axes track contribution better than any label does.

AxisThe questionWhy it tracks value
Scope of judgment How reversible are this person's decisions, and how wide is the blast radius when one is wrong? A person whose calls are hard to undo and affect several teams is carrying more of the company than one whose work is contained and reversible, whatever either is called
Scarcity of the capability How hard would this be to replace, in this market, this quarter? It is the honest half of the market rate, and it moves. Pretending it does not is how companies lose people they thought were paid fairly

Title then becomes what it should have been all along: a communication device for people outside the company, on a CV and in a customer meeting. It stops being the mechanism by which someone gets paid more, which means it stops distorting the structure.

The practical test that a company has made this switch: can two people hold the same title at materially different pay, and can both of them explain why without anyone becoming resentful? If the answer is no, pay is still tracking the label.

One caution before implementing this. Israel's Equal Pay Law requires equal pay for equal or comparable work, and equivalent duties exist in most jurisdictions. A contribution-based system is legitimate and defensible, but only if the axes are written down, applied consistently, and documented per decision. Applied informally it becomes a machine for producing pay gaps nobody can explain afterwards, which is both a legal exposure and the fastest way to lose the trust the system was meant to build. Write the framework before you use it, and have someone qualified review it.

One Scoreboard Both Sides Share

A GEAR org has two kinds of people in constant contact: the ones who plan (the need-owners setting direction) and the ones who execute (the pods shipping the work). The single thing that keeps them collaborating rather than drifting apart is a shared scoreboard of the correct KPIs. When the metric is right, both sides pull on the same rope. When the metric is wrong, planners optimize one thing, executors optimize another, and the gap between them widens even as everyone hits their numbers.

Where planners and executors meet

The scoreboard is only as good as the KPIs on it. A metric that everyone watches but that has no real link to the outcome will actively pull the two sides apart. That is the failure I unpack in The KPI Trap: when the measurement stack itself becomes the risk. Pick two or three KPIs per need that genuinely move the outcome, put them where both planners and executors read them, and the collaboration takes care of itself.

Jay Galbraith's Star Model makes the same point at the level of the whole operating model: strategy, structure, processes, rewards, and people have to be aligned with each other. Change the structure but leave the rewards and the metrics pointing the old way, and behavior barely moves. The scoreboard is how you keep the levers coherent.

Take Ownership: The Rollout

GEAR is meant to be run by the operator, not handed to a consultant and forgotten. Here is the sequence to own it yourself.

  1. 01

    Name the four needs and give each one owner

    Write Growth, Efficiency, Agility, Resilience on the wall and assign one accountable person to each, single-threaded, not a committee. Amazon single-threaded leader; Bain decision effectiveness.

  2. 02

    Draw pods around value streams, not functions

    Form small, cross-functional, autonomous teams aligned to a flow of value, sized so no team is too large to feed with two pizzas. Team Topologies stream-aligned teams; DORA loosely-coupled teams.

  3. 03

    De-conflict the seats

    Find the contradiction roles, then re-scope, pair, or add tooling before you ever split. Recruit for one clear mind, not a unicorn. Cagan empowered product teams; see The Unicorn Trap.

  4. 04

    Set decision rights so speed is the default

    Write down who decides what. The owner decides within guardrails and escalates only when a call crosses two needs. Bain decision roles; McKinsey rapid decision cycles.

  5. 05

    Build one scoreboard both sides share

    Two or three correct KPIs per need, in one place planners and executors both read. Verify each metric actually moves the outcome. See The KPI Trap; Galbraith Star Model.

  6. 06

    Run it on a six-week loop

    Ship, measure on the scoreboard, learn, adjust the design. Structure is a product you iterate, not a chart you freeze once and defend. Galbraith: keep the levers aligned as strategy moves.

Where GEAR Doesn't Fit

GEAR is an operating overlay, not a universal law, and applying it blindly causes its own damage. Below roughly ten people you do not need four owners; the founder holds all four, and the job is simply to name them as the doubling approaches. Splitting roles is never free, so a company that shatters every seat into narrow specialisms trades one kind of slowness for another. And in regulated or safety-critical work, some decisions should be slow and controlled; guardrails have to scale with risk, not shrink for speed. Used well, GEAR keeps the structure honest about what the business needs. Used dogmatically, it is just another chart.

Sources

  • Marcia Blenko, Michael Mankins, Paul Rogers, Decide & Deliver (Bain & Company). ~800 companies; 95% correlation between decision effectiveness and top-tier financial performance. bain.com
  • McKinsey & Company, The Five Trademarks of Agile Organizations. mckinsey.com
  • Matthew Skelton & Manuel Pais, Team Topologies - stream-aligned teams and team cognitive load. teamtopologies.com
  • Melvin Conway, How Do Committees Invent? (1967) - Conway's Law. melconway.com
  • Amazon / AWS, Two-Pizza Teams and the Single-Threaded Leader. aws.amazon.com
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate / DORA - loosely coupled autonomous teams predict delivery performance. dora.dev
  • Marty Cagan, Empowered (Silicon Valley Product Group) - empowered product teams. svpg.com
  • Jay R. Galbraith, The Star Model - align strategy, structure, processes, rewards, people. jaygalbraith.com
  • Ichak Adizes, The PAEI Model - no single manager holds all four capabilities. mindtools.com
  • Meredith Belbin, Team Roles - a team performs on a balance of nine roles. belbin.com
  • Geoff Smart & Randy Street, Who: The A Method for Hiring - the scorecard (mission, measurable outcomes, competencies), not a job description. geoffsmart.com
  • Haier's RenDanHeYi model - roughly 4,000 microenterprises organized around user needs, with decision, hiring, and profit rights at the front line (McKinsey interview with Zhang Ruimin). mckinsey.com
  • Dual-track career ladders (Microsoft's SDE I to Distinguished Engineer; Google's Principal Engineer paid like a Director) - advance as an owner without becoming a manager. Ken Norton
  • Reed Hastings & Erin Meyer, No Rules Rules (Netflix) - hire for the problem, pay top of market for the capability.
  • The People Operating System - the people layer underneath GEAR: how the HR function runs as an enabling team across hiring, onboarding, leveling, performance, recognition, and exits.
  • The Unicorn Trap - the deep dive on why some roles are unfillable (the psychology of planners vs executors) and how to split, pair, or scope them. GEAR's role section in one essay.
  • The KPI Trap - why the wrong metric on the shared scoreboard pulls planners and executors apart, and how to choose KPIs that hold.
  • The Expanding PM - how the Product Manager role keeps absorbing work, and why that makes it so hard to staff in one person.
  • The 10x Rule - why the structural gaps GEAR catches get roughly 10x more expensive to fix after a growth event than before it.
May Mor
About the author

May Mor

Efficiency Leader. M.Sc in AI, former Technical PM at a digital bank, where I built the onboarding that scaled an R&D team from 30 to 150 developers, and an AI-native adtech company. Currently running organizational reviews across regulated and operationally complex industries, and advising early-stage startups as consultant and board member. I help operators align their people, systems, and processes so growth scales the business instead of breaking it. Full bio →

If your org chart is drawn by title and the results are showing it, here is where to start:
Scale Readiness Assessment Scoped to your budget and timeline - a needs-first review of your people, processes, and technology
Book a 30-min intro call Talk through where your structure is slowing the business down
Startup Consulting Designing the operating model right from the start
Is your structure slowing the business down? Free 30-min call →
Book a call