The Operating System of Teams

In the last session we looked at the software development lifecycle – how an idea waddles its way through discovery, design, build, test, and release, before staggering back around in an endless loop. That explained what happens.

Today we’re going to answer a bigger question: why do some companies make that cycle hum like a well-oiled machine, while others collapse in a heap of finger-pointing and PowerPoint?

The answer is the **operating system of teams**: structure, process, and culture. These aren’t the glamorous parts of technology – nobody brags about their governance model at parties – but they quietly determine whether a business thrives or dies.

Imagine a group of brilliant people locked in a room with no structure. Engineers would build whatever amused them, product managers would write manifestos, and designers would be sketching mood boards nobody asked for. It would, in short, be a creative utopia, and a catastrophic business failure. The ensuing chaos would be a sight to behold, a beautiful, sprawling mess of uncoordinated genius that would, ultimately, produce nothing of value. The resulting disaster would be a magnificent spectacle of wasted potential, a testament to the unassailable truth that a million brilliant ideas are utterly worthless without a single, boring one to organize them.

Structure exists because:

• Somebody needs to decide who owns what. Without clear ownership, a task becomes a cosmic game of hot potato, with everyone desperately trying to pass it to someone else before it explodes into a massive, embarrassing failure.

• Work needs to flow without constant traffic jams. Without a designated flow, every conversation becomes a negotiation, every decision a full-scale parliamentary debate, and every project a journey through a digital traffic hellscape.

• Investors like predictability, not chaos. Investors, a notoriously cautious and faintly paranoid species, prefer to know where their money is going, rather than simply watching it vanish into a black hole of competing priorities and existential dread. Structure, however tedious, provides this illusion of safety.

So while structure feels bureaucratic, it’s actually a survival mechanism. The absence of it produces spectacular disasters that usually end with the phrase: ‘we thought someone else was doing that.’

Modern companies, in a fit of architectural fancy, borrow heavily from the Spotify model, which is an organisational structure so complex and misunderstood that Spotify itself quietly stopped using it, which is the sort of poetic irony that makes the universe worth living in. Nevertheless, it is a useful framework for understanding how many businesses try to work.

Squads

Squads are cross-functional mini-companies: a product manager, a designer, engineers, sometimes QA and data. They own one feature or product area end to end. The theory is that if you give a small team a clear objective and actual authority, they will behave like a tiny startup with all the speed and occasional mayhem that implies. Why this matters: ownership prevents endless hand-offs. When everyone is responsible, nobody is responsible.

Personas inside Squads

• The Squad CEO: Believes outcomes beat output. Carries one metric like a holy relic. Ships weekly.

  Spot it: One slide roadmap that actually happens. Impact: Tight feedback loops, fewer meetings, fewer excuses. Fix if absent: Give the squad a single target and permission to say no.

• The Wheel Reinventor: Believes their problem is unique and therefore requires a bespoke logging framework written at 2am.

  Spot it: Custom auth, custom telemetry, custom outages. Impact: Slow, fragile systems. Heroics on Sundays. Countermeasure: Tax bespoke work. Reward reuse. Platform patterns are the default.

• The Scope Squid: Wraps every ticket in six new tentacles. Everything is phase one and somehow also phase three.

  Spot it: Stories that gain mass with every refinement session. Impact: Missed releases, melted morale. Countermeasure: Slice to one-week increments. Definition of done that fits on a post-it.

• The Squad Tourist: Attends every ceremony, contributes to none, produces immaculate slideware.

  Spot it: Many updates, zero commits. Impact: Burden on others, velocity theatre. Countermeasure: Tie tasks to measurable impact. Cull vanity work.

Tribes

Tribes are collections of squads aligned to a domain. They exist to stop ten autonomous squads building the same thing ten different ways. Why this matters: shared direction reduces duplicate wheels, some of which are not so much round as an abstract concept.

Personas inside Tribes

• The Tribal Elder: Sets a simple north star and then leaves people to do their jobs.

  Spot it: Three crisp principles that everyone can quote without crying. Impact: Coherence without micromanagement. Countermeasure: Write the principles. Repeat them until even the plants know them.

• The Domain Librarian: Catalogues decisions, patterns and interfaces so knowledge outlives meetings.

  Spot it: Decision logs, ADRs, diagrams that match reality. Impact: Faster onboarding, fewer arguments. Countermeasure: One page per decision. Date it. Owner it.

