Skip to main content
The Team Collaboration Framework I Use Instead of Trust Falls

The Team Collaboration Framework I Use Instead of Trust Falls

I stopped running team-building exercises. I run a team collaboration protocol instead: ten written disclosures, staged over five weeks, that outlast an afternoon.

By · Published

I stopped running team-building exercises with the teams I work with. I run a team collaboration protocol instead, and the difference is not cosmetic: an exercise makes people feel closer for an afternoon. A written disclosure process makes people usable to each other for the life of the team, because everyone knows, in writing, how everyone else actually operates.

Most team collaboration advice is attitude dressed up as strategy: be more open, communicate more, trust each other. I think that gets the order backwards. You cannot be more open about something you have never been asked to articulate. Nobody spontaneously volunteers that they do their best thinking at 9am and go flat by 3pm, or that they read silence as disapproval, or that public praise embarrasses them more than it motivates them. You have to ask. Directly, in a structured way, before the friction starts, not after it.

Why team collaboration advice about attitude keeps failing

In almost every team I am brought in to fix, I see the same pattern: capable, well-intentioned people grinding against each other on the small stuff, how to give feedback, when to interrupt, what counts as an urgent message versus a routine one. None of that starts as a trust problem. It is an information problem. Left unaddressed long enough, it turns into a trust problem, because ambiguity gets filled with the worst available interpretation, every time.

This is my Team Collaboration and Effectiveness Framework: the Ten Disclosures. This is a working method, not a philosophy for the wall. It is a set of ten questions I have every team member answer in writing, then share with the group, two questions a week for five weeks. By the end, the team is not guessing about each other any more. It knows.

The Ten Disclosures: Stuart's Team Collaboration and Effectiveness Framework

  • 1. Contact protocol: How do you actually want to be reached for urgent, routine, and complex matters, not how you think you should answer. Most teams have never agreed what "urgent" means, so everything gets treated as urgent, and nothing is.
  • 2. Feedback exchange: How do you want to receive feedback, and how do you naturally give it. These are often mismatched inside the same person: someone who wants blunt feedback themselves may still deliver it too softly to others because they are managing their own discomfort, not the recipient's needs.
  • 3. Energy windows: When are you sharp, and when are you spent. Scheduling deep work against someone's dead zone is not a minor inefficiency; it is asking for their worst output on your most important task.
  • 4. Meeting engagement: What makes a meeting worth attending for you, specifically. Agendas in advance, room to think out loud, documented outcomes: people's answers here predict who goes quiet in your meetings, and why.
  • 5. Effectiveness drains: What specifically derails your focus: context-switching, ad hoc interruptions, unclear priorities. This is the one people under-report, because naming it feels like a complaint. That is maintenance information, not a complaint.
  • 6. Growth edge: What are you actively working on. Naming a real development area out loud, not an interview-safe answer, signals that the team is a place where admitting you are unfinished is normal, not risky.
  • 7. Motivation and recognition: What genuinely drives your best work, and how do you want to be recognised for it. Autonomy motivates some people and unsettles others. Public praise lands as reward for some and exposure for others. Guessing wrong here is worse than saying nothing.
  • 8. Decision style: Do you want to be consulted or informed. Do you think best through structured analysis or rapid brainstorming. Decision friction is rarely about the decision; it is about people being looped in, or shut out, in a way that does not match how they process.
  • 9. Collaboration mode and natural role: Do you do your best thinking alone first or in a room with others. What role do you gravitate to in a group: facilitator, challenger, synthesiser, executor. Teams that know each other's default roles stop competing for the same one and start covering the gaps.
  • 10. Working values: What principles actually govern how you work, not the values poster on the wall, yours. Shared vocabulary here is what lets a team disagree on a decision without it becoming personal.

The mechanism matters as much as the content. I do not hand this out as a one-off survey that gets filed and forgotten. Teams commit to two questions a week: pick your top two, answer them properly, share with the group, discuss for ten minutes in the next check-in. Five weeks later, all ten are covered, and the team has had five short, low-stakes conversations about how it actually works, rather than one long, high-stakes one after something has already gone wrong.

