It fails because nobody is holding the compass.

A software company lives inside its tools, so it staffs people to watch them. A company with real moving parts, trucks, warehouses, crews, production lines, bolts tools onto a physical business. Technology is a supporting actor, so it gets managed like the phone bill. Then, one reasonable purchase at a time, it quietly becomes the thing your margin, your customer experience, and your key people all depend on. Nobody decided that. It just happened, and nobody was assigned to notice.

Across the companies we work with, the damage shows up in four recognizable ways. We map them to the four points of a compass:

None of these is a technology problem. All four are ownership problems, and every one of them is fixable without buying anything.

This paper walks through each direction: the pattern, why it happens at companies like yours, and what good looks like. Each chapter ends with a single gut-check question. When you’re ready for the full reading, the Compass Score, our free twelve-statement assessment, takes three minutes, scores you 0–100 across all four directions, and shows your results immediately. A well-run company scores 85 or better. That’s the rubric talking, not a sales pitch.

You can read a P&L upside down from across a conference table. You know your margin by heart, your top customers by name, and what every truck in the yard cost you. Now try this question: what is your technology for? Not what it does. What business result is it supposed to produce, system by system, and who in your company is accountable for producing it?

In our experience that question stops the room. Not because CEOs of companies with moving parts are careless, but because at companies like theirs, nobody’s job is to have the answer.

Here’s the pattern. At a software company, technology is the product, so the whole leadership team watches it. At a distributor, a manufacturer, a contractor, a logistics operation, technology arrives sideways: a dispatch system bought to solve last year’s chaos, an accounting package the controller inherited, a CRM one sales manager championed, a dozen subscriptions nobody remembers approving. Each purchase was reasonable. Nobody chose the pile. And the pile is now load-bearing: it touches every order, every invoice, every customer interaction, and a growing share of your cost structure.

Managed things get watched by owners. Unmanaged things drift. Technology at moving-parts companies drifts in four distinct ways, and they compound quietly, which is why we reach for a compass instead of a checklist. A compass doesn’t tell you how sophisticated you are. It tells you whether you’re pointed where you think you’re pointed, and drift of a few degrees, over enough miles, puts you in a different state.

The four directions in this paper are the four ways we see companies lose their bearing: North, when no one owns direction; East, when execution misses the promise; South, when money sinks without a sound; and West, when the team routes around the tools. They rarely arrive alone. A company weak on North almost always develops a South problem, because spending nobody aims is spending nobody watches.

One note on honesty, because it matters to how you should read this. The Compass Score is a self-assessment. It measures your answers, not your infrastructure, and its results are directional, pun intended. That’s the point. The gap between what a CEO believes about its twelve statements and what an honest look would show is itself the finding. Most of the CEOs we talk to don’t need a forensic audit to get their bearing back. They need the right twelve questions, asked plainly, with no vendor in the room hoping for a particular answer.

That last part is worth saying twice. Compass Left doesn’t sell software, doesn’t resell licenses, and doesn’t take referral fees from anyone who does. We have nothing to gain from any answer you give except an accurate one.

Every system in your company was bought for a reason. Ask what result each one is supposed to be producing now, this year, in dollars or hours or customers, and the reasons evaporate. The dispatch system exists because dispatch was a mess in 2019. The ERP exists because the old one was worse. That’s history, not direction.

Direction problems hide behind two respectable-sounding habits. The first is the budget habit: next year’s technology spend is last year’s plus a few percent, which means your tech plan is a photocopy of a photocopy, aimed at whatever the business needed years ago. The second is the delegation habit: “someone handles IT.” Look closely at what that someone actually owns and it’s uptime, passwords reset, printers printing, the server humming. Uptime has an owner. Outcomes don’t. Those are different jobs, and the second one is the one that grows your company.

When nobody inside owns direction, direction doesn’t go unowned. It transfers to the people who show up with a roadmap: your vendors. You buy what they release, adopt what they sunset you into, and renew what they send. Every one of those companies is well run, and every one of them is steering toward their goals.

At a moving-parts company, technology ownership falls into a gap between three people. The controller sees every invoice but can’t judge what the systems do. The ops lead lives in the screens all day but never sees what they cost. And the CEO sees neither, because nothing about technology arrives on the CEO’s desk until something is on fire. Software companies close this gap with a CTO. At your size, that’s not a full-time job, so the job simply doesn’t exist, and the gap stays open for years.