• The Tribal Bureaucrat: Believes alignment equals meetings. Schedules a symposium for every pull request.

  Spot it: Calendars that look like Tetris. Impact: Slow flow, creative work done after hours. Countermeasure: Replace committees with written proposals and time-boxed comments.

• The Local Warlord: Captures squads and bends them to pet projects.

  Spot it: Roadmaps that mysteriously match one person’s hobby horse. Impact: Misaligned investment, quiet revolt. Countermeasure: Public quarterly bets. Kill anything that does not move the tribe metric.

Chapters and Guilds

Chapters and guilds are communities of practice that cut across squads. All the frontend engineers share patterns. All the data scientists agree on how not to ruin a model. Why this matters: craft standards compound. Without them, entropy wins.

Personas inside Chapters and Guilds

• The Chapter Gardener: Prunes nonsense, fertilises good patterns, and keeps the weeds of tech debt down.

  Spot it: One blessed component library, one lint config, one way to test. Impact: Fewer defects, faster delivery. Countermeasure: Retire one tool for every new one you add.

• The Pattern Hoarder: Collects frameworks like commemorative teaspoons.

  Spot it: Seven build tools and a medium post to justify each. Impact: Confusion, training overhead, bugs. Countermeasure: Adoption gates. Sunset dates. Bounties for deletion.

• The Standards Evangelist: Writes clear standards that are short enough to be read and sharp enough to be enforced.

  Spot it: Two pages, not two novels. Examples beat rhetoric. Impact: Consistency without rage. Countermeasure: Make every standard testable or delete it.

• The Underground Artisan: Builds the nicest code nobody else can use.

  Spot it: Beautiful abstractions hidden in private repos. Impact: Lost leverage. Duplication elsewhere. Countermeasure: Open by default. Code reviews across squads.

Platform Teams

Platform teams build the bits everyone else depends on: auth, CI, observability, environments, golden paths. Why this matters: without shared foundations you get seventeen ways to sign in and nineteen ways to crash.

Personas inside Platform

• The Platform Janitor: Quietly removes friction. Measures success in other people’s speed.

  Spot it: Self-service environments, paved roads, docs that do not lie. Impact: Teams ship sooner with fewer explosions. Countermeasure: Track time to first deploy and kill the top three blockers.

• The Golden Path Cartographer: Draws one obvious way to build a service and keeps it current.

  Spot it: Templates, scaffolds, starter repos that actually work. Impact: Consistency and fewer weird edge cases. Countermeasure: Version the path. Deprecate kindly. Enforce gently.

• The Platform Feudal Lord: Declares all tickets must pass through their desk.

  Spot it: Backlogs that stretch to the horizon. Impact: Bottlenecks, shadow infra, quiet rage. Countermeasure: Product management for platform, with SLOs and a public queue.

• The Snowflake Enabler: Accepts every bespoke request because saying no is hard.

  Spot it: Twenty slightly different pipelines, all broken differently. Impact: Maintenance hell. Countermeasure: Publish support tiers. Charge the true cost of custom.

Centralised vs Decentralised

Should specialists sit in one central castle or be embedded with squads like a federation of mildly opinionated experts. The answer is it depends. Centralised gives standards and depth but risks a helpdesk queue. Embedded gives speed and context but risks fragmentation and twelve definitions of active user.

Personas in the Centralised vs Decentralised debate

• The Castle Warden: Centralises to protect quality.

  Spot it: Strong standards, slower intake. Impact: Fewer disasters, more queues. Countermeasure: Set service SLOs and temporary embeds to unblock squads.

• The Federation Maestro: Embeds specialists but keeps a thin central spine for standards and training.

  Spot it: Chapter time every week, shared toolchain, local autonomy. Impact: Speed with coherence. Countermeasure: Guardrails not gates. Regular cross-checks.

• The Data Wanderer: Embedded analyst with no home tribe.

  Spot it: Six Slack channels, no career path, inconsistent models. Impact: Drift, duplicated metrics. Countermeasure: Anchor in a chapter. Shared metrics layer. Rotation plan.

• The Ticket Tyrant: Central team that measures worth by queue length.

  Spot it: SLA worship, outcome ignorance. Impact: Compliance without progress. Countermeasure: Replace ticket counts with consumer team velocity and adoption.

Now, structure is only half the story. Teams also need a way of working – a process religion, if you like. The grand and often hilarious history of these processes is a testament to the unyielding human desire to turn complex, unpredictable work into a predictable, repeatable routine.

