Drexler-Sibbet Team Performance Model

The Umbrella I Promised You

A few articles back, when we talked about the Tuckman Model, I said something that I meant: the Tuckman model tells you the weather exists. Other models hand you the umbrella. I told you we’d come back to that.

This is the umbrella.

The Drexler-Sibbet Team Performance Model was developed in the early 1990s by Allan Drexler and David Sibbet at The Grove Consultants International. Where Tuckman gives you four stages and a vocabulary, Drexler and Sibbet give you seven stages, a specific diagnostic question for each one, and - this is the part that changes your coaching - a clear picture of what resolution and non-resolution look like at every step. If a team is stuck, you can pinpoint exactly which question hasn’t been answered. Tuckman tells you “you’re storming.” Drexler-Sibbet tells you why.

I’ve used this model in team health checks, reorgs, onboarding, and the occasional emergency intervention where someone says “this team is falling apart.” It is, without exaggeration, the model I actually reach for. Not the one I teach first - that’s still Tuckman, because people need the foundation. But when it’s time to do the real diagnostic work, I open this one.

Seven Stages, Seven Questions

Each stage has a central question that the team needs to answer. When the question gets resolved, the team moves forward with energy and clarity. When it doesn’t, the team gets stuck - and the stuck-ness has a specific, diagnosable shape.

That’s what separates this from Tuckman. It’s not just “here are stages.” It’s “here are stages, here’s the question each one asks, and here’s what it looks like when the team can’t find an answer.”

Stage 1: Orientation - “Why am I here?”

Every team starts with this question, whether anyone says it out loud or not. Why does this team exist? Why am I on it? Is this worth my time and attention?

When orientation resolves well, team members feel purpose and belonging. They understand why the team was formed and why their particular skills matter. When it stays unresolved, you get confusion and a low-grade anxiety that colors everything else. People show up to meetings without knowing why the meeting exists. They hedge their commitment because they’re not sure this team is going to matter. (If you’ve ever joined a new team and spent the first two weeks wondering what you were actually supposed to be doing, you’ve lived in unresolved orientation.)

The coaching move here is straightforward but often skipped: make the purpose explicit. Not in a mission-statement-on-a-poster way. In a “let me tell you exactly why this team exists and why you specifically were chosen for it” way.

Stage 2: Trust Building - “Who are you?”

Once people know why they’re here, they need to figure out who they’re here with. What are your skills? What’s your working style? Can I rely on you? Are you going to judge me if I ask a dumb question?

When trust building resolves, you see openness and willingness to be imperfect in front of each other. People ask for help without performing competence first. There’s a warmth in the room - not forced team-building warmth, but the quiet comfort of people who’ve decided they’re safe enough to be real.

When it stays unresolved, you get caution and facade maintenance. People protect their image. They cc everyone on emails as a form of defensive documentation. (If your team’s email threads read like legal briefs, you might have a trust problem.) Meetings are polished and hollow.

The single most effective thing a coach can do at this stage is create low-stakes opportunities for genuine interaction. Not trust falls. Not corporate icebreakers where everyone says their favorite animal. Real conversation about working styles, past experiences, and what each person needs to do their best work. Anything that moves people from “colleague I’ve met” to “human I understand.”

Stage 3: Goal Clarification - “What are we doing?”

This stage is where I see the most teams get stuck without realizing it. They have a charter. They have a backlog. They have a product owner who’s been talking about the roadmap. But the team members have subtly different understandings of what the actual goal is. One person thinks they’re building a platform. Another thinks they’re building a feature. A third thinks they’re proving a concept that might get cancelled in six weeks.

When goal clarification resolves, there’s shared vision and explicit assumptions. The team has a common picture - not just a shared Jira board, but a shared mental model of what “done” means. People make decisions autonomously because they know what they’re optimizing for.

