develop turning experience into capacity featured image

Develop: Turning Experience Into Capacity

Part of THREAD™, the operating lens inside the Minotaur Method™: six kinds of attention that complex work asks for. You enter where the work is actually stuck, not in a fixed order. This piece reads Develop.

Imagine a VP of People at a two-hundred-fifty-person professional services firm running her third annual learning and development review.

The slides look good. Course completion is up. Workshop attendance is high. The feedback scores are strong. She has been reporting these numbers for three years and they have always done the same thing.

What has not changed is the behavior under client pressure. The leaders who took the executive presence workshop in March still default to the same patterns when a Friday afternoon escalation lands. The teams that did the feedback training in June still avoid the difficult conversation when a project is sliding.

Her program is producing learning. It is not producing capacity. She’s starting to suspect those are different things.

She is right.

The THREAD™ operating lens names six kinds of attention, vantage points you re-enter as the work demands. Target sets aim. Horizon reads the field. Resource counts the means. Evaluate weighs the signal. Act produces the move. Develop is the vantage that asks what turns a hard-won read into repeatable capability, and it is the one most often skipped or misunderstood. It is the work of converting experience into structural capacity that holds under load, so the next pass starts further along.

Develop Is Integration, Not Content Delivery

Picture a craftsman teaching an apprentice.

He doesn’t hand her a textbook on the day she arrives. He shows her one task. She does it. She does it badly. He shows her again. She does it again, slightly less badly. After six months, she does the task without thinking about it. After two years, she does the task while teaching another apprentice. The knowledge has not been delivered. It has been integrated, slowly, into a body that can perform it under any condition.

That is what Develop does. It is the practice of turning a lesson into a mechanism that holds in the muscle of the team.

Training is a different thing. Training delivers content. People watch a workshop, take notes, get a certificate. The content has been delivered. Whether it has been integrated is a separate question, and most training programs don’t measure it because the integration takes a year and the workshop took an afternoon.

A leader who runs Develop does not measure the training. She measures what survives under load. Six months after the workshop, when a project is on fire and the team is tired, does the new behavior show up. If yes, integration happened. If no, the workshop was content delivery, and the team is performing exactly the same way they were before, with a slightly better vocabulary for it.

Develop Asks What Made the Last Win Possible

Watch a leader who runs Develop well. She isn’t looking at the team’s training calendar. She’s looking at the team’s recent wins, and asking one specific question.

What made this win possible, and what would have to be true for it to happen again without the specific people who made it happen this time.

The question is unsentimental. The answer is often inconvenient. Sometimes the win happened because a senior leader was available at the right moment. Sometimes the win happened because two people on the team had a relationship that let them bypass a normal escalation. Sometimes the win happened because a piece of internal tooling that nobody documented was used in a clever way that nobody else on the team knows how to repeat.

The integration work is the second half of the question. What would have to be true. That is the design move. It’s unglamorous. It produces a slightly better protocol, a paired engagement, a piece of documentation, a removed bottleneck, a new default in a weekly ritual.

The work is small. It’s also what separates a team that compounds from one that performs and resets.

Develop Looks at the Patterns, Not the Events

Take a leader looking at twelve months of team performance.

The novice approach is to look at the wins and the losses individually. Project A went well. Project B went badly. Project C was mixed. The leader does an after-action on each, finds local lessons, and moves on.

The Develop approach is different. The leader steps back from the individual events and looks for patterns across them.

Which kinds of work consistently went well, and which kinds consistently went badly. Pattern, not event.

Which conditions correlated with the wins, regardless of which team did the work. Conditions, not credit.

Which failures repeated despite the team being technically capable of avoiding them. Repetition is the signal that the system has a structural gap, not that the individual people are at fault.

The patterns reveal what is integrated and what is not. A team that consistently wins on one kind of project and consistently struggles on another has structural capacity for the first and not the second. The development work is to build the structural capacity for the second, not to keep relying on individual heroics to bridge the gap.

A leader who works the patterns is doing organizational design. A leader who works only the events is doing project management. Both are necessary. Only one of them produces compounding.

Develop Closes When the Lesson Has Become Structure

Develop does not close because the team has held a retrospective. It closes when the lesson from a win has been turned into a mechanism that survives the people who learned it the first time.

Three signals that Develop has closed.

The lesson has been named in terms specific enough to act on, not abstract enough to feel philosophical. The mechanism that integrates the lesson has been built and embedded in an existing workflow, not added as a new optional layer on top. The team can produce the win again, six months later, without the original person specifically being involved.

When all three are present, the lesson has become structure. The system has gained capacity. The next time the cycle runs, Target opens on a floor that is slightly higher than the last one.

When any of the three is missing, the stage is not yet complete. The team will have done the work and learned the lesson and not integrated it, which means the next time the same condition arrives, the team will solve the same problem again. The cycle will produce performance and not capacity.

Develop is the stage that earns the right to make the next cycle cheaper.

What This Means in Your Week

Three moves to run Develop on a recent win on your team.

  1. Pick a clean win from the last sixty days. Ask one question out loud, in writing. What made this possible, and what would have to be true for it to happen again without the specific people who made it happen this time. Capture the answer in concrete terms.
  2. Pick one element from the answer that can be turned into a mechanism. The smallest one. A removed step. A new default. A pairing. A piece of documentation that fits on one page.
  3. Embed the mechanism in an existing workflow. Not as a new optional practice. As a modification to something the team already does. If it does not get embedded, the lesson stays a story.

Where this leads

Develop is one of six kinds of attention THREAD™ names, not a step in a line. It is the vantage that decides whether the work of the others compounds, or whether the team runs clean cycles that never get cheaper. Lean only on Develop and you polish lessons with nothing in front of them. Ignore it and the same hard problem gets solved from scratch every time it returns.

The THREAD™ Path page walks the full hexagon: all six, what each does and what each does not. About a fifteen-minute read.

Read across the lens: Target · Horizon · Resource · Evaluate · Act · Develop.

Chandler Thompson
Chandler Thompson
Articles: 13

Leave a Reply

Your email address will not be published. Required fields are marked *