Waterfall

This is the classic, linear approach. You spend months (or years) meticulously planning and documenting every single detail of the final product, then you build it all at once, in a grand, final act of defiant hope. Why it exists: it matches the logic of traditional engineering, where you can’t exactly move the foundations of a bridge after you've built the bridge itself. Why it fails: software isn’t concrete. It moves. In the time it takes to build a product in Waterfall, the market will have shifted, the technology will have aged, and your customers will have moved on to something shiny that actually works. The final product is a beautifully-designed digital dinosaur, a magnificent but ultimately useless monument to human hubris.

Personality Profile: The Waterfall personality is a cautious and detail-oriented soul, a lover of spreadsheets and Gantt charts. They are the sort of person who meticulously plans a vacation down to the minute, only to be thrown into existential despair when their flight is delayed. They believe in the power of a perfect plan, which is a noble, if entirely pointless, philosophical position in the fluid world of software.

Agile

Agile is the chaotic, messy, and infinitely more sensible reaction to Waterfall's spectacular failures. It’s a process of building and releasing in small “sprints” of a few weeks at a time. It’s less a plan and more a series of controlled explosions, punctuated by a lot of frantic communication. Why it exists: because reality changes too fast for giant plans. The core philosophy is "fail fast, learn faster," which is a noble but often terrifying sentiment. Why it fails: people say they’re doing Agile but really just renamed their status meetings. Without strict discipline, it can devolve into a confusing, frantic mess. The term "Agile" is often used to justify a complete lack of planning, resulting in teams that run very fast in circles while screaming things like "sprint velocity" and "daily standup."

Personality Profile: Agile attracts a more adaptable, if somewhat frantic, personality. These are the people who are not in the slightest bit bothered by a sudden, drastic change of plans. They are the sort of people who would cheerfully agree to a trip to the beach, only to find themselves on a bus to the Arctic, and still be excited about the journey. They are driven by a need for constant motion, and can often be found in a state of perpetually high-stress but surprisingly productive panic.

Scrum

The most popular Agile flavour. It provides a strict, almost religious, set of ceremonies: Sprints, stand-ups, retrospectives. Why it exists: it gives structure to Agile’s chaos. It is a set of rituals designed to enforce communication and discipline on a species that is, by its very nature, uncommunicative and undisciplined. Why it fails: teams often obsess over the ceremonies and forget the point – delivering value. The daily stand-up becomes a chore, the sprint review a meaningless recitation of achievements, and the retrospective a passive-aggressive exercise in collective blame. The result is a team that is "doing Scrum" but is, in fact, not getting anything done.

Personality Profile: The Scrum personality is a lover of ritual and order, a person who believes that if they follow a set of strict rules, the universe will, in turn, reward them with a functional product. They are driven by a need to complete the ceremony, and can often be found obsessing over a backlog that stretches to the horizon.

Kanban

The low-key, minimalist cousin of Scrum. It’s a visual board with tasks flowing left to right, from "To Do" to "Done." Why it exists: to keep work visible and prevent overload. It is a quiet, unassuming system for a team that is not interested in ceremonies, only in getting things done. Why it fails: without a dedicated sense of purpose and discipline, the boards become graveyards of forgotten tickets and unloved tasks. A testament to all the good intentions that were never acted upon.

Personality Profile: The Kanban personality is a minimalist, a quiet soul who believes that a single task can be a universe in itself. They are not interested in the grand, sweeping narrative of a product, but in the single, quiet, satisfying motion of moving a ticket from "To Do" to "Done." They are the sort of person who would build a beautiful, perfectly functional house with a single plank of wood.

Scaled Agile (SAFe)

The corporate attempt to do Agile at scale. It’s a vast, bureaucratic framework that layers Agile principles on top of a traditional, hierarchical company structure. Why it exists: enterprises crave order. They see the success of Agile in small, fast-moving teams and think, "Yes, let's put that into a 200-page document." Why it fails: it usually turns into Waterfall with more jargon. It is a masterpiece of corporate misinterpretation, a process that promises speed and agility but delivers only more meetings, more documents, and more deeply cynical employees.

Personality Profile: The SAFe personality is a lover of process and bureaucracy. They are the kind of person who believes that a good plan, if written with enough detail, can solve all of the world's problems, including the problem of people not wanting to follow a plan. They are driven by a need to control the universe, and can often be found in a state of perpetual, low-grade panic, surrounded by a mountain of documents.

