Skip to content

When the Company Ran on Conversations: A Case Study in Building Organisational Structure

CASE STUDY · BUSINESS STRUCTURE

When the Company Ran on Conversations

A Case Study in Building Organisational Structure

This is a real case study. Names and identifying details have been changed to protect confidentiality. The situation, the tensions, and the outcomes are all real.

The Setup

It was a 40-person company. Profitable. Growing. The founder had built it almost entirely on relationships, with clients, with employees, with vendors. He was the kind of person who remembered everyone’s birthday, called people by their first name on day one, and had a genuine warmth that made people want to work hard for him.

But the company had a problem. A quiet, creeping, invisible problem.

Everything ran on conversations. Approvals happened over WhatsApp. Deadlines were discussed in hallway check-ins. Feedback was given verbally, once, and then forgotten. New employees were onboarded by shadowing someone for a week and hoping they picked things up. Decisions were made in the founder’s head and communicated in fragments, sometimes to one person, sometimes to three people differently, sometimes not at all.

Nobody had a written job description. Nobody had a documented process. Nobody really knew who was accountable for what, until something went wrong.

The Problem That Broke the Surface

The trigger was a client complaint. A long-standing client had been promised a deliverable. Three people thought someone else was handling it. No one had written it down. The deliverable was missed. The client was furious. When the founder tried to understand what had gone wrong, he got three different versions of the same conversation.

That’s when he called me in. Not for a grand organisational overhaul. He was practical. He said: “I just want people to know what they’re supposed to do. I don’t want a missed delivery to ever happen because no one wrote it down.”

It sounded simple. It wasn’t.

What I Found When I Looked Closely

Before building anything, I spent the first two weeks just listening. I sat in on meetings. I read through WhatsApp threads (with permission). I had one-on-one conversations with eight employees across functions.

What I found wasn’t chaos. It was something more nuanced: an informal system that worked brilliantly when the company was 10 people and was quietly straining under the weight of 40.

Here is what the diagnostic showed:

Role ambiguity was rampant. Two people were doing the same task from opposite ends. Three tasks had no owner at all.

The founder was the bottleneck for everything. Even decisions that didn’t require him kept floating up because there was no clarity on who else could make them.

Institutional knowledge lived in people’s heads. One senior employee was the unofficial keeper of all client history. If she left, the company would lose years of context overnight.

Feedback only flowed downward, and rarely. There were no structured check-ins. Performance was assessed by gut feel, not data. Good work often went unacknowledged.

New joiners were swimming, not onboarding. There was no document, no checklist, no structured first 30 days. Every new joiner’s experience depended entirely on which team member they happened to shadow.

The root cause wasn’t a lack of effort or talent. The root cause was that the company had never been forced to externalise its knowledge. Everything was verbal because the founder was brilliant at holding everything in his head, and everyone else had learned to mirror that approach.

The Approach: Structure Without Suffocation

The biggest fear the founder had, and it’s a fear I hear from almost every founder I’ve worked with, was that adding structure would kill the culture. That it would make the company feel corporate, stiff, bureaucratic.

That fear is legitimate. But I’ve also seen the opposite: companies that never built structure and eventually collapsed under the weight of tribal knowledge, founder dependency, and accountability gaps.

The goal wasn’t to create a manual for everything. The goal was to make the implicit explicit: to take what already existed informally and give it a form that could survive without being held in one person’s memory. We worked in four phases over three months.

Phase 1: Role Clarity Documents (Weeks 1–3)

We started not with org charts but with a simple question asked to every person: “What do you actually do, day to day? And what do you think is not your job, but keeps landing on your desk?” From those conversations, we built one-page Role Clarity Documents for each position: core responsibilities, key decisions this role can make independently, deliverables this role owns, and who this role escalates to when stuck. Three roles got redrawn entirely based on what the team surfaced.

Phase 2: Decision Rights Framework (Weeks 3–5)

We built a simple Decision Rights Matrix: a one-page grid mapping decision types against decision levels. This single document reduced the founder’s daily involvement in operational decisions by what he estimated was 40%. Not because he stepped away, but because his team now had permission, in writing, to act without him for a defined category of decisions.

Phase 3: Core Process Documentation (Weeks 5–10)

We identified the five highest-impact processes: client onboarding, project handover, monthly reporting, vendor payment, and new employee onboarding. For each, we ran a “walk-through” session where the person who currently owned that process narrated every step out loud while someone else documented it. Our quality bar was simple: if a new person could follow the document and get to a reasonable outcome without needing to ask the founder, it was good enough.

Phase 4: A Rhythm for Accountability (Weeks 10–12)

The final piece wasn’t a document. It was a cadence: a meeting rhythm that gave structure to how the team communicated formally, not just informally. We introduced three recurring touchpoints. A Monday morning 20-minute team standup. A bi-weekly founder check-in with each function head. And a monthly all-hands where one team shared a “what we learned this month” update. The all-hands learning sessions became, unexpectedly, the most valued ritual.

What Changed, and What Didn’t

Six months after the engagement ended, I checked back in. The missed-delivery incident that had triggered the whole project hadn’t recurred. Not once. Two new employees had joined and onboarded significantly faster than any previous hire. The founder had also, for the first time in eight years, taken a two-week holiday and the company hadn’t needed to call him once.

What didn’t change: the warmth. The founder still remembered birthdays. People still talked in corridors. The culture that had built the company didn’t disappear when structure arrived, because structure, done well, doesn’t replace culture. It supports it.

Key Takeaways for Any Growing Organisation

1. Verbal cultures don’t fail because people are careless, they fail because they scale. What works at 10 people breaks at 40. The trigger isn’t bad intent; it’s a system that was never designed for the size it grew into.

2. Start with role clarity, not org charts. Org charts show reporting lines. Role clarity documents show accountability. Most growing companies need the latter far more urgently than the former.

3. Documentation is not bureaucracy, it is institutional memory. Every time you document a process, you are extracting knowledge from one person’s head and making it available to everyone.

4. The founder as bottleneck is a structural problem, not a character flaw. The fix is not to change the founder; it’s to build systems that don’t require their constant presence.

5. Rhythm creates safety. When people know they have a standing forum to raise blockers, share updates, and be heard, they stop hoarding problems until they explode.

If this case study resonated with something you’re seeing in your own organisation, I’d love to hear from you. The situations change; the patterns rarely do.

Leave a Reply

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