For Teams
Your cognitive approach is not a quirk to be managed. It is a resource the team needs — if the team is designed to use it. How We Excel gives you language and structure for contributing more deliberately, disagreeing more productively, and protecting yourself from being reduced to a label.
Most teams are assembled — not designed
Most teams are populated based on who is available, who has relevant titles, and who the leader already knows. The actual functions the work requires are rarely mapped in advance. As a result, teams routinely include the wrong mix of cognitive approaches for the work at hand — not because of bad people, but because of a bad process.
This creates a specific problem for team members: you may be contributing the right thing at the wrong time, or contributing a cognitive approach the team needs but doesn't know it needs. Without a shared vocabulary, that often reads as difficult, disruptive, or out of sync.
How We Excel gives you a framework to understand what is happening — and language to name it — without requiring your leader or team to already be using the system.
How We Excel takes seriously the idea that people who do the work, maintain the outputs, and live with the results are stakeholders in the design of that work — not just recipients of decisions made by others. Your perspective is not a preference. It is part of what makes the work valid.
What this section covers
- Understanding your cognitive approach and what it contributes
- Structured disagreement — how to challenge productively
- Cognitive partnering — working with different approaches deliberately
- Protection from labeling — what the framework is not
Your cognitive approach is functional, not personal
The eight cognitive approaches in CAP-5 describe how someone tends to enter shared work — not who they are as a person. Understanding your own patterns helps you contribute more deliberately.
Cognitive contribution is the specific thinking work you do in shared work — how you process information, generate ideas, evaluate proposals, manage relationships, or structure action. It is distinct from your technical expertise or your role on the team.
A person with strong Evaluative patterns may contribute to every stage of the work by stress-testing assumptions — even when that is not their formal job. A person with strong Relational patterns may catch the interpersonal breakdown that is about to derail a decision — even when no one asked them to attend to that.
These contributions are real functional work. They are often invisible until they are absent.
When a team consistently undervalues or suppresses a cognitive approach — by rewarding only certain types of contribution, by allowing only certain voices to shape decisions, or by labeling contributors as problematic when their approach differs from the dominant one — the team is reducing its own functional coverage.
If you find yourself consistently talked over when you raise concerns, dismissed when you ask for more time at requirements, or told that your approach is "too detailed," "too abstract," or "too focused on relationships" — that may be a coverage signal, not a personal criticism. Name it as functional: "I think we may be moving past requirements before they're complete" is different from "I think you're not listening to me."
You do not need CAP-5 results to use this language. The goal is to describe cognitive work in functional terms — what it contributes to the work — rather than in personal terms that invite defensiveness or misinterpretation.
- "I want to make sure we've identified all the stakeholders before we define the problem" — not "You always jump ahead."
- "I think there are options we haven't considered yet" — not "You're too rigid."
- "I'm noticing we haven't tested this assumption" — not "I have a bad feeling about this."
- "Can we name what the team must be able to do before we talk about who?" — not "That person isn't right for this."
Functional language anchors the conversation in the work. That is where shared disagreement can be productive.
Structured disagreement is functional — when it is aimed correctly
Not all disagreement is equal. The level of the disagreement matters more than the existence of it.
Disagreement about facts
Easiest to resolve — find the right data. When you are here, name it: "I think we have different information. Can we align on the facts first?"
Disagreement about requirements
Harder — and more important. You may be working from different assumptions about what the work must accomplish. Return to stakeholder needs before moving to solutions.
Disagreement about values
Deepest level. Cannot be resolved by finding more information. Needs to be named clearly and either negotiated explicitly or escalated — not argued through endlessly.
What CAP-5 — and How We Excel — should never do to you
A framework that reduces people to types is not a cognitive visibility instrument. It is a labeling system. That is not what this is.
- Assign you a permanent type or label
- Rank your cognitive approach against others
- Exclude you from tasks, roles, or decisions
- Predict your performance or job fit
- Justify hiring, promotion, or exclusion decisions
- Reduce a complex person to their highest-scoring dimension
CAP-5 measures self-reported preferences at a point in time. Preferences shift across context, relationship, stakes, and phase. A high Evaluative pattern in one role may look very different in another. You are not your profile — and no one in a shared-work context should treat you as if you are.
If someone uses CAP-5 results or HWE language to exclude, rank, or limit access for you or a colleague, that is a misuse of the instrument. It is incompatible with the purpose of this architecture. You do not need to accept it as legitimate.
Cognitive partnering — deliberate, not accidental
When team members understand their own cognitive patterns and each other's, they can stop interpreting difference as difficulty and start designing for it.
Cognitive partnering is not about finding people who think like you. It is about being intentional with people who think differently — recognizing when those differences are covering functional gaps the work needs, rather than creating friction the team resents.
A strong Analytical pattern paired with a strong Ideational pattern can produce excellent requirements definition followed by creative solution design — or it can produce endless debate between evidence and possibility. The difference is usually whether both people understand what each approach is doing functionally.
The goal is not harmony. It is productive tension — where cognitive difference generates better work rather than better arguments.
Questions that shift the dynamic
"What cognitive work is this person trying to get done right now?"
"Is there a function we need at this stage that their approach covers?"
"Are we arguing at the right level? Is this a facts disagreement, a requirements disagreement, or a values disagreement?"
"What would I be missing if their approach weren't present?"
Explore the tools designed for team work
The Tools index lists what is available now, what is coming, and what each tool is specifically designed to do in shared work.