Direction doesn’t require a technologist. It requires the same discipline you already apply to trucks and people:

• Every major system has a named result and a named owner. One page: system, cost, the business result it exists to produce, the person accountable. A line you can’t fill in is a finding, not a formatting problem.
• The technology plan is written after the growth plan. Decide where the business is going next year, then ask what has to be true of your systems for that to happen. Spending flows from goals, not from last year’s line items.
• Someone owns outcomes, not just uptime. Inside or outside, part-time or fractional, a person whose job is the question “is this pile of systems taking us where we’re going?”

You’ve lived this one. A system gets chosen after a demo that made everyone in the room a believer. Then the rollout starts, and time does something strange: the project is “almost done” for months. The go-live slips once for data, once for training, once for a reason nobody can reconstruct. The budget grows a change order at a time. And when the system finally turns on, it’s running the basics, while the capability that actually justified the purchase, the real-time job costing, the automated scheduling, the customer portal, sits unconfigured, waiting for a phase two that never comes.

There’s a quieter execution failure underneath the loud one. Somewhere during every rollout, one person becomes the only human being who understands how the new system connects to everything else. Usually it’s an ops lead or an office manager, competent, loyal, and buried. The company’s systems now run on their memory. That’s not resilience. That’s a single point of failure with a nice personality.

The moment the contract is signed, the two people who cared most about the promise both leave the room. The salesperson’s job is done, and yours is, too, because you delegated the rollout, reasonably, to people who already had full-time jobs. The vendor’s implementation team is paid to close tickets and hit their go-live date, not to deliver the outcome from the demo. Your internal lead is doing the rollout in the margins of their real job. Between those two, there is no one whose success is measured by the sentence “the thing we were promised is now true.” At larger companies, that’s a project owner with real authority. At yours, that role went unfilled, not by decision, but by default.

• The promise goes in writing before the contract does. The specific claims from the demo, in plain English, with numbers where possible. The rollout is scoped against that document, and so is the vendor.
• One named owner, with time actually cleared. A rollout done “in spare time” is a rollout done twice. If nobody can be freed up, that’s a fact about the timeline, not a reason to pretend.
• Go/no-go gates instead of drift. Fixed checkpoints where the project proves it’s on track or the plan changes. “Almost done” is not a status.
• Written down beats remembered. How systems connect, who to call, what happens monthly, on paper, so a resignation is a personnel event, not a systems event.

Here is a number you know: what you pay your best driver, your best machinist, your best foreman. You know it to the dollar, because you signed off on it, and because if it were wrong by 10% you’d feel it.

Here is a number you almost certainly don’t know: what you paid for software last month. Not the round number from the budget. The real one, the sum of every seat, subscription, module, renewal, and per-user fee that hit your cards and your AP ledger across every department. We’ve yet to meet a CEO of a company with real moving parts who knew that second number within 20%. That’s not a criticism. It’s a design feature, and it wasn’t your design.

Software waste survives precisely because it never shows up wearing that name. It shows up as three perfectly ordinary things:

Zombie licenses. Someone joins, and getting them a seat in every system is urgent, so it happens day one. Someone leaves, and removing their seats is urgent to exactly no one. The email account gets shut off because IT has a checklist for that. The $89-a-month seat in the dispatch system just keeps billing.

Two systems, one job. Sales bought a tool to track customers. Two years later, operations bought a different tool that, among its other features, tracks customers. Nobody chose to pay twice for the same job; the overlap arrived one reasonable purchase at a time. Overlap is worse than double cost, because now the customer data lives in two places, and neither one is right.

Contracts that renew themselves. Auto-renewal is the default in almost every software agreement, and the renewal notice, when there is one, goes to whoever’s inbox was on the account five years ago. The vendor’s business model is quietly betting that you’re too busy to read it. On companies like yours, that’s usually a winning bet.

None of these requires anyone to do anything wrong. That’s the point. Sinking money isn’t a discipline problem. It’s what happens by default when spending is designed to be forgettable and nobody’s job is to remember it.

You don’t need software to manage your software. You need four habits, none of which takes a technical person:

• A one-page inventory. Every system, what it costs, what business result it exists to produce, and who owns it.
• A renewal calendar. Every contract’s renewal date, 60 days ahead of it, in front of someone with the authority to cancel. Auto-renewal stops being a trap the moment someone is looking.
• Offboarding that includes licenses. The same checklist that collects the truck keys and kills the email collects the seats. Day one, not eventually.
• One job, one system. When two tools do the same job, pick one and kill the other, not just for the cost, but because duplicated systems mean duplicated truth, and duplicated truth is how the wrong number ends up in front of a customer.

