Ask a manager to grow their team and most reach for a course. It feels responsible. There's a budget line, a calendar invite, a certificate at the end. But when researchers asked successful executives where they had actually learned to lead, almost none of it traced back to a classroom. Capability is mostly a design problem, and the main lever sits on your own desk: the work you hand out, and how you back people up once they have it.

The quick version

  • People grow mostly by doing hard, real work, not by being trained. Plan capability the way you plan the workload.
  • The move is the stretch assignment: a task one size too big, given on purpose, with support attached.
  • Feedback helps capability, but roughly a third of the time it makes performance worse. How you give it matters more than that you give it.
  • Protect time to learn. People can't improve and perform flat-out in the same hour.

The idea in depth

Capability is your team's ability to do tomorrow's work, not just today's. A high-performing team and a high-capability team aren't the same thing. The first delivers now. The second can absorb a new problem, a bigger remit, or a stretch of your absence without falling over. The research is encouraging on one front, capability really is buildable on the job, and uncomfortable on another: the way most organisations reach for it first, formal training, is the weakest lever they have.

Experience is the teacher. Training is the footnote.

The most-cited evidence here comes from the Center for Creative Leadership. In The Lessons of Experience (Morgan McCall, Michael Lombardo and Ann Morrison, 1988), researchers asked successful executives where they had learned the lessons that mattered. The answer was overwhelmingly the job itself: challenging assignments, difficult bosses and colleagues, and hardships, far more than any course. That study later hardened into the rule of thumb you may have heard as 70-20-10: roughly 70% of development from doing the work, 20% from other people (feedback, watching good and bad examples), and 10% from formal training. Lombardo and Eichinger popularised those numbers in The Career Architect Development Planner (1996).

That flips the question. Development isn't a break from the work; it's a property of it. Before you book a course, ask what assignment would teach the same thing, and who this person could learn from inside the next month. If your only answer to "how is Sam developing?" is "Sam's booked on a workshop," the strongest 90% of your toolkit is sitting idle.

An honest limitation: the 70-20-10 split is a memorable heuristic, not a measured law of nature. It came from executives recalling their own careers, self-report, decades ago, in one population, and the precise ratios have never been independently validated. Treat it as a reminder that experience dominates, not as a budget formula. The number that matters is the one closest to 70: people grow by doing.