What the research says about why this works

I did not invent the idea that structure beats hope on team performance; I built a mechanism around what the research already shows. Google spent two years studying 180 of its own teams under an internal effort known as Project Aristotle, trying to find out whether it mattered more who was on a team or how the team worked together. The answer was the second one, and the single strongest factor the researchers identified was psychological safety: each member's read on whether taking an interpersonal risk in front of the group would be held against them.

2x: more likely to be rated effective by executives: Google's Project Aristotle found individuals on teams with a strong team culture were rated effective twice as often by executives, brought in more revenue, and were less likely to leave the company (Google re:Work, Understand Team Effectiveness).

That finding is exactly why I do not tell teams to "build psychological safety" and leave it there. Telling a team to be safer is advice with no mechanism attached, which is the same complaint I have about most team collaboration guidance. The Ten Disclosures are the mechanism: a structured way to take the interpersonal risk the research says matters most, in a setting low-stakes enough that people will actually take it. Alongside psychological safety, Google's researchers ranked dependability, structure and clarity, meaning, and impact as the other dynamics that separated its highest-performing teams from the rest. The disclosures map onto all five: contact protocol and meeting engagement build structure and clarity, effectiveness drains and decision style build dependability, and growth edge and working values build meaning.

Let me be direct about one thing: none of this works if it is treated as an HR exercise. If people write safe, professional-sounding answers designed not to reveal anything, you get a document, not a framework. The value lives entirely in specificity. "I prefer direct feedback" tells the team nothing. "I want to hear the criticism first, in one sentence, before any of the context, otherwise I spend the whole conversation waiting for the bad news" tells them exactly how to talk to you.

Understanding how team members prefer to be contacted for different types of communication is where most of this starts, because it is the lowest-stakes disclosure and the one that pays off fastest. A routine question through the wrong channel, or an urgent one buried in email, wastes a day for no reason other than nobody asked. Once the team has that map, the harder disclosures, feedback style, decision involvement, what drains you, get easier, because the group has already proven the exercise is safe.

Providing and receiving feedback effectively is where I see the biggest gap between what people assume about their colleagues and what is actually true. The pattern I run into constantly: someone believes they are a direct communicator, and their team experiences them as blunt to the point of dismissive, or the reverse, someone believes they are being kind by softening feedback, and their team experiences it as vague to the point of useless. The disclosure exercise surfaces the gap. It does not close it. That takes practice. But you cannot practise fixing something you do not know is broken.

Identifying when team members are most productive, and when they are best suited for collaboration, is a scheduling question dressed up as a personality question. Once the pattern is visible, the method is straightforward; most people recognise their own rhythm. What is missing is a mechanism for that information to reach whoever is making the calendar decisions. Deep-work blocks get fragmented by meetings because nobody has the data, not because anyone means the harm.

Effective meetings are where a badly run disclosure process shows up fastest, because meetings are the one arena where every individual preference collides in the same room at the same time. Pre-shared agendas, concise framing, documented outcomes: none of that is novel advice. What is novel is knowing, specifically, which of your team members need it and which do not, instead of applying a blanket meeting policy that half the room finds patronising and the other half finds essential.

Identifying and reducing what drains someone's effectiveness is the disclosure people are most reluctant to make honestly, because it can read as a complaint about how the team or the manager operates. Frequent context-switching, unstructured interruptions, unclear priorities, notification overload: these answers come up constantly, and they are almost never about any one person. They are about default operating patterns nobody chose on purpose. Naming them is what makes them fixable.

Sharing development areas, what skills or leadership capabilities someone is actively working on, does something the other nine disclosures do not: it makes imperfection normal at the team level, tolerated individually. A team where everyone privately knows they are a work in progress, but nobody says so, is a team performing competence at each other. That is exhausting to sustain, and it blocks the honest feedback the whole framework depends on.

Motivators and recognition preferences are the disclosure most often assumed rather than asked. Managers default to what motivates them and get it wrong for a meaningful share of their team, every time, because motivation is not uniform and never has been. Some people want challenge and autonomy. Some want the impact of their work spelled out explicitly, because they cannot feel it otherwise. Some want public credit; others find it mortifying. Undisclosed difference is where recognition efforts backfire.

