In which the function refuses to fit on the org chart.
The Invisible Engine: Why BizOps Builds Belief, Not Just Plans
Borrowed Authority
BizOps can't force anyone to do anything. The gap between the influence the role carries and the authority it holds is where most of the interesting problems live.
Every model, framework, planning template, and definition you propose depends on voluntary adoption. A team can opt out without ever saying no, and teams are very good at this. They fill in your template with placeholder numbers while keeping the real numbers in another spreadsheet, or sometimes in the head of a regional sales director named Greg. They attend the planning meeting and hold a second meeting afterward to discuss what they truly think. They use your terminology in cross-functional settings and their own terminology everywhere else, which means the alignment you thought you achieved exists mainly in rooms where you are present. This is a smaller share of organizational life than anyone with a crowded calendar wants to admit.
What BizOps usually inherits are half-built systems. A QBR template nobody fills in with conviction. An "operating cadence" announced with great enthusiasm in September and still moving through implementation in March, its kickoff slides referencing a fiscal year that ended two quarters ago. KPIs defined during the Series B and never checked against anything resembling the current business. A Slack channel called #revenue-operations with three members, two of whom have left the company, and a pinned message linking to a Google Sheet that requires access permissions nobody knows how to grant.
The scaffolding looks solid from a distance. You can point to it in a board deck and say, "We have a process." Then someone leans on it.
I once inherited a planning process that looked comprehensive on paper. Every department had a template. The timeline covered the full quarter. Twelve important metrics came with shared definitions, and an executive sponsor genuinely cared about the outcome.
The templates had been designed eighteen months earlier. Since then, the company had shifted its business model, acquired another company, reorganized two departments, and changed CROs. Product lines that no longer existed still had their own tabs. The timeline assumed a board schedule that had moved. Three metric definitions were subtly wrong in ways that became visible only when someone tried to reconcile them across departments.
Everything looked functional. Very little survived contact with the company as it currently existed.
This is the environment BizOps enters: systems built for an earlier version of the organization, shaped by tradeoffs nobody fully remembers, and still carrying enough institutional weight that replacing them requires more than demonstrating that they are broken. Someone has to decide what deserves repair, what needs rebuilding, and which parts are strange for a good reason.
That last category is larger than it first appears.
The Way In
The way in is usefulness, usually the kind that arrives before anyone has time to admire the framework behind it.
A headcount plan that matches both the budget and what recruiting can plausibly fill. A forecast that explains why last quarter missed and which assumptions could cause the same miss again. A pricing model that handles most edge cases without requiring the CEO to arbitrate whether a thirty-seven-month contract qualifies for the strategic exception everyone vaguely remembers approving. A board deck where the appendix and narrative slides tell the same story, which sounds like a low bar until you have watched three executives discover, in real time, that they brought different versions of revenue to the same meeting.
The work is granular and frequently tedious. Much of it resembles debugging operations: tracing definitions, testing assumptions, reconciling sources, and learning why an approval that should take two days routinely takes eleven. These are rarely the assignments that produce the most impressive strategy slides. They are often the assignments that determine whether the strategy can happen.
Usefulness buys access. People start bringing you problems while the outcome is still unsettled. That timing matters more than the prestige of the room. A VP mentions a possible restructuring before announcing it, leaving enough time to model the effects on three neighboring teams. A product lead raises a dependency before it reaches the roadmap, allowing planning to account for it rather than discovering it halfway through the quarter. A sales leader shares a forecast concern while it can still change hiring, rather than after the recruiters have opened twelve roles.
Early problems can be shaped. Late problems arrive with a communications plan.
Access alone does not guarantee influence. Access without trust is surveillance from the organization's perspective and performance from yours. You can attend every executive meeting in the company and still function primarily as the person who knows where the latest deck lives. The transition happens when people begin involving you for judgment rather than production. They ask what you think before asking what you can build.
Usefulness gets you invited. Repeated usefulness, paired with judgment, begins to create trust.
Building Belief
Belief shows up in behavior.
A sales manager updates the forecast without a reminder because they understand how it feeds the hiring plan. Product includes cross-team dependencies in its roadmap after seeing Engineering change sequencing when those dependencies surface early. Finance retires a shadow model because the official one has been right, or at least usefully wrong, for three quarters in a row.
"Usefully wrong" captures something important about how operational systems earn trust. A forecast does not need to be perfect. Perfection is a promotional concept invented by people who have never had to forecast a quarter involving customers, competitors, sales representatives, procurement departments, holidays, exchange rates, or February.
A useful forecast makes its errors legible. The assumptions are documented. The inputs are visible. When the result misses, the organization can trace why. Perhaps expansion revenue was overstated because the renewal assumption did not account for a pricing change. Maybe new-logo timing assumed legal reviews that no longer matched the customer mix. The miss becomes diagnostic. People learn something more precise than "the forecast was off," then adjust the system before repeating the same error with fresher formatting.
A hiring plan matters when recruiters and managers believe it can be executed. A pricing framework works when the sales team recognizes its actual deal landscape inside it. Planning templates receive honest answers when the people completing them trust that accuracy will lead to useful decisions rather than a ceremonial interrogation about why every department is not exceeding plan.
Systems become real through use. People stop working around them. They defend the methodology in rooms where BizOps is absent. A new employee learns the process from a colleague rather than from the person who built it.
That transfer is the clearest measure of belief. A director explains the planning process to their team and can answer the questions that follow. Sales ops walks a skeptical new hire through the forecast methodology, including the reasoning behind it. The CFO stops requesting a backup model because maintaining two versions of reality has finally become more frightening than trusting one.
These behaviors accumulate slowly. Each one represents somebody deciding that the system helps them do their work. Once enough people reach that conclusion, adoption no longer depends on persuasion. Participation becomes the ordinary choice.
Organizational Debugging
Every company has patterns that repeat quarter after quarter despite being identified, discussed, post-mortemed, and theoretically fixed.
Deals slip during the final two weeks. Headcount plans drift away from actual hiring. Engineering timelines miss by roughly the same margin. Product launches generate support volume nobody anticipated, although support anticipated it and wrote this down in a document nobody opened.
The patterns are rarely mysteries to the people inside them. Each team can describe its local problem with great precision. What remains harder to see is the system producing all of those local experiences at once.
I once spent two months trying to understand why deals consistently slipped near the end of every quarter. Sales attributed the problem to buyer behavior. Finance blamed pipeline hygiene. The CRO preferred process discipline. Every theory sounded plausible, and each one placed the failure somewhere else.
The actual cause came from three processes that no single team could see together.
Legal review took an average of nine business days while deal timelines budgeted five. Pricing approval required a VP who routinely traveled during the final week of the quarter. A clause in the contract template triggered procurement review at the customer's company, adding another week that nobody included in the close date.
Each fact was known. Legal knew its turnaround time. Sales knew when the VP traveled. Customer procurement teams knew what the clause did. Nobody held all three pieces at once.
The slip emerged from processes designed independently and never reconciled.
This kind of diagnosis is what I think of as organizational debugging. BizOps can move across enough boundaries to see interactions that remain invisible from within any single function. Sales understands the sales process. Legal understands legal review. Finance understands approvals. The failure often lives in the handoff between them.
The uncomfortable part is that the diagnosis sometimes points back toward systems you helped create.
The pricing approval workflow that added a week to every deal was mine. I designed it six months earlier because the CEO was worried about margin erosion. The five-day legal assumption was mine too. The general counsel told me it should take five days, and I accepted that because I wanted to preserve a relationship with a stakeholder I knew I would need later. I also knew the contract clause might deserve a closer look during the last template revision. I let the revision ship anyway because the project was already late, over budget, and exhausting everyone involved.
Each choice was defensible. Each contributed to the pattern I later spent two months diagnosing.
The debugger contributed to the bugs.
Every process creates constraints. Every guardrail redirects behavior. A control installed to prevent one failure can generate a different failure six months later, usually with a new name and its own Slack channel.
Organizational debugging requires enough distance to find the pattern and enough honesty to recognize your own fingerprints when they appear.
How It Erodes
Operational systems usually erode through local adaptations.
Finance adjusts assumptions in its own spreadsheet because the shared model cannot handle multi-year deals and nobody has approved the work required to fix it. The workaround helps Finance meet a deadline. It also creates a second version of reality.
Other teams make equally reasonable choices. Product develops its own definition of "on track." Sales changes forecast categories to reflect how managers actually call deals. Customer Success adds a private risk field because the official health score misses the customers everyone is worried about.
Each adaptation solves a real problem. Together, they turn leadership meetings into translation exercises. The first thirty minutes of a QBR go toward reconciling numbers. Someone explains that Product's "on track" differs from Engineering's "on track." The board deck develops parallel versions, one technically accurate and another capable of supporting a sentence.
The official process often continues throughout all of this. Templates get distributed. Boxes get checked. Deadlines are met in the narrow sense that documents arrive before the meeting.
The more subtle risk appears when BizOps becomes the workaround for every weakness in the system. People send you the exceptions because you can resolve them. Models depend on adjustments only you understand. Planning runs because you remember which three teams need to be warned before the numbers change.
Being needed can resemble effectiveness for a long time. Early on, they may be identical. The distinction appears when your personal involvement becomes the mechanism holding the process together.
That dependency does not make the work selfish or misguided. It usually grows from responsible choices made under time pressure. Fix the immediate problem. Keep the quarter moving. Document it later. Train someone after the reorg. Eventually the list of things only you can do becomes evidence that the system still needs work.
The warning sign is practical: when removing one person would cause the process to become unintelligible, the process has not yet become organizational knowledge.
Rebuilding
Rebuilds rarely begin with an announcement. They start with something small enough to prove.
Pick the metric everyone argues about. Map the definitions currently in use. Find out why they differ, because at least one of the differences will come from a legitimate need rather than carelessness. Publish a source of truth and get three teams to use it. Three is enough to create a reference point without waiting for the universal rollout that will spend six weeks on stakeholder mapping and die during a reorganization.
Other teams can join when the system demonstrates that it handles their reality.
Name the previous failure specifically. "The planning process needs improvement" communicates almost nothing. A useful diagnosis sounds more like this: "The old forecast could not handle multi-year deals, which caused the same Q4 variance in two consecutive years. The new version separates contract value from recognized revenue and makes the assumption visible."
Specificity lowers the emotional temperature. People can debate whether the diagnosis is right. They can test the fix. A generalized reset asks everyone to revisit every grievance they have ever had with planning, often in the same meeting.
Make the improvement visible in terms people care about. The forecast landed within five percent. The hiring plan matched actual starts. The pricing model covered ninety percent of deal structures without exception requests. The QBR began with a decision instead of a twenty-minute discussion about which spreadsheet had the correct denominator.
These metrics will never make BizOps glamorous.
Expect stress-testing. Teams will bring every edge case they can find because abandoning a private workaround requires confidence that the shared system can hold. The sales manager with a thirty-seven-month contract across three currencies and an amendment signed during a leap year is not trying to ruin the launch. They are checking whether the system recognizes the world they work in.
Treat those challenges as design input. Adapt where the edge case exposes a genuine flaw. Hold the line where the exception would make the model incoherent. Explain the difference.
Trust returns through that sequence: a claim, a test, a visible response. Skepticism remains, though it can become useful. People who remember the old failure ask better questions. They inspect assumptions. They notice when workarounds begin to reappear.
What a rebuilt system gains is resilience. People understand where it is strong, where it is approximate, and how to challenge it before a local workaround becomes a competing reality.
Enough visible fixes, repeated across enough cycles, and the system begins to hold again.
The Disappearance
When BizOps works well, the system stops drawing attention.
Definitions hold. Planning cycles complete without drama. Forecasts converge across teams rather than diverging. The board deck has one version. Meetings begin with what to do rather than whose number is right.
The proof is a particular kind of silence. People are still questioning assumptions and debating decisions. They have simply stopped debating whether the process itself exists.
I have a test for this that I think about often. I call it the vacation test, though I have never had the courage to run it deliberately.
Step away during an important planning moment. Take a week off during budget season. Stop answering every question immediately. When you return, look at what happened.
Perhaps the process stalled. That means too much knowledge still lives with you.
Maybe it ran, though the outcome required cleanup. The foundation exists, while maintenance remains concentrated.
The best result is more ordinary. The process ran. People made reasonable choices. Someone improved a tab or clarified a definition, and nobody thought to report the achievement because nobody considered your absence the central fact.
That outcome can feel stranger than the first two. Much of professional life trains us to demonstrate value through visible involvement. Operational maturity asks for decisions moving without escalation, information surviving handoffs, and people resolving familiar problems without locating the person who originally built the mechanism.
The clearest signal appears in language.
People stop asking, "What does BizOps want?" They start saying, "Based on our model..." or "According to our planning process..." Borrowed authority has become shared belief.
The model is no longer BizOps' model. The template belongs to the teams using it. The definitions survive because people understand them well enough to teach, challenge, and improve them.
The people who use the system have forgotten, or never knew, that someone had to fight for it.
Decisions move. Tuesday feels ordinary. By that point, the belief lives in the system itself.
Footnotes
The quiet opt-out is one of the stranger achievements of organizational life. It allows a person to comply with a process and reject it simultaneously.
A loud refusal creates a useful problem. Someone says, "This process does not work for us," and the disagreement becomes available for inspection. A quiet opt-out looks like success. The template arrives on time. The meeting has excellent attendance. Every required field contains something.
Meanwhile, the actual work has migrated elsewhere.
The forecast in the shared system is ceremonial. The forecast in Greg's spreadsheet is operational. Greg's spreadsheet has no documentation, a tab called "New New Final," and a formula that refers to a hidden column last edited by somebody named Kelsey in 2022. It is also the most trusted financial instrument in the western region.
This is why compliance is such a weak measure of adoption. A process can achieve 100 percent completion while losing contact with the decisions it was created to support. The green checkmark survives. Reality leaves through a side door.
Planning systems age in dog years.
One major organizational change can turn a sensible process into an artifact whose original beliefs must be inferred from its dropdown menus. A reorganization changes ownership. An acquisition introduces new products and definitions. A business model shift alters which metrics matter. The template continues to circulate because the recurring meeting still exists, and the recurring meeting still exists because deleting it would require someone to know who created it.
I have watched this cycle at several companies. The delay usually comes from treating replacement as a verdict on the original work. Yet a planning system can have been useful and still be finished. Snow tires are not a failed technology in July. They have simply become a strange way to drive to the grocery store.
Access and trust are easy to confuse because both place you in important rooms.
Access means you have the calendar invitation. Trust means people allow your judgment to alter the outcome. The difference becomes visible during disagreement. A person with access receives the latest deck and is asked to confirm the numbers. A person with trust can say that the narrative built around those numbers makes no sense.
Corporate life contains many ceremonial forms of access. You can attend executive staff meetings, sit near the CEO, and receive documents marked confidential while functioning primarily as a highly credentialed advance-slide operator.
Trust arrives when someone asks what you see before telling you what they need produced. The room may be the same. Your role inside it has changed.
Finance retiring a backup spreadsheet may be the purest behavioral signal of trust available inside a company.
Finance people do not delete backup models casually. Many maintain them with the care normally reserved for family recipes or emergency water. The official system may have twelve integrations, executive sponsorship, and a dedicated engineering team. The backup is a spreadsheet named "Actual Actuals" that one person updates at 6:10 every morning.
When the backup finally disappears, the shared system has earned something more meaningful than approval. Someone has decided they would rather depend on it than protect themselves from it.
The deal-slip diagnosis took two months, which was longer than stakeholders expected and shorter than the problem deserved.
The pricing approval bottleneck was easy to confirm and difficult to raise because the bottleneck was technically a workflow and practically a vice president on an airplane. I described the change as a "timing optimization," a phrase that allowed everyone to preserve dignity while acknowledging that revenue approvals should probably remain possible when one person crosses the Atlantic.
The procurement clause required a different kind of investigation. Nobody on our side knew what it triggered because nobody on our side had worked in customer procurement. The company had moved upmarket while the contract retained assumptions from a time when customers were smaller and purchasing involved a manager with a corporate card.
Three customer contacts eventually explained the process. Each conversation required a sales representative willing to let an operations person near the account. Often the answer exists outside your company, held by someone who has no reason to explain it unless a chain of people trusts you enough to make the introduction.
Many workflows are fossilized executive anxieties.
A required approval field may exist because, four years ago, one deal received a discount so alarming that the CEO still remembers the percentage. A weekly report may trace back to a board member who asked a difficult question during a meeting in 2021. An eighteen-step hiring process may represent a previous attempt to prevent one bad hire from ever happening again, regardless of what this does to the next two hundred candidates.
Over time, the original fear disappears while the process remains. New employees encounter the dropdown, assume it reflects timeless wisdom, and build additional processes around it. Nobody wants to remove a control without knowing what dragon it was installed to contain.
Part of debugging is organizational archaeology. You trace the rule backward, find the buried incident, and decide whether the dragon still lives there.
Official processes possess what can only be described as zombie durability.
I have seen QBR formats reference business units dissolved years earlier. Nobody presented those sections, though the slides remained because removing them would have shifted the page numbers. Planning templates asked for metrics the company no longer tracked. Teams entered "N/A" quarter after quarter, producing a valuable longitudinal record of the fact that the question had stopped making sense.
Recurring meetings are especially powerful. Once a process has a calendar invitation, it begins generating its own justification. The meeting occurs because it is scheduled. Attendance proves the meeting matters. The continued existence of the meeting supports renewing the invitation.
Somewhere inside most companies is a sixty-minute monthly meeting whose original purpose has been completely forgotten. Eight people still attend. One shares a screen. Everyone leaves with the vague sensation that governance has occurred.
A person can become the human API between systems that were supposed to integrate.
Sales sends them one file. Finance sends another. They translate definitions, correct the dates, and produce the answer leadership needs. The organization experiences a functioning process. The person experiences eleven recurring meetings and a growing conviction that nobody else understands how the company works.
This arrangement often looks efficient because the human API is faster than fixing the underlying systems. It also creates flattering evidence of importance. Questions arrive constantly. Every decision seems to pass through you. Your calendar becomes a heat map of organizational relevance.
The danger appears when volume gets mistaken for scale, or for the word Silicon Valley prefers, leverage. A well-designed system should reduce the number of times someone needs to ask the same person the same question. Otherwise you have built an integration with excellent judgment, no documentation, and no failover, running on hardware that has to sleep.
Edge cases are how teams introduce themselves to a new operational system.
Sales will produce a contract with three currencies, a usage component, a reseller, a termination option, and a handwritten side letter discovered after signature. Finance will ask how the model handles a customer whose fiscal year contains fifty-three weeks. Product will identify a dependency shared with a team that technically ceased to exist during the last reorganization but continues to own two production services.
These cases can feel like sabotage when you have spent weeks trying to build something clean. Usually they are evidence that the team has begun imagining itself inside the system. Indifference is quieter. People nod, thank you for the work, and continue using the spreadsheet they trust.
Stress-testing means the system has entered the consideration set. The challenge is to distinguish the edge case that reveals a design flaw from the edge case that should remain strange forever.
Running the vacation test deliberately is hard. The prospect of returning to find that everything ran smoothly without me can feel more threatening than the prospect of returning to find that everything fell apart.
I have gotten better at recognizing that impulse, though recognizing it and escaping it are different skills. The desire to make yourself unnecessary competes with the desire to be valued, and the desire to be valued usually wins. It is louder, more immediately rewarded, and much easier to point to during a performance review.
Companies reinforce the conflict. People receive credit for solving difficult problems, while systems receive no performance review for eliminating the need to solve them again. Someone who answers thirty questions can appear more valuable than someone whose process prevented those questions from arising.
I have benefited from that confusion. More than once, I have let a system remain dependent on me for longer than it needed to because the dependency felt like proof that my work mattered. The reasons were never sinister. There was always another deadline, another exception, another improvement I could make before handing it over. There was always one more adjustment that only I could make.
The healthiest operators I have worked with genuinely celebrate when the system runs without them. I aspire to that. I am not always there.
| Published | 20 July 2025 (1 year ago) |
|---|---|
| Reading time | 22 min |
| Tags | operations, org structure, finance |
| Constellation | The Relay |
Reply
I’d welcome your thoughts on this essay. Send me a note →
