Growing people: skill matrix, stretch, delegation, feedback

What it is

Growing people is the deliberate part of a lead's job that most leads do accidentally: assigning work to close named gaps rather than to whoever is free, sizing stretch so it is survivable, transferring authority one rung at a time, and giving feedback specific enough to act on.

Four instruments, each with a concrete form:

SKILL MATRIX       each person x each competency, with a current
                   level and a target. Turns "who's available?" into
                   "who needs this?"

STRETCH RATIO      roughly 70% known / 30% new. More than that and
                   you have set up a failure and called it growth.

DELEGATION LADDER  do it -> do it and tell me -> propose then do ->
                   decide and inform -> own it entirely.
                   Move one rung at a time, and SAY which rung.

SBI FEEDBACK       Situation, Behaviour, Impact. Specific, timely,
                   behavioural. Praise publicly, correct privately.

What this is confused with: career conversations. A quarterly conversation about ambitions is not development; the work someone does every day is the development. A lead who has a great career chat and then assigns the same person the same kind of task for six months has done nothing.

Also confused: delegation and abdication. Handing over a task without naming the rung means the engineer does not know whether to ask before acting, and the lead does not know whether to expect a proposal. Both then experience the other as unreasonable.

The problem it solves

Assignment by availability is the default, and it produces a team that is individually competent and collectively fragile.

Six months of assigning work to whoever is free:

  Alex   has done every streaming task, because Alex is fastest
         at them
  Sam    has done every frontend task, for the same reason
  Priya  has done whatever was left

Consequences:
  - Alex is the single point of failure for streaming, cannot take
    a holiday without risk, and is bored
  - Sam has not touched a backend service in a year and is now
    unpromotable at a company that expects breadth at the next
    level
  - Priya's growth is a function of what nobody else wanted
  - the bus factor on two systems is 1

Every one of those is a lead's decision that was never made deliberately.

And the feedback failure, which is the other half:

"You're doing great, keep it up."         -> unactionable
"Your communication could be better."     -> unactionable and
                                             slightly hurtful
"You need to show more ownership."        -> the single most
                                             common unactionable
                                             piece of feedback in
                                             engineering

The engineer cannot act on any of them, so nothing changes, so
the same feedback appears at the next review, by which point it
has become a rating.

Mechanics

The skill matrix

Competencies that matter for engineers (adjust to your ladder):
  domain knowledge      the product and its constraints
  systems design        decomposition, tradeoffs, failure modes
  code quality          readability, testing, maintainability
  operational           debugging production, on-call competence
  communication         writing, presenting, disagreeing well
  ownership             follow-through without prompting
  mentoring             growing others

Levels: 1 needs help, 2 does it, 3 does it well, 4 teaches it.

                domain  design  code  ops  comms  own  mentor
  Alex             4       3      3     4     2     3     2
  Sam              2       2      4     1     3     3     1
  Priya            3       2      3     2     4     2     2
  Dev (new)        1       3      3     2     3     2     3
  Jo               3       4      3     3     3     4     3

Reading the matrix is the point, and three readings come out of it immediately:

1. RISK. Alex is the only 4 in ops, and the only 4 in domain.
   Two single points of failure in one person.
   -> the next two production incidents get a deliberate
      second responder, and Alex's job is to narrate.

2. INDIVIDUAL GAPS. Sam is a 1 in ops and a 2 in domain, which
   is exactly what will block them at the next level.
   -> Sam takes the next on-call shift paired, and owns the next
      piece of work that requires understanding the domain
      rather than the code.

3. UNDERUSED STRENGTH. Dev is a 3 in mentoring and brand new,
   which is unusual and worth using: Dev onboards the next hire.
   Being trusted with that in month two is also the highest-
   value retention move available for a strong new joiner.

Keep it private to the lead. A shared matrix becomes a ranking, and people optimise for the number. Its purpose is to make assignment deliberate, not to publish an assessment.

Update it after every substantial piece of work, not quarterly, because the cost of maintaining it is what determines whether it survives.

The stretch ratio

An assignment should be roughly 70% within the person's current
capability and 30% new.

  90/10   comfortable, and it is not growth. Fine sometimes; a
          diet of it is why strong engineers leave.
  70/30   the target. Hard enough to learn, familiar enough to
          finish.
  50/50   possible with heavy support, and only for one thing at
          a time.
  30/70   a setup. The person will either fail publicly or be
          rescued, and both damage them.