When it’s unresolved, you see apathy, skepticism, and competing priorities. Sprint goals feel like someone else’s idea. There’s a specific kind of frustration that sounds like “we keep going in circles” - and they’re right, because circles are what you get when there’s no shared destination.

Stage 4: Commitment - “How will we do it?”

Goal clarification gives you the what. Commitment gives you the how. This is where the team decides on approach, assigns roles, and makes real promises about how the work will get done.

This is also where you find out whether the previous three stages actually resolved or just appeared to. A team that never really built trust won’t commit honestly - they’ll agree to timelines they don’t believe in because they’re afraid to push back. A team with unclear goals will commit to work that may not matter. Commitment is the stage where unfinished business from earlier stages comes home to roost. (Because of course it does.)

When commitment resolves, you see assigned roles, clear processes, and genuine buy-in. People know who’s doing what. They’ve chosen their approach together rather than having it imposed. They feel ownership - this is our plan, not the manager’s plan or the coach’s plan.

When commitment stays unresolved, you get dependence and resistance. People wait for instructions instead of taking initiative. They do what they’re told but don’t go beyond it. There’s a subtle foot-dragging - not sabotage, just the slow, heavy movement of people who are complying but haven’t committed. The difference between compliance and commitment is invisible in a standup and unmistakable in a sprint review.

Stage 5: Implementation - “Who does what, when, where?”

Now the team is executing. The question isn’t abstract anymore. It’s tactical. Who picks up that ticket? When does this handoff happen? Where does the deployment go?

This is the stage most organizations think about when they think about “teamwork.” But Drexler and Sibbet are clear that implementation quality depends entirely on how well the first four stages resolved. A team that skips to implementation without orientation, trust, goal clarity, and commitment will produce output. They just won’t produce the right output, or produce it efficiently, or enjoy doing it.

When implementation resolves, there’s disciplined execution and the satisfying hum of a team that knows what it’s doing. Blockers get surfaced and resolved quickly. When it’s unresolved, you see missed deadlines and constant confusion about who’s responsible for what. The team is busy but not productive. Meetings multiply because coordination isn’t happening informally.

This stage is where most retrospectives live, and the trap is that coaches focus all their attention here - process improvement, workflow optimization, tooling changes - without checking whether the real problem is upstream. A team with broken implementation might need better processes. Or they might need to go back to Stage 3 and figure out what they’re actually building.

Stage 6: High Performance - “Wow!”

This stage doesn’t have a question so much as an exclamation. The team isn’t just executing - they’re in flow. Individual expertise combines into something greater than the sum of its parts. (Yes, that’s essentially the S-word that consultants love. No, I will not say it.) People anticipate each other’s needs. Decisions happen fast because context is shared so deeply that long explanations are unnecessary.

If you’ve ever been on a team like this, you remember it. It might be the most satisfying professional experience a person can have.

When this stage resolves, you see surpassing results and spontaneous collaboration. The team isn’t following a playbook - they’re improvising, and it works because the foundation underneath is solid. People laugh more. They volunteer for hard problems. They cover for each other without being asked.

When it’s unresolved - when the team almost reaches it but can’t quite get there - you see overload and disharmony. The intensity without the flow state creates burnout. It feels like sprinting on sand.

Not every team reaches this stage, and that’s not always a failure. But the teams that do are the ones that make you believe this whole coaching thing is worth doing.

Stage 7: Renewal - “Why continue?”

Everything cycles. Members leave. Markets shift. Products mature. And at some point, the team faces a question it hasn’t had to answer before: is there still a reason for us to exist in this form?

This is where Drexler-Sibbet does something that Tuckman’s adjourning stage only hints at. Renewal isn’t just about ending - it’s about the decision point. The team might renew with fresh energy and a new purpose. It might dissolve and reform. The question “why continue?” has multiple valid answers, and none of them are wrong.

