SPONSORED NEWSLETTER
I talk a lot about operating systems – more specifically business operating systems (BOS) – things like EOS, Scaling Up and their ilk.
And even more specifically I’ve been doing a client project reviewing the tooling options to support their BOS – yes, systems to run a system. It’s all getting a bit meta.
I’ve been doing a market appraisal of the software tools that have sprung up to help founders actually run them – tools like Ninety, MonsterOps and even what you can do with a bit of vibe coding
These platforms are designed to take the frameworks off whiteboards and spreadsheets and put them somewhere your whole team can see and use.
Here’s what got me to this point with that project.
I was working with a solo founder earlier this year who’d invested seriously in implementing a business operating system last autumn.
They’d chosen an appropriate framework, got a decent external facilitator and most of the managers seemed genuinely committed. So far so good.
But three months in, they told me things were already drifting.
They were seeing things like rocks weren’t getting updated, scorecards were half-filled in and their weekly meeting had become a bit of a box-ticking exercise.
When I dug into it, the problem wasn’t actually the operating system itself.
It was that all the knowledge to run it lived in a patchwork of spreadsheets, Google Docs and probably someone’s notebook too. There was no single place where the whole picture came together.
That got me thinking about why dedicated tools for running your operating system actually matter, as well as where founders consistently trip themselves up with them.
Let me be clear: I’m not here to sell you software as designing your BOS has to come first (commercial break: I run a business that helps you do this).
Having watched several scaling businesses try to implement systems for their operating systems, I’ve noticed some things that a proper tool does that cobbled-together alternatives struggle with.
The first thing is organisational clarity.
This sounds obvious, but it’s remarkable how quickly insights and knowledge in a growing company fragments.
Marketing thinks the priority is brand awareness while sales thinks it’s pipeline volume and the product manager thinks it’s the new feature release.
So the result is everyone’s busy and nobody’s aligned.
A well thought out BOS and the right software tool to support it gives you a single place where the vision, the quarterly priorities, the accountability chart and the scorecards all live together.
When everyone can see how their role connects to where the company is heading, you get far less of the miscommunication that typically plagues businesses in the 20-to-100 person range.
The second thing is disciplined execution.
Here’s the thing about meeting rhythms and quarterly rocks and scorecards – they only work if you actually do them!
Consistently. Every week. Every quarter. Without fail. You get the idea!
A dedicated tool builds that rhythm into the infrastructure of how you work. Your weekly meeting has a structure. Your rocks have owners and due dates that everyone can see. Your scorecards show leading indicators so you can course correct before a problem becomes a crisis.
I’m a bit of a fitness buff, and I liken this to the difference between knowing you should go to the gym and having a personal trainer waiting for you at 7am.
The appointment makes it happen consistently. Otherwise I’d stay in bed.
The third thing is systematic issue resolution.
Most growing businesses have an issues list of sorts. It’s just that it lives in the founder’s head and keeps them awake at night. Or it gets discussed in corridors. Or in the worst case, festers quietly until something breaks.
A structured issue-solving process – Identify, Discuss, Solve – sounds almost childishly simple. But when it’s embedded in a tool that your whole leadership team uses every week, something interesting happens.
People start raising concerns before they become catastrophic.
You move from firefighting to prevention and that shift is enormous.
The fourth thing – and this is the big one for founders – is that it helps you scale leadership beyond yourself.
Because the whole point of implementing an operating system is to build a business that doesn’t require you to be involved in every decision.
When your processes are documented, your accountability chart is clear, and your team can see exactly what’s expected of them, they start making decisions within their defined roles.
They do this without asking you first and without waiting for permission.
The software tool becomes the scaffolding that lets other people lead. And that’s how you stop being the bottleneck.
The last thing is that it replaces gut feelings with data.
Anyone that’s worked with me knows I’m a big believer in founder intuition. But that intuition doesn’t scale. And it’s very hard to hold someone accountable to a feeling.
Measurables and scorecards give you objective metrics. They make it immediately visible when something’s off-track.
And over time, they build a culture of transparency that isn’t dependent on any one person’s instincts.
But here’s where it can go wrong with software for your BOS
I’ve seen these few mistakes so often over the past four years they’re worth calling out. Because they’re all entirely avoidable.
The first mistake is what I call tool worship.
A founder gets excited about the software, implements it across the business, and then wonders why nothing’s changed.
The software tool is not the transformation. That’s so important I even underlined it, which is a first for Build I think.
The transformation is the behavioural change – the discipline of running your meetings properly, of setting and completing rocks, of having honest conversations about what’s working and what isn’t.
I’ve seen teams go through the motions in their weekly meetings without any genuine engagement or accountability. Everyone’s ticking boxes but nobody’s actually committed.
The system is only as good as your commitment to it. And leadership has to model that discipline first. If you’re not taking it seriously, why would anyone else?
The second mistake is over-engineering.
Founders who love systems have a tendency to track everything:
Fifteen metrics on the scorecard. Eight rocks per person per quarter. Processes documented down to the level of which font to use in customer emails.
This creates a ton of bureaucracy and doesn’t really add much on the clarity front.
And we all know that bureaucracy is the enemy of the speed that got you here in the first place.
Start simple, get some consistency then refine.
The vital few indicators that actually matter are almost always obvious. Revenue, pipeline, customer satisfaction, cash, plus one or two operational metrics specific to your business.
You don’t need fifteen. You need five or six that you look at every single week.
Less is genuinely more here.
The third mistake is letting it slip when things get busy. This one breaks my heart a little, because it’s so predictable.
You implement the system. The first quarter goes brilliantly. Everyone’s engaged. Rocks are getting done and meetings feel productive.
Then Q2 hits and there’s a big client issue. Or a key hire falls through. Or you’re fundraising. Or….well, you know – scale-up life happens.
And the weekly meeting gets pushed. Then cancelled. Then never properly restarts. Scorecards stop getting updated. Rocks carry over from one quarter to the next without anyone really addressing it.
And faith in the whole BOS evaporates. Because if the leadership team doesn’t treat it as sacred, nobody else will either.
Here’s what I tell every founder I work with: the operating system meetings are not optional when you’re busy. That’s precisely when you need them most.
When everything’s on fire is exactly the moment you need a structured hour to step back, look at the data, and decide what actually matters.
Choosing a software tool for your BOS
There are a few software tools out there you can use for your BOS that, unlike generic project management tools, are built specifically to help you run your operating system.
I’m very happy to point founders towards MonsterOps as it gets the balance right between the features that really make a difference when implementing a BOS. It avoids the feature bloat and complexity that comes with some of the well known BOS tools out there.
It helps you holds your team accountable, maintains your meeting cadence, and makes the whole framework feel sustainable rather than a burden to manage.
Take something as simple as your weekly meetings (L10s or whatever you call them)
MonsterOps includes a customisable agenda structure with section timers.
That means everyone knows exactly where you are on the agenda, how much time is left and what isn’t getting the attention it deserves.
There’s no more rushing through issues because nobody’s keeping track of time. I find it’s little things like this that make the difference in practice when it comes to adoption.
I know the founder at MonsterOps actually uses it to run two companies and an agency simultaneously.
He told me his own team was sceptical at first but they came around quickly because the structure actually made them feel more empowered, not constrained
In case you haven’t guessed by now, adoption is where most operating systems die. The team at MonsterOps have made that their first priority by keeping it simple enough to use and roll out without any training.
Because it’s separated from your project management stack, it stays clean. It tells you and your leadership team exactly what needs to be done for the company to move forward.
And if you’re already recording your meetings with something like Fathom or Otter, you can paste the transcript straight in. Your meeting notes get captured inside the system where they actually belong.
It wouldn’t be 2026 if I didn’t mention AI too. It has a built-in AI agent that you can query (including mid-meeting) to pull up past decisions, scorecard trends or team productivity data.
The longer you run your BOS inside MonsterOps, the more useful those answers become.
(I should point out that this issue has been generously sponsored by my friends at MonsterOps, here’s a quick link so you can see more about the tool)
A few things to reflect on
If you’re running a business operating system already, ask yourself honestly:
- Is your tool (if you have one) helping or has it become just another thing people ignore?
- Are you tracking the vital few metrics or have you buried your team in data?
- When was the last time you cancelled or significantly shortened your weekly leadership meeting?
- Do people actually use your tool or do they try to work around it?
And if you haven’t implemented a dedicated tool yet – if you’re still running your operating system from spreadsheets and memory – it might be worth asking whether that’s really working.
Or whether you’ve just got used to the friction?
The tool won’t save you. But the right tool, used with genuine discipline, can be the difference between an operating system that transforms your business and one that quietly fades away in a shared Google Drive.
Introducing MonsterOps
This issue of Build is kindly sponsored by my friends at MonsterOps. I said yes to this sponsorship because I love what they’re doing and their mission to help as many companies as possible experience the benefits of using a BOS. They have a very generous free plan for small companies, a very reasonable flat fee for larger ones and loads of helpful features.
Get more like this from Simon in your inbox
Build ditches startup hype to deliver raw, practical wisdom for founders about leading high growth businesses. Just straight talk from a fractional COO who’s seen every mistake, every shortcut and every hard truth founders have to face between start-up and scale-up.
“Great email. Thanks. It’s like you can see into the heart of my organisation. Sometimes what you send it so bloody timely it’s scary.”
“Timely and pertinent once again. I honestly don’t know how you do it!”
Join more than 1,000 founders learning how to scale without losing their minds, their team or their company culture.
Sign up now to get Build in your inbox.