The dimension of the stretch matters as much as the size. Stretching someone on technical complexity, on scope and ambiguity, and on visibility at the same time is three stretches, not one.

A new senior engineer's first stretch:

  BAD:  lead the cross-team migration, present to the VP monthly,
        and it uses a technology they have not touched.
        Three simultaneous stretches. This is a 30/70.

  GOOD: lead the cross-team migration (new: scope and
        coordination) in a technology they know well (familiar),
        with you presenting to the VP for the first two months
        and them taking it over in month three (staged).
        One stretch at a time, sequenced.

Naming which dimension is being stretched, out loud, to the person, is what turns an assignment into development. "This is a scope stretch, not a technical one; the technology is deliberately familiar so that the coordination is the hard part" tells someone what to be good at.

The delegation ladder

1. DO IT              I tell you exactly what to do.
2. DO IT AND TELL ME  You execute, and report back after.
3. PROPOSE, THEN DO   You bring me the plan; once I agree, you go.
4. DECIDE AND INFORM  You decide and act, then tell me what you did.
5. OWN IT ENTIRELY    You own the outcome. I hear about it in your
                      updates, not as an approval step.

Two rules, and both are commonly broken:

RULE 1: MOVE ONE RUNG AT A TIME.
  Jumping someone from 2 to 5 is not empowerment, it is
  abandonment, and when it goes wrong the lesson they learn is
  that they were not ready, which is not the lesson.

RULE 2: SAY WHICH RUNG, EXPLICITLY, PER AREA.
  "You own the caching layer entirely. On the API contract,
   bring me the proposal first, because it affects three other
   teams."
  Same person, two rungs, two areas. Without saying it, the
  engineer guesses, and half the friction between leads and
  seniors is a rung mismatch nobody named.

The most common failure is the lead who thinks they are at rung 4 and behaves like rung 3.

Lead says:  "You own this, go."
Lead then:  reviews every PR in detail, asks to see the design
            before it ships, and reverses a decision.

The engineer experiences this as being told they own something
and then not owning it, which is worse than being told rung 3
honestly. If you are going to review the design, say so: that
is rung 3, and rung 3 is a legitimate place to be.

Moving someone up is a decision with a visible marker, and saying it makes the promotion of trust real: "Last quarter you brought me proposals on the ingest work and I agreed with all of them, so from now on that area is decide-and-inform."

SBI feedback

SITUATION   when and where, specifically
BEHAVIOUR   what you observed, observable and not inferred
IMPACT      what it caused, on people or on outcomes

Vague:  "You need to communicate better."

SBI:    "In Tuesday's design review [S], when Priya raised the
         backfill concern you moved to the next slide without
         responding [B]. She stopped contributing for the rest of
         the meeting, and the backfill risk we hit last week was
         the thing she was raising [I]."

What makes it work is that behaviour is observable and therefore arguable. Someone can disagree that they moved past the concern, and that disagreement is a useful conversation. Nobody can productively disagree with "you need to communicate better."

The same structure for positive feedback, and it is under-used:

"In the incident on Thursday [S], you posted a status update
 every 15 minutes even though there was nothing new to say [B].
 That is why nobody from support interrupted the responders, and
 it is the reason the VP did not join the call [I]."

That tells them exactly which behaviour to repeat. "Great job on
the incident" does not.

Timing and setting:

TIMELY     within days. Feedback about something a month ago is
           about a memory, and the person has already repeated
           the behaviour several times without correction.
PRIVATE
  for correction    always
PUBLIC
  for praise        usually, and check: some people find public
                    praise uncomfortable, and it is worth asking
                    once rather than assuming.

One-to-ones

THEIR AGENDA FIRST. If you have a topic, it goes after theirs.
NOT A STATUS MEETING. Status is available in the tracker. If your
  1:1s are status updates, you have converted the only private
  channel you have into a report.
CAREER EVERY FOURTH ONE. Explicitly scheduled, so it does not get
  crowded out by whatever is urgent.
NOTES ARE SHARED. A running doc both people can edit, with
  actions. It makes the thread visible over months, which is what
  makes growth conversations concrete.
CANCEL RARELY. A cancelled 1:1 says the relationship is the
  flexible item. If you must, reschedule rather than skip.