When renewal resolves, there’s recognition and celebration, followed by either energized continuation or healthy closure. When it stays unresolved, you get boredom and burnout. People stay out of inertia rather than purpose. The team that was once high-performing becomes a team that’s just… there. The best people start looking for their next challenge elsewhere - not because they’re unhappy, but because the “why” has evaporated and nobody’s refilled it.

The coaching move is to make the question explicit. Don’t let a team drift into irrelevance. Sometimes the answer is “yes, and here’s what’s next.” Sometimes the answer is “we did great work and it’s time to move on.” Both answers deserve a real conversation.

What This Changes About Your Coaching

Diagnosis Gets Specific

This is the fundamental upgrade over Tuckman. When a team is struggling, you don’t just know they’re “storming” - you know which specific question hasn’t been answered. Is the team confused about purpose (Stage 1)? Do they not trust each other (Stage 2)? Are they misaligned on goals (Stage 3)? Did they never genuinely commit to the approach (Stage 4)?

In my classes, I describe this as the difference between a doctor who says “you’re sick” and one who says “your iron is low.” Both are technically correct. One of them tells you what to do next. The symptoms at each stage are specific enough to identify and different enough from each other that you can usually pinpoint the stuck stage within a single observation session.

Team Health Checks That Actually Work

Here’s a practical application I use regularly: take the seven questions, turn them into a team self-assessment, and run it as a health check. Give each person the seven questions. Ask them to rate how well the team has answered each one - green, yellow, or red. Put the results on a wall and look at where the reds cluster.

The conversation that follows is almost always more productive than a generic retro. Instead of “what went well, what didn’t,” you’re talking about “we all agree that we don’t have goal clarity - what would it take to fix that?”

I’ve done this with teams ranging from brand new to two years old, and the pattern is consistent: the reds are rarely in implementation. They’re almost always in the first four stages. Teams think their problem is execution. The model shows them their problem is foundation.

Onboarding as Stage Reset

When a new member joins an established team, the team doesn’t restart from scratch - but it does need to revisit the early stages. You can design an onboarding process around the first four questions. Day one addresses orientation. Week one addresses trust building. Week two addresses goal clarity. By week three, the new person should feel committed - not compliant, but genuinely bought in. If they don’t, you know which stage to revisit.

This is more useful than the typical onboarding checklist of “here’s your laptop, here’s the wiki, here’s the standup time, good luck.” The first question a new team member asks - silently, always - is “why am I here?” If nobody answers it, they’ll spend weeks making up their own answer. And it might be wrong.

Navigating Reorgs Without Starting From Zero

Reorgs are where this model earns its keep. When teams get shuffled, the instinct is to act like nothing changed. Same sprint cadence, same ceremonies, same backlog - just different people.

Drexler-Sibbet says: no. A restructured team is a new team. Some trust may carry over, and organizational context provides some orientation. But the specific combination of these people with this purpose needs to answer its own questions.

The coach’s job is to slow the team down long enough to build the foundation, while managing the organizational pressure to produce immediately. The alternative - a team sprinting on unresolved stages - always costs more in the long run.

What It Looks Like in the Room

Dara had been coaching agile teams for about eight years, mostly in aerospace manufacturing. She’d seen her share of team dysfunction - schedule pressure, engineering pride, the particular stubbornness of people who build things that can’t afford to fail. But the team she inherited after a division-wide restructuring was a new kind of challenge.

Twelve people - structural engineers, systems engineers, a manufacturing liaison, two test engineers, and a project coordinator named Hank who’d been with the company for twenty-two years and had opinions about everything. They’d been pulled from four different programs to form a new integrated product team. On paper, they had every skill the project required. In practice, they had been meeting for six weeks and produced almost nothing.

Dara’s predecessor had focused on process. There was a Kanban board. There were standups. There were weekly status reports. All the machinery of a functioning team was in place, and none of it was working. The Kanban board had the same tickets on it from week three. Status reports said “on track” in a tone that convinced nobody.

