The Ubuntu Trust Framework · A Working Paper, 2025
Seven pillars for the kind of trust a distributed team can actually feel on a Wednesday.
A long, deliberately peer-reviewable look at the operating model underneath Ubuntual — written for the Heads of People, VPs of Ops, and Chiefs of Staff who are tired of culture-wash and want rigor before they buy.
A measured preamble — what the Ubuntu Trust Framework is, what it isn’t, and who built it.
The Ubuntu Trust Framework is the proprietary seven-pillar model at the center of everything Ubuntual ships. It began in 2021 as a graying-page Google Doc between two founders — one former People Lead at Doist, one former CTO of a Nordic fintech — and a borrowed office in Cape Town. It is now a working instrument used inside 2,400+ distributed teams across 64 countries, and it is the reason we are not, and have never been, in the business of selling motivational posters.
This page is written for the operator who has been burned by a culture deck and would like, before booking anything, to read the actual artifact. Take your time. There are about two thousand words below.
What the Framework is: a layered model of the conditions under which distributed teams compound trust over time — and the rituals, feedback loops, and measurement instruments that make each condition operable on Monday morning.
What it is not: a values statement, a poster wall, a personality test, or a “culture transformation” offering. The seven pillars are deliberately unsexy. Each has been tested across 612 company onboardings between 2021 and 2024, in collaboration with 38 distributed-team researchers, and revised five times. The current revision is held under version control at Ubuntual and is updated once per quarter.
Pillars
Seven
Validation dataset
612 companies, 2021–2024
Research collaborators
38 distributed-team researchers
Revisions to date
Five, quarterly cadence
Current revision
v2025.Q2
Independent citation
Harvard Business Review, May 2024
Pillars I & II · The Foundation
Before a team can run async, it has to be willing to be seen.
The two foundational pillars concern themselves with the preconditions of trust: the felt sense that one belongs, and the willingness to be psychologically safe inside a group that does not share a building.
IPillar One
Belonging without proximity
Belonging is a system, not a feeling.
We define belonging operationally as the reproducible condition in which a teammate, in any time zone and at any tenure, can name who they are inside the group and have that name be received as accurate by the rest of the group. This is measured weekly inside Ubuntual through a two-question instrument called the Ubuntu Pulse, benchmarked against 187,000 distributed teammates.
The four operational levers of Belonging are: (1) name and pronoun registration at onboarding, (2) asynchronous introductions that survive first-week turnover, (3) structured cross-timezone pairing during the first 90 days, and (4) a visible, named owner for each new hire’s first quarter. Teams that implement all four see a measurable lift in Pulse scores by week six.
— Pillar I, Ubuntu Trust Framework, v2025.Q2
IIPillar Two
Psychological safety, instrumented
Trust begins where the cost of disagreeing falls to zero.
Trust, in the Framework, is not warmth. It is the measurable willingness of a teammate to surface a concern, file a dissent, or admit a mistake inside a group conversation, without first running a private political calculation about what it will cost them. We instrument it through three signals: the ratio of surfaced concerns to private DMs; the latency between a decision and the first respectful disagreement; and the frequency of “I was wrong” statements in retros.
The two rituals that move the needle are: (1) the Weekly Round, a written-only Friday thread in which every teammate is paid to disagree with one decision that week, and (2) the Repair Hour, a 60-minute weekly block owned by rotating managers specifically for closing the loop on unresolved tensions. Neither ritual is optional inside the Framework.
— Pillar II, Ubuntu Trust Framework, v2025.Q2
Pillars III & IV · The Operational Layer
Philosophy is cheap. Operability is what compounds on Monday.
The middle pillars are where Ubuntu stops being an idea and starts being a system a Head of People can hand to a manager on a Tuesday and have running by Thursday.
IIIPillar Three
Async cadence that respects the planet
Async Cadence: rhythm over availability.
The third pillar codifies the asynchronous operating cadence that makes distributed work survivable across 11+ time zones. Every ritual — standup, review, planning, retro — ships with a timezone-aware template that defaults to written-first and treats the live call as an optional second pass. Standups ship as a 24-hour written window in which teammates post what they shipped, what they’re stuck on, and what they need, in their own language and on their own morning.
Three observable signals mark a healthy Cadence: (1) fewer than two mandatory synchronous hours per teammate per week; (2) zero “I missed the meeting, can someone catch me up?” tickets per cycle; and (3) the median response latency on written threads below 11 working hours. Teams at GitLab, Doist, and Buffer alumni companies operate against these signals today.
— Pillar III, Ubuntu Trust Framework, v2025.Q2
IVPillar Four
Rituals you can run twice without it getting weird
Ritual Design: small, repeated, on the record.
Rituals, in our usage, are small repeated acts that bind a group to a shared history. The fourth pillar specifies the conditions under which a ritual survives: it must be (1) documented, (2) owner-named, (3) bounded in length, and (4) archived in a place the next teammate can find. The Framework ships with 31 such rituals, including the Tuesday Welcome (a five-minute written check-in with every new hire’s manager for their first six weeks), the Friday Round (described above), and the Quarterly Weave (a 90-minute cross-timezone pairing exercise that pairs engineers with customer-facing teammates).
The two failure modes we look for are the Sporadic (rituals that happen when someone remembers) and the Performed (rituals that happen on stage in front of leadership). Both reduce Pulse scores within a quarter. The remedy in both cases is the same: write it down, assign a name, ship it.
— Pillar IV, Ubuntu Trust Framework, v2025.Q2
Pillars V & VI · The Connective Tissue
Daily async is the spine. Shared purpose is the marrow.
The fifth and sixth pillars concern what happens between people when a decision goes wrong — and what holds a group together when the cadence gets boring.
VPillar Five
The cost of staying silent, made visible
Feedback & Repair: closing the loop faster than it opens.
The fifth pillar addresses the single largest driver of remote attrition we have observed across the 612-company validation set: unresolved feedback. It is not, contrary to the culture literature, the absence of feedback that hurts distributed teams. It is the presence of feedback that never visibly closes. The Framework therefore defines feedback as a loop, not an event: every piece of feedback ships with a named owner, a deadline, and a closing record.
Repair, the second half of Pillar V, is the named practice of returning to a teammate who was harmed by a decision and visibly fixing it — publicly, in the same channel, with a timeline. Teams operating inside the Framework run a median of 2.4 visible repairs per quarter. It is uncomfortable. It works.
— Pillar V, Ubuntu Trust Framework, v2025.Q2
VIPillar Six
Why we are all here, written down
Shared Purpose: a sentence a hire can quote at month six.
Purpose, in this Framework, is not a wall poster. It is a single sentence that any hire can quote — under oath, at month six — about why their team exists, who it serves, and how its success will be measured over the next two years. We have watched otherwise excellent distributed organizations lose their best people to loneliness of purpose: a slow separation between what the team says it is for and what the team is actually rewarded for.
Three artifacts hold Shared Purpose in place: (1) the One-Sentence Charter, rewritten every 24 months or after any 30% growth event; (2) the Quarterly Compass, a public retro against that sentence; and (3) the Visible Tradeoff, in which the founding team names, in writing, what the company will not do this year. None of these artifacts is novel. All three are absent from roughly 60% of the distributed teams we audit.
— Pillar VI, Ubuntu Trust Framework, v2025.Q2
Pillar VII · The Capstone
Compounding Trust.
The seventh pillar is not a behavior. It is the long, slow observation that when the other six are in place — and only when the other six are in place — trust compounds rather than decays across a distributed team’s lifecycle.
VIIPillar Seven
The instrument that ties the model together
Ubuntu Pulse: the weekly 60-second reading on whether your team is compounding or decoupling.
Ubuntu Pulse is the only built-in instrument of its kind in the culture-tool segment: a weekly 60-second survey, fielded every Wednesday morning in the teammate’s own timezone and language, that returns a single readable number — the Ubuntu Pulse Score — benchmarked against a dataset of 187,000 distributed teammates. It is, depending on how you hold it, a thermometer and a compass.
What Pulse actually measures is the rate at which a team is compounding the other six pillars. A rising Pulse correlates with falling 90-day attrition, rising async throughput, and longer tenures among high performers. A falling Pulse over two consecutive quarters is, in our data, the single strongest leading indicator of a distributed-team crisis — earlier than engagement surveys, earlier than eNPS, earlier than the manager 1:1s the People team will run in panic.
The customers analyzed in our 2024 cohort reported, on average, a 41% drop in 90-day attrition within their first two quarters on the platform. We are not permitted to promise you the same number — your context is yours — and we are not in the business of writing you a guarantee that we cannot underwrite. What we can offer is the instrument, the cohort it’s benchmarked against, and the Framework underneath it.
Figure 7.1 · The Pulse instrument, dashboard view. Benchmark dataset: n=187,000, rolling 12-week window.
Across the seven pillars, the pattern is consistent. The teams that compound are not the teams that move fast on culture; they are the teams that move slowly and on the record. They write things down. They name the owner. They close the loop visibly. They run the Pulse every Wednesday and they act on what it tells them. They do this for years. The results, frankly, are not dramatic week to week. They are dramatic across a calendar.
— Pillar VII, Ubuntu Trust Framework, v2025.Q2 · End of Working Paper
Ubuntual