Notes 11 May 2026 · 5 min read

Why your office manager is your most expensive software developer.

Your office manager is a software developer. They might not call themselves one. They almost certainly don't have a job title that says so. But if you actually look at what they do all week, a significant chunk of their job is building, fixing, and maintaining software inside your business.

It just isn't called software inside your business. It's called “the master spreadsheet” or “the quote tracker” or “Becky's system.”

Walk through any mid-market construction office and look at what's holding the operations together. You'll find a quote tracker with complex formatting that nobody else fully understands, a variations log with formulas linking to four other sheets, an email routing setup that handles subcontractor messages automatically, an automation that copies invoice data into a billing spreadsheet, and a project database the office manager built one evening because the project management tool she was given didn't actually let her see the things she needed to see.

This is real engineering work. It's just done by someone whose job description says “office manager” and whose pay reflects that. It's also done in evenings and lunch breaks because nobody officially asked for it. And it's done without a single line of documentation, because she knows how it works and that's been good enough so far.

That's where the cost hides.

Start with the time. A spreadsheet that took two weeks of evenings to build, plus thirty minutes a week to maintain, plus the occasional hour to fix when something breaks, adds up to a couple of hundred hours a year. That's not free time. That's time the office manager isn't spending on the actual job she was hired to do.

There's also the bottleneck. Because she built it, only she can change it. When something needs adjusting, it goes on her list. When the rules need updating because the business has changed, it waits until she has time. The system that was meant to make the office more efficient quietly becomes the slowest part of it, because every change routes through one person.

The bigger cost is the risk. Your office manager has been at the business eight years. Everyone knows that. What nobody quite has a plan for is what happens to the quote tracker if she leaves. Or the variations log. Or the email routing. Or any of the dozens of small systems that have been built up over years, none of which exist anywhere except in her head. If she gives notice tomorrow, the business has three months to reverse-engineer eight years of quiet engineering work. Most businesses can't do it.

And the cost nobody sees is the ceiling. The office manager is good. But she's not a full-time developer. She's solving the immediate problem in front of her, using the tools she has, in the time she has available. The spreadsheet that holds it all together is genuinely impressive given the constraints, but it's still a spreadsheet. It will never do certain things. The business has built itself a ceiling and nobody has noticed because the ceiling is exactly where her last upgrade left it.

I'm not suggesting any of this is the office manager's fault. The opposite. She's done the business a real service by stepping into a gap that nobody else was going to fill. Most construction firms would be in much worse shape without the person who quietly took it on themselves to make the systems work. The right response is recognition for the engineering she's done, not a redundancy notice.

But “the office manager builds it” stops being a sustainable answer at a certain size. Once a business is past the point where one person can hold the whole operational system in their head, the spreadsheet engineering starts to consume time the office manager doesn't have, hold risk the business can't insure against, and limit growth in ways the MD can't see. It's worked because there's been no alternative, not because it's the right shape.

There's a better way to think about it. The office manager already knows what the business needs. She's proved it by building it herself. The question is whether to keep using her hours to maintain a system that only she understands, or to capture what she's built into proper tools the whole office can use and that don't depend on one person being there.

The first step in any custom software engagement worth doing in a construction firm is sitting down with the office manager and reverse-engineering what she's already built. Not because she got it wrong. Because she got it right, in the limited tools she had available, and the next version should do the same thing without the limits.

If you've been quietly relying on your office manager to be your software developer, you're not the only one. What matters now is recognising the engineering work she's done, and thinking about what happens to your business when the engineer eventually leaves.

If that's a question you don't have a good answer to, get in touch.

Work with me

Recognise the pattern? Let's talk.

I take on a handful of new clients a year. If any of this echoes your business, let's start the conversation.