[Part 2] The system that saved my sanity (and my company)

Last week, we explored why work gets stuck even with a perfect org chart (read Part 1 here). If you did the exercise, you probably noticed that the same bottlenecks appears across your company.

I have been here. As my company grew, I found myself in endless meetings, constantly being pulled into decisions, and feeling like everything would fall apart if I stepped away. My calendar was full, brain was tired, and the business wasn’t growing “smoothly”.

I did not like managing “people”. We needed systems — clear, repeatable ways for work to flow without getting stuck between people, process, departments and most importantly, me.

This is part 2 of our 3-part series:

Part 1: ✓ Why org charts fail + what to do instead
Part 2: The 4 elements of an operating model
Part 3: How to implement without chaos (including handling exceptions)

Most companies try to design their operating model in one big swing. That’s like trying to fix traffic, parking, and public transport all at once.

In this edition, I will break down the 4 elements that make up an Operating Model for any business.

For each element, I’ll show you:

What it looks like when it’s broken
The system that works
The core principle behind it

Let’s dive in…

1. Decision Rights

A client needed a price discount. By the time it went through manager → me → finance → back to sales, the client was gone.Here’s the system we built:

Set well-defined roles, limits, and escalation paths.

For each decision type, we defined:

Who can decide (role, not person)
Their authority limit
Next level escalation

Example: “Account Executives can approve discounts up to [X] without review.”The principle: Push decisions down to where the information is.Result: No more work sitting idle waiting for approvals.With clear decision rights in place, the next challenge is ensuring everyone has the information they need to make decisions effectively.

2. Information Flow

Here’s what broken information flow looked like:

Sales didn’t know about the product update. Support wasn’t aware of the workaround Engineering found. Marketing announced features that weren’t built yet. Everyone was always late to know.

Here’s the system we built:

Set clear triggers for what information goes where.

Example:

New feature? Product team updates central changelog, triggering alerts to Sales and Support
Client complaint? Support flags severity: [P0 = immediate escalation, P1 = next day review]

The principle: Information flows should be automatic, not heroic.

Result: No more “I didn’t know about this” surprises.

Now that information flows freely, the next step is turning that information into actual work output.

3. Value Creation

Here’s what broken workflow looked like:Every new project felt like starting from scratch. Teams reinvented processes, debated handoffs, and scrambled to find templates.Here’s the system we built:

Map your core workflows once, then repeat.

Example:

Client onboarding: Define stages, owners, and exit criteria
Feature development: Set standard cycles [Discovery → Spec → Build → Test]

The principle: Routine work should follow routine paths.Result: Teams spend time executing work, not figuring out how to work. With clear workflows in place, the final piece is ensuring the right people are available at the right time.

4. Team Allocation

Here’s what broken team allocation looked like:

Everyone needed the same experts. Every project was of highest priority. Teams held onto their best people because they didn’t trust they’d get help when needed.

Here’s the system we built:

Create clear rules for expertise sharing.

Example:

Set schedules for expert availability (“Technical leads available for Project A mornings, Project B afternoons”)
Define what qualifies as “urgent” and how many urgent slots each team gets

The principle: Make team allocation predictable, not political.

Result: Work moves forward without getting stuck waiting for key people.

The Results

When these four systems were in place:

Teams moved faster without my constant involvement
People felt empowered to make decisions
Work flowed smoothly across departments
I could finally focus on strategic growth

Most importantly, the business became valuable – because it could run without me.

What's Next

So far, we covered the Why (the need) and the What (its components) of the Operating Model.

Next week, I’ll share the How. I’ll give you my detailed 6-week implementation guide, including:

Who should lead this (hint: not you)
How to pick your perfect pilot project
A week-by-week rollout plan
How to handle exceptions systematically

For now, try this:

Look at the last 3 decisions that took too long
Map who was involved and why
Draft ONE clear decision right that would have helped

This exercise will give you a head start on next week’s implementation guide. Go ahead, give it a try. If you get stuck – just hit Reply and let me know.

Thank you for being here. See you next Thursday.

Surabhi

PS: Remember what makes a business truly valuable? It’s not just about strong financials. It’s about having robust systems that reduce founder dependency and enable high-performing teams to execute without constant oversight. That’s exactly what an Operating Model will help you build.

What I am reading:

I’m almost halfway through Inspire Someone Today by Srikanth ND. And it’s one of the most practical books I’ve read for professionals.

Through the stories of six friends, it offers powerful lessons on mindset, leadership, resilience and more.

What I am enjoying the most is the AIM Framework at the end of each chapter. It’s a step-by-step guide to applying the concepts through micro-experiments.

If you’re looking to fast-track career growth, gain leadership skills, and find balance, this book should be on your list. Can’t wait to uncover more and share my takeaways.