flowchart LR
    A(["Where leaders
actually learned"]) --> B(["~70%
Doing hard, real work"])
    A --> C(["~20%
People: feedback & examples"])
    A --> D(["~10%
Formal training"])
    B --> E(["Capability"])
    C --> E
    D --> E
The 70-20-10 heuristic, after CCL's Lessons of Experience. A reminder, not a formula. Leaders Loop

Aim just past what they can already do

If experience is the teacher, the obvious question is: which experience? Not any task will do. Hand someone work they can already do in their sleep and they coast; hand them work far beyond reach and they drown. The sweet spot has a name in developmental psychology, Lev Vygotsky's zone of proximal development (in Mind in Society, 1978): the gap between what a person can do alone and what they can do with help from someone more capable. Learning happens in that gap. The support that gets them across it was later named scaffolding by Wood, Bruner and Ross (1976), guidance you add while it's needed and remove as it isn't. (Worth noting for accuracy: "scaffolding" was their term, not Vygotsky's.)

In practice, that means calibrating the stretch. A stretch assignment is a task deliberately set one size too big, enough that success is genuinely uncertain, not so big that failure is near-certain and expensive. Then you scaffold: heavy support up front, visibly pulled back as they find their feet. You're aiming to make yourself progressively unnecessary. Still as involved at week eight as you were at week one? The scaffolding never came down, and no capability transferred.

The caveat: stretch only develops people when the conditions are safe. Vygotsky's framing assumed help was on hand and the cost of error was a lesson, not a catastrophe. Stretch someone with no support, in a role where a mistake gets them publicly burned, and you don't build capability, you build fear. Your most capable people quietly start updating their CVs.

flowchart TD
    A(["Pick a real task
one size too big"]) --> B(["Set the goal &
the guard-rails"])
    B --> C(["Scaffold:
high support early"])
    C --> D(["Withdraw support
as they find footing"])
    D --> E(["They own it;
you debrief the lesson"])
    E --> F(["Capability transferred"])
A stretch assignment as a development cycle, support added, then deliberately removed. Leaders Loop

Feedback helps, but not the way most managers do it

The "20" in the heuristic is mostly feedback and proximity to good examples, and it's where well-meaning managers do the most accidental harm. The landmark study is Avraham Kluger and Angelo DeNisi's meta-analysis (Psychological Bulletin, 1996), pooling 607 effect sizes. On average, feedback improved performance, but in more than a third of cases it made performance worse. The pattern they found is the useful part: feedback that pushes attention to the self ("you're disappointing," "is this really your best?") tends to backfire, because the person spends their energy defending their ego instead of fixing the task. Feedback aimed at the task, specific, about the work, pointed at what to do next, is what lifts performance.

The fix is to keep feedback on the task and on the next step. Swap "this report was sloppy" for "the recommendation on page two isn't supported by the data on page five, walk me through your reasoning." The first is a verdict on the person. The second is a problem to solve together. Same standard, opposite effect on whether anyone gets better.

This is also why coaching skills matter more than feedback skills for development: a good coaching question makes the person do the thinking, which is the thing that actually builds the muscle.

A worked example

The figures below are illustrative, a composite scenario, not a measured case.

Priya runs a six-person analytics team. Her strongest analyst, Daniel, is excellent at the work but has never led anything. The default play is to send him on a "first-time managers" course next quarter. Instead, Priya designs the development into the work.

A new request lands: a quarterly board dashboard, roughly six weeks of effort, visible to executives, real stakes, recoverable if it wobbles. That's the stretch: bigger than anything Daniel has owned, but survivable. She gives him the brief and the guard-rails ("the board cares about three numbers; don't rebuild the data pipeline"), then scaffolds heavily at the start, they pair on the first stakeholder conversation, she reviews his plan, she's in the room but not running it. By week three she's down to a weekly check-in. By week five Daniel is fielding an executive's awkward question himself while Priya watches and says nothing.

When his first draft over-engineers the visuals, she resists "this is too busy." Instead: "If a director has nine seconds on this slide, what's the one thing they must leave with, and does the chart make that unmissable?" Daniel re-cuts it himself. The dashboard ships. More importantly, Priya now has someone who can own executive-facing work, capability she didn't have six weeks earlier, built for the price of attention rather than a training budget. The course would have taught Daniel about leading; the assignment taught him to lead.

Frequently asked questions

Isn't a stretch assignment just dumping work on people?

The difference is intent and support. Dumping is handing over work you don't want, with no scaffolding and no debrief. A stretch assignment is chosen because it grows a specific capability, comes with help that's deliberately withdrawn over time, and ends with a conversation about what was learned. If you couldn't name the capability before you handed it over, it's a dump, not development.

How do I build capability when I have no training budget?

You've already got the strongest lever, the 90% that isn't formal training is free. Rotate who runs the meeting, who owns the client, who presents to your boss. Pair a less-experienced person with a stronger one on a real task. The cost of on-the-job development is your attention and a tolerance for slightly slower, slightly rougher first attempts, not money.

What if my best people are too busy delivering to develop?

That's the central tension, and it's real. People can't improve and perform flat-out simultaneously, Eduardo Briceño's "learning zone vs. performance zone" framing (his 2016 TED talk) is the clearest version of it. You have to protect a little slack: a project where it's safe to be slower because the point is to learn. A team that is always 100% in the performance zone is, by definition, never building capability.

How do I know it's working?

Watch your own involvement, not their output. Capability is transferring when you can withdraw support without the work falling over, when the weekly review gets shorter, when problems get solved before they reach you, when you can take leave and return to find nothing on fire. If the work only holds up while you hover, you've built dependence, not capability.

Does this replace formal training entirely?

No, the 10% is real and sometimes essential, especially for genuinely new technical skills, compliance, or a body of knowledge nobody on the team holds. The error isn't using training; it's using it first and alone. Training lands best as a deliberate input to an assignment someone is about to take on, not as a substitute for the assignment.

Related in the Toolkit

Where to go next