Growth plans against the next level's rubric

Not: "get better at design."
But: mapped to the actual next-level rubric, with named artifacts
     as evidence.

  Rubric line (Staff): "drives technical direction beyond their
  own team"
  Current evidence: none
  Plan: own the cross-team schema-evolution proposal, write the
        RFC, run the review with the three consuming teams
  Artifact by end of quarter: the RFC, the review notes, and the
        adoption decision
  Who else needs to see it: the two staff engineers who will be
        in the calibration room

The last line is the one leads omit, and it is the difference
between doing the work and being promoted for it.

Adjectives do not survive a calibration room; artifacts do (see promotions and the calibration room).

A worked example: a team where nobody was growing

A team of five, stable for eighteen months, no attrition and no promotions. The lead's read was that the team was "solid." Two engineers had privately started interviewing elsewhere.

Building the matrix surfaced the shape of the problem:

                domain  design  code  ops  comms  own  mentor
  Alex             4       3      3     4     2     3     2
  Sam              2       2      4     1     3     3     1
  Priya            3       2      3     2     4     2     2
  Jo               3       4      3     3     3     4     3
  Dev              1       3      3     2     3     2     3

Assignment history, last 2 quarters, by system:
  streaming:  Alex 11 items, everyone else 2 combined
  API:        Sam 9, Jo 4
  data:       Jo 8, Priya 3
  frontend:   Sam 7, Priya 1

Three findings:

1. Alex owned streaming with a bus factor of 1, was a 2 in
   communication, and was one of the two interviewing. Their
   stated reason, in the eventual conversation: "I've been doing
   the same thing for two years and nobody has asked me to do
   anything else."

2. Sam was a 4 in code and a 1 in ops, and had been passed over
   in the last promotion cycle for "insufficient operational
   maturity", which nobody had told Sam in those words.

3. Priya was the strongest communicator on the team and had been
   given the leftovers, which is how a 4 in communication ends up
   with a 2 in ownership.

The reassignment, done deliberately over one quarter:

ALEX: moved off streaming as primary. Given the API rewrite
      (new domain, familiar difficulty: a technical stretch that
      is 70/30) AND the job of bringing Priya to a 3 in
      streaming. The mentoring assignment was explicit and
      framed as the growth: "your next level needs evidence you
      can grow others, and streaming is where you can."
      Delegation rung: 5 on streaming architecture, 3 on the API
      rewrite because it touches two other teams.

SAM:  next on-call shift paired with Jo, then two solo shifts,
      then owning the alert review. Framed with the actual
      reason: "the calibration feedback was operational
      maturity, and here is the specific evidence we need by
      the next cycle."
      Delegation rung: 2 on on-call initially, moving to 4.

PRIYA: given the cross-team migration coordination, which is a
      scope stretch in a familiar technology. Deliberately not
      also a technical stretch.
      Delegation rung: 3, moving to 4 in the second month.

JO:   already a 4 in ownership and design, and the growth was
      lateral: took the technical-direction work for the
      quarter, wrote the schema-evolution RFC, ran the review
      with three consuming teams. Mapped explicitly to the staff
      rubric line about influence beyond their own team.

DEV:  onboarded the new hire in month two, using the 3 in
      mentoring. Cost: about a day a week for six weeks.

SBI feedback, introduced at the same time, with one specific correction:

To Alex, about the communication 2:

  "In the incident review on the 14th [S], when the platform
   team asked why we hadn't caught it in the canary, you said
   'the canary is useless for this' and moved on [B]. Two things
   happened: the platform lead brought it up with me afterwards
   as 'your team thinks our tooling is useless', and the actual
   point you were making, which was right, didn't land [I]."

Alex's response was to disagree with the characterisation, and
the resulting 20-minute conversation was the useful part. The
behaviour changed within a month, which "you need to work on
your communication" had not achieved in two prior reviews.

Results after two quarters:

                                before      after
bus factor on streaming              1           2
bus factor on data                   1           2
promotions                           0    2 (Sam, Jo)
regretted attrition             2 at risk       0
matrix cells at level 1              3           1
matrix cells at level 4              6          10
items assigned to the person
  who most needed the skill        n/a    tracked; 14 of 22