The point isn’t which religion you follow. The point is that process should serve the work, not the other way around. Too much process and you strangle speed. Too little and you get chaos.

Now we get to the most important bit – culture. You can have squads, Agile, roadmaps, dashboards, the lot. But if the culture stinks, everything collapses. Culture is the thing that determines a team's behavior when nobody's watching. It's the silent, invisible force that either propels a company forward or slams on the brakes with all the grace of a brick wall hitting a small car.

Culture boils down to three questions:

• Do people trust each other? If trust is missing, every decision turns into a turf war. Engineers refuse to use code they didn't write, and product managers are forced to write requirements so detailed they could be mistaken for a legal contract. The result is a company that is more interested in protecting itself than in building anything of value.

• Do they have autonomy to make decisions? If autonomy is missing, everything bottlenecks on managers. Every tiny decision, from the color of a button to the name of a variable, needs a manager's approval. The result is a company where nothing gets done, and the most valuable people are the ones who are the best at getting their manager's attention.

• Are incentives aligned across product, engineering, and business? If incentives are misaligned, sales will promise features engineers can’t deliver, product managers will panic, and the whole system will descend into a spiral of lies and recriminations. It's the kind of subtle, silent sabotage that can kill a company faster than a bad competitor.

Why does culture matter? Because it determines behavior when nobody’s watching. Tools and process might tell people what to do, but culture decides whether they actually do it.

Some patterns repeat so reliably it’s like watching the same bad film over and over. They are the seven deadly sins of the technology world, and they destroy scalability. They look fine in a five-person startup but lethal at 200 people.

• Too much process: This is a disease of scale. As a company grows, it adds more rules, more meetings, and more approval gates. Every decision needs five approvals, every change requires a 20-page document, and every new feature gets stuck in a perpetual state of "pending." The result is a company where nothing ships. This is often an attempt to prevent problems, but it ends up simply preventing everything.

• Too little process: This is the opposite problem. A company with too little process is a glorious, chaotic mess. Everyone is building everything, there is no single source of truth, and a simple change can break a dozen different systems. Chaos reigns, duplication is everywhere, and nothing is stable. It's a sort of digital Wild West, and while it can be exciting for a time, it is ultimately unsustainable.

• Hero culture: This is a company where all the success depends on one ‘rockstar engineer.’ This person is a genius, a myth, and a walking disaster waiting to happen. They know all the secrets, they work all night, and they are the only person who can keep the system running. But if they leave—to go to a company with better pay or, more likely, to get a good night's sleep—everything collapses. It's a system built on a fragile, human foundation.

• Silos: This is when different teams, departments, or even individuals operate in complete isolation from one another. Data is hoarded in one corner, security becomes a department of "no," and product and engineering are in a perpetual state of war. This prevents communication, creates friction, and ultimately ensures that no one knows what the other is doing. A company full of silos is like a magnificently engineered train with no tracks.

• Cargo cult Agile: A team suffering from this is a team that has learned the rituals but missed the point. They have daily stand-ups but don't communicate. They have retrospectives but don't learn from their mistakes. They go through the motions of "Agile," but they are, in fact, getting nothing done. Meetings are everywhere, value is nowhere. It is a sad, and far too common, state of affairs.

Why this matters: these patterns destroy scalability. They look fine in a five-person startup but lethal at 200 people.

And this is why private equity people like me obsess about teams. Because culture and structure aren’t fluffy HR topics – they determine value creation. It's the difference between a thriving, self-sustaining business and a money-burning husk of a company that is propped up by a few exhausted individuals.

• Strong teams deliver consistently. They are predictable, reliable, and get things done. They are, in short, a solid investment. You know what you're getting.

• Weak teams burn cash. They are unpredictable, unreliable, and cost a fortune to maintain. They are, in short, a liability. You don't know what you're getting, but you can be sure it's not good.

• Toxic cultures scare off buyers. A culture of fear, blame, and infighting is a loud, flashing warning sign to any sane investor. It's a company that is at war with itself, and a company at war with itself is a company that will not last.

So when I do diligence, I don’t just ask about revenue and technology. I ask:

• Who really owns decisions?

• How do teams coordinate?

• Are people empowered or terrified?

Because these things tell me whether a company can scale, and therefore whether it’s worth buying.