When I look at a company, I do not see what the leadership team sees. They see departments, quarterly targets and a stack of tools. I see a production system, because twenty-five years of building software under load trains you to look for how systems fail. One of those systems took an enterprise sales platform from $0 to $500M in four years, and earlier I built a message switch serving the FBI, the DOJ and state law enforcement agencies. In that work, finding the weak point before it fails is the job.
Here is the audit. These are the findings I look for first, in the order they would appear in the report.
Finding one: a single point of failure, load-bearing and unbacked-up
Every audit starts by mapping what breaks when each component breaks. In a mid-market company the map is usually short, because a handful of people carry functions the organization believes are institutional. The one person who understands how pricing exceptions get approved. The account lead whose relationships are the account. The operator who knows which spreadsheet feeds which report.
Engineers call this a single point of failure, and a system with one is classified as fragile however well it runs today. Uptime is not the test. The test is what happens under fault: a resignation, a medical leave, an acquisition, a rapid doubling of volume. Redundancy costs less than the outage every time, and the outage is certain across enough days.
Finding two: the most expensive processors are running the cheapest jobs
Engineers obsess over what runs where. Batch cleanup jobs do not run on the most powerful and most expensive machine. Every workload goes to the cheapest resource that can execute it correctly.
Organizations invert this rule daily. Senior people spend their cycles on reformatting reports, chasing approvals, answering the same internal question for the fortieth time, and moving data between systems that do not talk to each other. The workload only they can do, judgment, waits in the queue behind it. In computing that is a scheduling failure. In a company it is called a full calendar.
Finding three: dark data everywhere
An engineer inventories data the way an accountant inventories cash. Mid-market companies are richer than they know: years of closed-lost notes that encode why deals die, a list of dormant accounts that each represent a pre-built trust relationship, support transcripts that predict the next hundred questions, pricing history that shows exactly where margin leaks.
Data that exists and produces no value is called dark data, and finding it is good news, because activating it costs a fraction of acquiring anything new. Nothing has to be created. The assets exist and are waiting for a system to run them.
Finding four: the expertise is unversioned
Here is the finding that stops a code review cold. The company's core intellectual property, the way its best people think through a deal, a design, a customer problem, has no existence outside the original copy. It is not written down in executable form, not encoded in intake, not embedded in tools, and not transferable to a new hire without years of apprenticeship. In engineering terms, the most valuable logic in the building is running in production with no source code, no documentation and no backup.
It surfaces at every retirement and every acquisition, when decades of refined judgment get valued at the price of the furniture. Expertise this structured can be encoded: into assessments, decision-support tools, workflows and knowledge systems that scale the judgment without cloning the person. Uncompiled, it is rented. Compiled, it is an asset.
Finding five: humans are the middleware
In most companies, people are the integration layer. The CRM does not talk to billing, billing does not talk to support, and support does not talk to the renewal forecast, so a person copies information from one screen to the next. Every handoff adds delay, errors and a cost nobody budgeted.
Engineers treat a manual handoff as a defect with a price. Count the handoffs in your quote-to-cash process, then count them again in renewals. The number is usually higher than anyone guessed, and each one is a place where a system can do the work.
The part that is not a deficiency
An honest audit reports strengths, and this one is real: the product works. The company has customers, revenue and a reason to exist. Engineers rarely get handed a system with a core function this sound. What is fragile is the wrapper around it: redundancy, capture, leverage and flow. Wrapper problems are the easy kind. Encoding, automating and distributing the reasoning of people who already know their craft is a solved class of problem. It is engineering.
The audit on one page
| Finding | The engineering name | What it costs | The fix |
|---|---|---|---|
| Key functions route through a few people | Single point of failure | Fragility, no scale, lower enterprise value | Systematize one function per quarter |
| Senior talent doing clerical work | Scheduling failure | The gap between loaded cost and judgment value, every day | Move capture and assembly to systems |
| Idle accounts, notes and transcripts | Dark data | Unactivated revenue and insight | Reactivation and analysis pipelines |
| Expertise lives in heads | No source control, no backup | Value that leaves with the person | Encode into workflows and knowledge systems |
| Humans moving data between tools | Manual integration | Delay, errors, unbudgeted labor | Connect the systems, remove the handoffs |
Figure 1: The five findings. Each is architecture, and architecture can be rebuilt while the business keeps running.
The recommendation
Every audit ends with one. Stop treating these findings as personality flaws or time-management failures. They are design, and design can be changed one component at a time while the business runs, starting with the failure that costs the most.
The Leverage Diagnostic on this site is a six-minute version of this audit. It scores six areas of your company and prices the gap, so the first component to fix is chosen by the numbers.