Alex, six months later, had a 3 in communication, had grown
Priya to a 3 in streaming, and was in the following promotion
cycle with mentoring evidence they had not previously had.

Nobody was hired and nobody worked more hours. The change was that assignment stopped being a function of availability.

One thing that got worse, and it was predictable:

Throughput fell about 15% in the first six weeks.

Alex on the API rewrite was slower than Sam would have been.
Priya on streaming needed Alex's time. Sam's paired on-call
shifts consumed two people.

The lead flagged this in advance to the PM with a number and a
duration: "expect roughly 15% less for six weeks; this is the
cost of removing two bus factors and getting two people
promotable."

It recovered by week nine and exceeded the previous level by
week fourteen, because four people could now do work that
previously only one could.

Announcing the dip in advance with a number is what made it a plan rather than a slump, and it is the same move as pricing any other investment.

Production evidence

Situation-Behaviour-Impact is a feedback model developed and taught by the Center for Creative Leadership, and its documented rationale is precisely that behaviour is observable and therefore discussable, where inference and judgment are not.

The delegation ladder appears in several forms, notably in the "levels of delegation" used in management-training literature and in Jurgen Appelo's Delegation Poker; the shared claim across versions is that the failure is ambiguity about the level rather than the choice of level.

Google's Project Oxygen identified "is a good coach" and "helps with career development" among the behaviours most associated with effective managers, with the specific finding that regular, specific, actionable feedback separated the highest-rated managers from the rest.