A company that does these four things doesn’t have a software-waste problem. It’s that direct.

You bought a system that does a hundred things. Your team uses thirty of them, and built spreadsheets for the rest. Data moves between your systems the old-fashioned way: someone reads it off one screen and types it into another, every day, as a job. And when something breaks, you find out the way no CEO wants to find out, from a customer, on the phone, annoyed.

Workarounds are the hardest direction to see from the corner office, because every workaround is locally brilliant. The spreadsheet exists because the scheduling module was clumsy and the office manager was clever. The re-typing exists because connecting two systems was somebody’s someday project. Each workaround saved minutes on the day it was born. Then it settled in, invisible from above, and started collecting rent: hours of duplicate entry, errors introduced at every re-keying, and a picture of the business that exists only in files on one person’s desktop.

The customer-detection problem is the same failure at its most expensive. Your team almost always knows about a tech problem before it reaches a customer. Whether they say so depends on what happened the last five times they mentioned one. If reporting friction changes nothing, people stop reporting, and route around instead. Silence isn’t health. Silence is your team having given up on the tools, politely.

Workarounds are rational for the person who builds them and invisible to everyone above them. No one asks permission to open a spreadsheet. Each one is too small to escalate, and there’s no one to escalate to, because, as with everything else in this paper, watching the whole picture is nobody’s job. So the gap between what your systems can do and what your team actually does with them widens a little every month, and you’re paying full price for the whole system either way.

• Surface the shadow systems. Ask each department one disarming question: “what spreadsheets would hurt us if they broke?” Then either kill each one (the real system does this, let’s configure it) or promote it (this is a real business process, let’s make it official and owned).
• Kill the re-typing. Anywhere a human moves data between systems by hand, on a schedule, you’ve found either a missing integration or an unnecessary system. Both are cheaper than the errors.
• Make friction reportable. A standing, low-ceremony way for the team to flag where the tools fight them, and visible follow-through, so the reports keep coming to you instead of to your customers.
• Review utilization before buying anything new. The capability you’re about to buy is often sitting, already paid for, in a system you own.

Four directions, one diagnosis. Nothing in this paper is a technology problem. Un-aimed spending, drifting rollouts, silent leaks, quiet workarounds: every one of them is what a normal, well-run physical business gets by default, because every party involved owns a piece and nobody owns the bearing. Your vendors own their products. Your controller owns the invoices. Your ops lead owns the screens. The direction of the whole, where all of this is taking your company, belongs to no one until you assign it.

That’s also the good news. Companies wait on technology problems because they expect fixing them to mean a big check and a painful conversion. But ownership problems respond to ownership. A one-page inventory, a renewal calendar, a named owner per system, a written promise before the next contract: none of it requires buying anything, and most of it starts working the week it starts existing.

The first step is smaller still: find out where you actually stand. Three minutes, twelve statements, an honest bearing. Competitive CEOs tend to remember their score, and the direction that cost them. The next section shows you how.

The Compass Score is deliberately simple, and deliberately transparent. Twelve plain-English statements, three per direction, each rated 1 (“not true”) to 5 (“absolutely true”). No jargon, no trick questions; every statement is the kind of thing you could answer about your own company in ten seconds, honestly, if not always comfortably. Your ratings convert to a 0–100 score. There’s no black box and no weighting scheme; you could compute it on a napkin, and we’d encourage it.

Your score places you at one of four bearings:

One benchmark, and it’s one we can defend: a well-run company scores 85 or better. That isn’t survey flattery; it’s the rubric’s own math. Scoring 85 means averaging about 4.4 across all twelve statements, meaning nearly every statement in this paper is simply true at your company. Rating yourself all 4s, “mostly true across the board,” lands you at 75, still Drifting. The bar is high because the statements are basic. There’s nothing exotic on the list; it’s the technology equivalent of “we reconcile the bank account.”

The single most useful output isn’t the total. It’s your weakest direction, because each direction has a different first move: North starts with assigning ownership. East starts with rollout discipline. South starts with the inventory and the renewal calendar. West starts with surfacing the shadow spreadsheets. Working your weakest direction first is how a score becomes a plan.