This article expands on the “Team and Growth” thread in Management Retrospective.
When a team gets busy, development is easily pushed into “later”: wait until the project wraps up, wait until there’s time for a sharing session, wait until newcomers are familiar before assigning harder work. But if development only happens in these gaps, it usually doesn’t really happen.
Because team capability is not the graduation result of a course. It shows up in the day-to-day judgment, collaboration, and delivery: whether problems are stated clearly, whether options have had their trade-offs compared, whether risks can surface in time, and whether experience can be picked up by those who come later. Only by doing these things well and consistently does the team become more reliable than the last time.
I prefer to understand development as a system that lets capability compound: let people take on real responsibility slightly above their current level, receive feedback while getting proper support; then leave the transferable judgment and methods to the team.
The Object of Development Is Not a Knowledge Gap
Training is good at solving “what you don’t yet know”: how a tool is used, how a process runs, what basic concepts a domain has. This is certainly useful, especially when first exposed to a new environment.
But many growth bottlenecks do not come from knowledge gaps. A person may know how to write a proposal yet still can’t judge which problem is worth solving first; may know how to push a task forward yet still can’t redo the trade-offs when constraints change; may already be able to finish work independently yet still lack the ability to get collaborators to understand, participate, and benefit.
These abilities are hard to acquire just by listening. They require entering real situations and practicing repeatedly amid outcomes, disagreements, and uncertainty. So the first thing development has to answer is not “which course still needs to be made up,” but:
- On which kinds of problems is this person already reliable?
- Which stretch of responsibility is most worth expanding next?
- Where will they get stuck, and what support can they receive?
- After it’s done, how do we know they didn’t just finish a task but really learned?
Only by answering these questions clearly does development turn from an abstract expectation into work that can be done together.
A Good Challenge Only Steps Out a Little
Growth requires leaving the comfort zone, but “harder” doesn’t naturally equal “more growth.” When responsibility far exceeds current ability, people often can only rely on firefighting, copying others’ answers, or barely finishing through overexertion; when responsibility stays below ability for a long time, they fall into repetition and burnout.
A more effective arrangement is to make the challenge a bit bigger than current ability, but not so big that support is lost. For someone who can just now finish tasks independently, have them own a small project that includes upstream/downstream coordination; for someone who can already complete proposals, ask them to compare alternative paths and explain what not to do; for someone running a direction, have them organize a cross-role trade-off and review the result.
This “small step” is not a fixed task size but a new kind of responsibility. It should have three things at once:
- Clear outcome: know what counts as done, and know which goal it serves;
- Controllable boundaries: decision rights, time, and collaboration scope match the responsibility;
- Support available: at key points someone can provide context, challenge, and feedback, rather than taking over only at the end.
Pressure without boundaries is not development. When handing over new responsibility, also hand over the necessary information, the paths to ask for help, and room to make reasonable mistakes.
An Example of “Just Hard Enough”
Suppose an engineer can already reliably complete well-defined requirements. The team next wants to rework a submission process that keeps getting reworked: it involves pages, interfaces, and operations configuration, and the problem is not in any one piece of code but in the fact that several parties understand “what counts as done” differently.
Giving him sole responsibility for the whole rework may be too big a span; having him only change one button provides no new practice. A more fitting arrangement is: have him get the most common path working end-to-end and lead a thirty-minute alignment. Before the meeting he needs to write down the actions the user wants to complete, the current chain, and the two questions not yet confirmed; after the meeting, record who provides what input, when it’s confirmed, and how it’s accepted. A more experienced peer only reviews the question list together before the meeting and gives feedback afterward on risks that were missed.
The result of this exercise is not just “the rework ships.” If the next time he faces a cross-role task he can proactively confirm inputs, outputs, and acceptance criteria first, that means the ability has transferred; if he still only stares at his own implementation, then the next round should keep practicing problem definition rather than immediately enlarging the project.
Feedback Should Center on Behavior and Judgment
“Nice work” and “you need to be more proactive” rarely help people change, because they don’t point out what to do next time. Better feedback should return to observable behavior and the judgment process.
For example, instead of just saying “the project wasn’t pushed forward well enough,” look together at: whether the goal was confirmed at the start; whether the most uncertain dependency was validated in advance; whether the impact and options were explained when a risk appeared; whether scope, owner, and next steps were re-aligned after a change.
This kind of feedback has two values. First, it lets the person know where the problem is, rather than turning one result directly into an ability label. Second, it gradually gives the team a shared language: what gets discussed is facts, assumptions, trade-offs, and actions, rather than who tries harder or who looks more like a “good employee.”
An effective development loop can be very light: clarify beforehand what to practice this time, ask questions at key moments during the process rather than answering for them, and review afterward which judgments worked, which signals were ignored, and how to try next time. What matters is not how complete the form is, but whether the loop keeps happening.
Turning One Mistake into the Next Capability
For example, a member’s feature is found only at the last stage to have a dependency condition that doesn’t hold, and delivery has to be postponed. If the review stops at “communicate better next time,” almost nothing changes. A more concrete discussion returns to the process: who first knew about that dependency? What assumptions were still unvalidated at the time? Why didn’t the progress sync list it as a risk? If the same situation happened again, what’s the latest point at which it should be validated, and what scope should be prepared to shrink if validation fails?
The point of such a review is not to find who caused the delay, but to let the person practice a repeatable move: write out the premises in the plan and set checkpoints for the most important premises. The manager should also check their own part—whether they gave enough background at the start, and whether they put the pressure to “finish on time” above “honestly exposing risks.”
One delay doesn’t automatically mean insufficient ability; the signal that needs continued handling is the same blind spot recurring without any new way of checking. Only by linking feedback to a concrete next action can the team truly learn from results.
Managers Should Shift from “Giving Answers” to “Designing Exercises”
More experienced people easily become the team’s shortcut. When a proposal is unclear they finish it themselves, when collaboration stalls they coordinate it themselves, when members come asking they hand over the conclusion directly. These practices can save the immediate situation, but they may also let the team permanently outsource its most critical judgment to a few people.
The harder and more valuable approach is to first judge what the other person actually lacks: background information, a way to break things down, decision authority, or an opportunity to articulate an idea clearly? Then give the matching support.
Sometimes you can directly add constraints; sometimes you should break down the problem together and then ask them to come back with two or three options; sometimes you need to decisively take over when the risk exceeds their responsibility. Development is not refusing to help, but not prematurely taking away an ability that could have grown on the other person.
Managers also need to lead by example. Teams imitate what is actually rewarded: if only the final result is seen, people will hide risks; if clear reviews, honest unknowns, and the effort of helping others are taken seriously, the team is more likely to form an open and reliable way of working.
“Not Answering for Them” Doesn’t Mean Standing By
When a member comes for help with “how do I do this proposal,” drawing out the complete design is usually fastest. A response with more development value can go in three steps: first ask what user or collaboration problem they want to solve; then ask about known constraints, paths already ruled out, and the risks they’re most worried about; finally agree that they’ll come back with one or two options to discuss. At this point the manager should still fill in the historical background they couldn’t possibly know, and should step in promptly when a risk would affect a wider scope.
If the options they bring back the next day are still immature, the discussion shouldn’t turn into “why haven’t you figured it out yet.” You can point out together: the problem definition is clear, but key dependencies weren’t estimated; or the options are listed thoroughly, but there’s no explanation of why one should be done first. This way the answer isn’t taken away, and the person isn’t left stuck alone in vague requirements. The quality of support isn’t about how little help is given, but whether, after the help, the person can judge more independently than before.
Turning Individual Experience into Team Assets
One person finishing a difficult piece of work doesn’t necessarily make the team stronger. If experience stays only in one person’s head, it easily disappears after members change or tasks switch. Real compounding comes from experience being understood, reused, and improved by others.
This doesn’t mean writing every process into heavy documentation. More practical distillations are often small: after a decision, leave behind the goal, constraints, and trade-offs; after an incident, note the earliest signal and the fix; after a stretch of collaboration, update the handoff boundaries; in a sharing session, make clear which practices apply and which should not be copied when the conditions aren’t present.
When these materials re-enter the next piece of work, the distillation completes its loop. New members don’t have to guess from zero, and more experienced people can put their energy into harder problems. Development is then no longer just one person’s extra effort, but part of how the team works.
The Value of Distillation Only Shows Up the Next Time
After a change is finished, the team can leave a record of under a page: what they wanted to improve; which approach they took and which alternatives they didn’t choose; what they observed after launch; and what needs re-judging when conditions change. Months later, when another member hits a similar problem, they don’t need to copy the old answer, but can first understand the constraints and validated assumptions of that time.
This is different from concentrating knowledge in some “repository.” Truly useful experience stays close to the decision scene: trade-offs left beside proposals, the earliest signal noted in incident records, interfaces and owners written clearly in collaboration notes. As long as the next person doing the work can take fewer detours or ask a better question because of it, the compounding has already happened.
Conclusion
Development is not pushing everyone toward one set of standards, much less dressing up unbounded demands as “growth.” It is a long-term commitment: respect where each person currently is, give them real responsibility that lets them step out a little, help them correct course with concrete feedback, and then let the valuable experience among it return to the team.
When a team can keep turning one completion into better judgment the next time, and turn individual experience into shared capability, capability begins to compound.