Decision-making style, how someone wants to be involved, and whether they think through structured analysis or rapid brainstorming, determines whether your team's decisions feel inclusive or feel like being informed after the fact. Get this wrong consistently and you train capable people to stop offering opinions, not because they have run out of them, but because they have learned the timing is always wrong.

Collaboration preferences and natural group role are what let a team stop duplicating effort. When nobody has disclosed that they default to facilitator, you get three people trying to run the same conversation and nobody synthesising the output. When everyone knows the natural roles in the room, the team self-organises around gaps instead of competing for the same seat.

A caution on sequencing, because I have watched teams get this wrong: do not start with values, and do not start with feedback. Both feel like the important disclosures, so teams want to lead with them, and both are the ones people are least honest about on day one, because trust has not been established yet. Start with contact protocol and energy windows, the low-stakes, almost administrative disclosures, because answering them honestly costs nothing and builds the habit of honesty before you ask for anything that feels exposing.

Core values are the last disclosure, and I put it last on purpose. By the time a team reaches it, they have already built five weeks of small, low-stakes honesty. Sharing the principles that actually govern how you work, transparency, accountability, mutual respect, continuous improvement, whatever they genuinely are for you, lands very differently once the team has already demonstrated it can handle honest disclosure without punishing it.

Pick your top two items a week, and in five weeks you will have covered all ten. Not because the team suddenly agrees on everything, but because it has stopped mistaking difference for dysfunction. One more thing worth saying plainly, because I get asked it every time I run this with a new team: no, this is not therapy, and no, you do not need a facilitator or an off-site to do it properly. It runs inside your normal weekly check-in. Two questions, ten minutes, every week, for five weeks. The cost is trivial. The reason teams do not do it is that nobody ever made it anyone's job to ask.

Related Reading

Why disclosure beats trust-building exercises

I will say the quiet part plainly: most trust-building exercises do not build trust. They build a shared memory of an afternoon. Trust is built by accurate prediction: by knowing, before you act, how a colleague will respond, what they need, and what will land badly. You cannot predict what you have never been told.

The reason I insist on the written, staged, five-week format rather than a single workshop is that trust does not form in a single sitting, no matter how well-run it is. It forms across repeated small proofs that honesty was safe last time, so it is worth risking again this time. A one-off session where everyone shares their communication style is a nice afternoon. A five-week cadence where the team keeps showing up honest, week after week, is a different thing entirely: it is a habit, and habits are what survive contact with a hard quarter.

I also want to be clear about what this framework does not do. It does not resolve conflict. It does not fix a team where the real problem is a manager who will not act on what they learn, or a member who discloses honestly and gets penalised for it later. Disclosure without follow-through is worse than no disclosure at all, because it teaches people that honesty gets logged and ignored. If you run this and then keep scheduling the same person's deep-work block through their dead zone, or keep giving public praise to someone who told you they hate it, you have spent their trust rather than earned it.

What it does do, reliably, is remove the single biggest source of team friction I encounter in my work: people assuming their own operating preferences are the default, and everyone else's deviation from that default is a character flaw rather than a difference. Ten structured questions, answered honestly and acted on consistently, is a small intervention. The effect on how a team actually works together is not small at all.

If I had to compress this into one sentence for a leader deciding whether to bother: teams do not fall apart because people are difficult. They fall apart because nobody was ever asked to explain themselves before the assumptions calcified. Ask early. Ask in writing. Ask ten specific questions instead of one vague one about "communication styles." That is the whole method, and it is ownable precisely because almost nobody does it: most teams still rely on osmosis, slowly figuring each other out through months of friction, when a structured five-week disclosure gets them there in a fraction of the time and without the scar tissue.

I run the Ten Disclosures with teams inside my direct coaching engagements, and the same disclosure logic sits underneath how CapabilityAI prompts teams to surface working preferences between live sessions, rather than losing them between one workshop and the next.