Published engineering career ladders (Rent the Runway's, CircleCI's, Dropbox's, and the collection at levels.fyi and progression.fyi) are the concrete form of "map the growth plan to the next level's rubric," and their common structure, competencies with observable evidence, is what makes artifact-based plans possible.

Bus factor as an explicit risk measurement is standard practice in operational reviews, and pairing and deliberate rotation are the documented remedies; the connection to assignment policy, that a bus factor of one is a consequence of assigning by speed, is the part usually left implicit.

Research on stretch assignments in leadership development consistently finds that challenging assignments are the dominant developmental experience, with the caveat that support must scale with the stretch, which is the empirical basis for the 70/30 sizing rather than a larger one.

The debate

Should the skill matrix be shared with the team? Shared per-person, in the one-to-one, yes. Shared as a grid, no, because it becomes a ranking and people optimise for their row. The counter-argument, that transparency builds trust, is real and is better served by being explicit with each person about their own gaps and the plan, which is the part they can act on.

Is 70/30 too conservative? For a person with strong support and a low-stakes outcome, 50/50 works. The argument for 70/30 as the default is that the failure mode is asymmetric: an under-stretched engineer is bored and can be stretched next quarter, while an over-stretched one fails publicly and often concludes they are not capable, which takes far longer to undo.

Does assigning for growth cost delivery? Yes, in the short term, measurably. The honest number in one case was about 15 percent for six weeks, and the argument that carries it is that the alternative was two bus factors of one and two engineers interviewing elsewhere. Announce the dip with a number and a duration, because an unannounced dip is indistinguishable from a slump.

Is SBI formulaic? It reads as formulaic when used for trivial things, and the fix is to use it for feedback that matters rather than to abandon the structure. The value is that it forces you to identify a specific observable behaviour, and if you cannot, the feedback was not ready to give.

Should a lead delegate work they are better at? Usually yes, and this is the hardest instinct to override. The lead's throughput is not the team's constraint; the team's capability is, and every task a lead keeps because they are faster at it is a capability that stays at a bus factor of one. The exception is a genuine deadline emergency, and the follow-up transfer is what stops it becoming permanent.

Are career conversations useful at all? Yes, as calibration, and they are not development. Development happens in the assignments between the conversations, and a lead who has a great quarterly career chat and then assigns by availability has run a pleasant meeting.

Follow-up Q&A

"How do you decide who gets which piece of work?"

From a skill matrix rather than from who is free. Each person against each competency, with a current level and a target, updated after every substantial piece of work. Three readings fall out immediately: risk, where a competency has exactly one strong person, which is a bus factor of one you created; individual gaps, where the thing blocking someone at the next level is visible as a low cell; and underused strength, where someone is strong at something they never get to do. Then assignment becomes "who needs this" rather than "who is available," and you say out loud which dimension is being stretched.

"What is the right size for a stretch assignment?"

About 70 percent within current capability and 30 percent new, and the dimension matters as much as the size. Technical complexity, scope and ambiguity, and visibility are three separate stretches, and combining them is how a well-intentioned assignment becomes a setup. The good version of a first leadership stretch is new scope in a familiar technology with the lead handling the executive exposure for the first two months. The failure mode is asymmetric: an under-stretched engineer can be stretched next quarter, while an over-stretched one often concludes they are not capable, and that takes far longer to undo.

"What is the delegation ladder and where does it go wrong?"

Do it; do it and tell me; propose then do; decide and inform; own it entirely. Two rules. Move one rung at a time, because jumping from rung two to rung five is abandonment rather than empowerment. And say which rung, explicitly and per area, because the same person can be at rung five on one system and rung three on an API contract that affects three teams. The most common failure is a lead who says "you own this" and then behaves like rung three, reviewing every design and reversing decisions. Being told rung three honestly is better than being told rung five and experiencing rung three.

"What does actionable feedback look like?"

Situation, behaviour, impact. Instead of "you need to communicate better," say: in Tuesday's design review, when Priya raised the backfill concern you moved to the next slide without responding; she stopped contributing for the rest of the meeting, and the backfill risk we hit last week was what she was raising. Behaviour is observable, so it is arguable, and the disagreement is a useful conversation. Nobody can productively disagree with "communicate better," which is why it appears in three consecutive reviews and then becomes a rating. Use the same structure for praise, because "great job on the incident" does not tell anyone which behaviour to repeat.

"How do you write a growth plan that survives a promotion committee?"

Map it to the actual next-level rubric line, name the artifact that will be the evidence, and name who needs to see it. Not "get better at design" but: the rubric says drives technical direction beyond their own team, current evidence is none, the plan is to own the cross-team schema-evolution proposal and run the review, the artifact is the RFC and the adoption decision, and the two staff engineers who will be in the calibration room need to have seen it. The last part is what leads omit, and it is the difference between doing the work and being promoted for it, because adjectives do not survive a calibration room and artifacts do.

"What does assigning for growth cost?"

Short-term throughput, measurably. In one case about 15 percent for six weeks, because the person learning was slower than the person who already knew, and pairing consumed two people at once. It recovered by week nine and exceeded the previous level by week fourteen, since four people could then do work only one could before. The move that makes it a plan rather than a slump is announcing the dip in advance with a number and a duration, and naming what it buys: in that case removing two bus factors of one and making two people promotable, with two engineers who had been interviewing elsewhere staying.

Common misconceptions

"Assign work to whoever is free." That is how you get a bus factor of one on every system and a team where nobody's capabilities changed in two years.

"A career conversation is development." The assignments between the conversations are the development. The conversation is calibration.

"You own this" is delegation. Without naming the rung, the engineer guesses whether to ask first, and half the friction between leads and seniors is an unnamed rung mismatch.

"Feedback should be gentle." It should be specific. A vague soft signal followed later by a hard decision is the cruelest version, and it is what "you need to show more ownership" turns into at review time.

"Bigger stretches grow people faster." Beyond about 70/30 the person either fails publicly or is rescued, and both teach the wrong lesson.

"A lead should keep the work they are best at." The lead's throughput is not the constraint. Every task kept because you are faster is a capability that stays at a bus factor of one.

Interview delivery note

Say this verbatim: "I assign from a skill matrix rather than by who is free, because assigning by availability is how you end up with a bus factor of one on every system and a team whose capabilities have not changed in two years. And I name which rung of the delegation ladder someone is on, per area, because most friction between a lead and a senior engineer is an unnamed rung mismatch." Two mechanisms and the failure each prevents.

The senior-versus-staff separator is pricing the growth investment out loud. A senior lead assigns stretch work. A staff lead tells the product partner in advance to expect roughly 15 percent less throughput for six weeks, says what it buys, removing two bus factors and making two people promotable, and reports when it recovers. Announcing the dip converts an unexplained slump into an investment with a return date, and it is the same move as pricing any other technical investment.

The second signal is naming which dimension of a stretch is which. Saying "this is a scope stretch, not a technical one, so the technology is deliberately familiar and the coordination is the hard part" tells the engineer what to be good at, and it demonstrates that you know technical complexity, scope and visibility are three separate stretches that should not be combined.

The Staff & Team Lead Interview Reference