Dara ran a team health check using the Drexler-Sibbet stages. She printed the seven questions on index cards and asked each person to sort them into three piles: “We’ve answered this,” “We’re working on this,” and “We haven’t touched this.”

“Why am I here?” - ten of twelve put it in “haven’t touched this.” Hank put it in “answered.” When Dara asked why, he said, “Because I was told to be here.” She said, “That’s an answer, but is it your answer?” He paused for a long time.

“Who are you?” - universal “haven’t touched this.” Twelve people meeting weekly for six weeks didn’t know each other’s backgrounds or working styles. They knew names and titles. They didn’t know humans.

“What are we doing?” - split. The systems engineers thought they were building a prototype. The structural engineers thought they were doing a design study. The test engineers thought they were writing qualification plans. Nobody was wrong, exactly, but nobody was aligned.

“How will we do it?” through “Wow!” - all “haven’t touched this.” Obviously. The later stages were empty because the early ones were.

Dara put the cards on the table: “This is why your Kanban board hasn’t moved. You’re trying to do Stage 5 work without finishing Stages 1 through 4.”

She spent three weeks - an eternity in aerospace, where schedule pressure is measured in kilopascals - working through the first four stages deliberately.

Week one was orientation. She got the program director to explain, in plain language, why this team existed and what was at stake. Not the contract language. The human version. “The current component has a fatigue problem that’s going to ground the fleet in three years. That’s what you’re solving.” Dara watched Hank’s face change. He’d known the what. He hadn’t known the why.

Week two was trust building. Each person shared their strongest technical domain and - the part that mattered - the thing they were least confident about on this project. A structural engineer named Wendy admitted she’d never worked on this type of alloy and was nervous about the material properties. Two engineers immediately offered to pair with her. That single moment of vulnerability did more for the team than six weeks of standups.

Week three was goal clarification. The team literally drew what they thought the end product was. The drawings were different enough to be alarming. By the end of a two-hour workshop, they had a shared picture - sketched on a whiteboard, photographed, and taped above the Kanban board.

By week four, the team committed to a phased approach the structural and systems engineers had designed together - something that wouldn’t have happened without the trust built in week two. Hank, who everyone had assumed was resistant to change, turned out to be the team’s most valuable integrator. He’d been quiet not because he didn’t care, but because nobody had asked the right questions.

The Kanban board started moving.

By quarter’s end, Dara’s team was delivering on schedule. The test engineers were in design discussions. The manufacturing liaison was catching producibility issues before they became expensive redesigns. People were solving problems across boundaries because they trusted each other enough to admit what they didn’t know.

At a program review, the division VP asked Dara what she’d done differently. She said, “I stopped asking ‘who does what, when, where?’ and started asking ‘why are we here?’”

He didn’t get it. She sent him the model.

Go Deeper

• Drexler, A.B., Sibbet, D., & Forrester, R.H. (1988). “The Team Performance Model.” In Team Building: Blueprints for Productivity and Satisfaction, edited by W. Brendan Reddy and Kaleel Jamison. The original publication. Harder to find than it should be, but worth tracking down for the diagnostic detail on resolved and unresolved states.

• The Grove Consultants International. grove.com. Sibbet’s consultancy, which publishes the Team Performance Model as a large-format visual framework. The poster-sized version is a legitimate coaching tool, not just wall art.

• Sibbet, D. (2011). Visual Teams: Graphic Tools for Commitment, Innovation, and High Performance. Wiley. Broader work on visual facilitation with significant coverage of the Team Performance Model in practice.

• Tuckman, B.W. (1965). “Developmental Sequence in Small Groups.” Psychological Bulletin, 63(6), 384-399. Read alongside Drexler-Sibbet to see where they overlap and where Drexler-Sibbet adds diagnostic depth Tuckman leaves implicit.

• Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass. A complementary model that diagnoses why teams get stuck - particularly at trust and commitment. See also the Five Dysfunctions card in this deck.