In which a plan without belief becomes just a PDF.
Built to Shift: Why BizOps Defies Definition
The Floating Function
It is 4 PM on a Tuesday. Same spreadsheet. Third argument of the week. One tab says 182 customers. Another says 174. Sales stands by 182. Finance believes it cannot be right, although 174 may not be either. Both are defensible. Both come with screenshots. Someone has to decide which version is real enough to leave the building.
That someone is me. Or was me. Or will be someone like me next quarter, because few people volunteer to stand at the fork where two truths diverge and pick one.
The picking is the job. It rarely appears in job descriptions. What appears are phrases like "strategic planning," "cross-functional alignment," and "operational excellence," which are to the actual work of BizOps roughly what a restaurant menu is to the experience of cooking: a clean description of something far messier than the language suggests.
BizOps rarely shows up as a neat box on an org chart. Sometimes it sits under Finance. Sometimes it reports directly to the CEO. Sometimes it is scattered across teams without a shared title. Ask five people what BizOps does and you will get five answers: strike team, organizational duct tape, internal consulting arm, spreadsheet service. All partially true. None sufficient. The ambiguity is structural. The moment you define the function too cleanly, you risk smoothing away the very friction that makes it necessary.
Here is what it is actually for, at least in the version I have lived.
A CEO asks, "If growth slows, what is our real runway?"
The question is simple. The inputs are not. Burn sits in NetSuite. Forecast assumptions live in Salesforce. Hiring plans exist in Greenhouse and in a semi-private spreadsheet maintained by someone who left two months ago. Retention signals hide in support tickets and product dashboards. Every number means something slightly different depending on who pulled it.
"Headcount" means anyone on payroll to Finance. Approved roles to HR. Engineers who can ship this month to Engineering.
You cannot answer the CEO's question until you decide which version of headcount, revenue, and retention you are operating on. That decision is not purely technical. It is relational. Telling Finance their number is wrong carries a different weight than saying it answers a different question than the one currently on the table.
So you build a bridge. You reconcile definitions that should have been aligned years ago and produce a model sturdy enough to carry one board meeting. Next quarter you rebuild it because the company has shifted shape and the previous model no longer fits.
The rebuilding is the rhythm. The scaffolding is temporary by design. It holds long enough for a group of busy, politically motivated people to make a decision together. Then the company changes and the scaffolding needs adjustment again.
There is a part of this story that is less flattering.
Bridge-building sometimes means choosing the definition that is easiest to adopt rather than the one that would win a methodology argument. I've picked the customer count that a room could actually adopt, even when a cleaner definition existed on paper and would have died in rollout. I've convinced myself that “useful” and “true” were the same thing, and later had to admit they only overlap some of the time.
At one company, we carried two definitions of “customer” for months because each one answered a different question. One definition matched billing reality. The other matched how teams experienced usage. The moment we tried to collapse them into a single number, the meeting stopped being about the decision in front of us and became a referendum on whose system counted as official.
I've learned that definition work is rarely neutral. You can choose the version that is methodologically pure and watch adoption fail. Or you can choose the version that a room can actually use, knowing you are accepting rough edges in exchange for coherence. The trade is easier to defend than it is to live with, especially when the rough edges hide problems you should probably surface sooner.
You do not control which version of reality gets oxygen. You influence it through framing decisions that look technical in the moment and read as power later.
The Negative Space
From the outside, BizOps can look like strategy. Inside, it feels closer to triage with spreadsheets.
Every model is less about math than about forcing a conversation people would prefer to delay. The math is often the entry point.
You present a headcount model that shows the company cannot hire fast enough to hit the growth target. What you are really surfacing is a tradeoff three VPs have been circling for weeks: what gets delayed, what gets cut, what assumptions were always aspirational.
If the tradeoffs are not named before the meeting ends, the decision will be made by default. Default decisions tend to favor whoever is most confident in the room, not necessarily whoever has the most context.
The work repeats in smaller forms.
Pricing exceptions clog the system. Sales wants flexibility. Finance wants control. Legal wants predictability. You map the last quarter of deals and find that most exceptions cluster around a handful of patterns. You propose guardrails that handle the majority of cases without escalating every contract to the CEO. The framework is imperfect. It is still better than the accumulation of one-off negotiations that consume leadership time in ways no one tracks.
Three customer counts circulate across the company. Marketing tracks logins. Product tracks monthly actives. Finance tracks paying accounts. The analytically complete solution would require reworking how three systems record data. That would take two quarters and cooperation that does not currently exist.
You propose a definition that is close enough to be useful and simple enough to be adopted. Adoption and coherence matter more than precision in an organization that cannot align on what a word means.
The pattern is consistent: step into ambiguity that no one formally assigned to you, pull threads together that should already connect, surface tradeoffs before they calcify.
You operate in a space where you have influence but little formal authority. How much of that influence you exercise depends heavily on context, trust, and timing. You cannot compel Sales, Product, or Engineering to adopt your model. Yet you may shape which tradeoffs are named explicitly and which conversations happen in private before they reach a broader forum.
It is a position that requires restraint as much as conviction.
What the Skills Actually Are
On paper, the skill set sounds straightforward: modeling, SQL, analysis, program management, executive communication.
You need enough SQL to notice when a dashboard is flattering itself. Enough accounting to see when margin math is optimistic. Enough sales context to understand how a contract structure affects compliance. Enough engineering fluency to translate "small change" into a realistic delivery timeline.
That gets you invited.
Staying in the room requires something less technical.
You need to know who actually makes the call. Who needs to feel heard before they can concede. Who will agree publicly and then raise concerns privately. You need to recognize when Tuesday's good-enough answer is more valuable than Friday's perfect one, because by Friday the decision may already have shifted without you.
The popular narrative suggests operational excellence is primarily a systems problem. Build the right processes. Install the right tools. Establish the right cadence.
Systems matter. They are rarely sufficient on their own.
The work is persuasion by detail. You are helping multiple leaders converge on a shared frame, even when their incentives pull in different directions. Each is rational within their domain. The coherence does not emerge automatically.
You translate. You reconcile. You facilitate agreement in ways that allow people to retain dignity and status while still adjusting their position.
And sometimes you hold onto more of that translation than you should.
There were moments I held onto work longer than I needed to, telling myself continuity mattered. Sometimes it did. Sometimes it was harder to disentangle my usefulness from the access that came with it. The line between service and self-interest is not always bright.
How It Finds You
Few companies decide in advance to create BizOps.
The function emerges when divergence becomes too visible to ignore. Sales forecasts one future. Finance models another. Product builds against timelines that feel increasingly aspirational. At smaller sizes, these gaps resolve through proximity. At larger sizes, coordination costs rise and informal mechanisms fail before formal ones are built to replace them.
Someone starts closing the gaps. Often without permission. They reconcile the forecast. Build the template. Schedule the conversation nobody else was going to schedule.
That person becomes the seed of BizOps.
The same instinct that makes you effective in this role can also distort it. The ability to see across functions and step into ambiguity accumulates informal influence. You become connective tissue. That can serve the organization. It can also quietly concentrate knowledge in ways that make you harder to replace.
The distinction is not always obvious in the moment.
Without a function that closes gaps, companies drift in a quiet way. Forecasts diverge. Planning becomes ritual. Decisions get made by default rather than design. The function does not eliminate chaos. It reduces the likelihood that the same chaos repeats without anyone noticing.
Where It Reports
Reporting line shapes what is possible, though not always in obvious ways.
Under a CEO, BizOps gains visibility and speed. It also risks absorbing whatever is urgent that week.
Under a COO, the function aligns more directly with execution. If the COO shifts focus, BizOps often shifts with them.
Under Finance, the function thrives when Finance is forward-looking. If Finance is primarily retrospective, BizOps can narrow into reporting work rather than connective work.
The reporting line matters less than three conditions.
Air cover to surface cross-functional tension without being penalized for it.
Discipline to avoid becoming the organizational junk drawer.
Access to decisions while they are still forming, before positions harden and meetings become confirmations rather than explorations.
The Week You Cannot Quite Describe
Monday morning, a VP asks whether you can quickly model the impact of sunsetting a feature used by several enterprise customers. Quick will take days because revenue attribution is fragmented and undocumented. You say yes.
Tuesday afternoon, three department heads present hiring plans that exceed the budget by thirty percent. No one does the addition in the room. You do it quietly. You could surface the conflict publicly. Instead, you schedule separate conversations and help each person revise their request independently. It is slower. It often works better.
Wednesday, two departments adopt your planning template. Two resist. You negotiate data extraction without forcing format changes, knowing the compromise may create reconciliation work later.
Thursday, you sit in on an acquisition discussion framed as exploratory. Some conclusions have already been informally reached. The meeting shapes how they will be described.
Friday, you realize the feature model is unfinished because the week was consumed by work that will not appear on a tracker but that prevented misalignment from compounding.
This is the week, in variations.
The work that matters most is the hardest to describe. It rarely attaches cleanly to your name. The person presenting the analysis may receive the credit. The person who reconciled definitions and surfaced tradeoffs receives less visible acknowledgment.
Sometimes that is enough. Sometimes it raises questions you continue to sort through.
Footnotes
The job title "BizOps" is a case study in corporate naming. It manages to be simultaneously too broad (what business operations aren't "business operations"?) and too narrow (it excludes the strategic work that occupies most of the actual time). I have watched companies debate naming for months. "Strategy & Operations" sounds like consulting cosplay. "Business Operations" sounds like you manage the office. "Chief of Staff" implies a single executive's orbit. The naming difficulty reflects something genuinely hard about defining work that exists in the negative space between other people's job descriptions. The function is, in a real sense, whatever the gaps are, and gaps resist naming because acknowledging them means acknowledging that the org chart is a fiction, which everyone knows but nobody wants to say in a planning meeting.
The politically safe definition and the analytically clean definition diverge more often than I'd like to admit. The expedient choice and the right choice overlap frequently enough that you can conflate them for months, infrequently enough that the conflation should probably bother you more than it does. The cumulative effect of choosing the cleaner conversation over the harder, but maybe more strategic conversation is a gradual widening gap between story and reality: the organization develops a version of its own performance that is internally consistent, well-documented, and subtly detached from the messy reality underneath. You don't notice the drift while it's happening because each individual choice was defensible. You notice it when you're asked a question the curated version cannot answer, and suddenly the conversation you avoided six months ago is the conversation you're having now, except now you're having it with worse options and less time.
There is a particular flavor of organizational dysfunction I think of as the reverse-importance problem: the amount of leadership time consumed by a decision is often inversely proportional to that decision's strategic significance. I have watched a C-suite spend forty-five minutes debating whether to approve a $15,000 vendor contract and then approve a $2 million hiring plan in six minutes because "we already discussed this at the offsite." The pricing exception work is a good example. Each individual exception is small enough that no one prioritizes building a framework to handle them, even though the aggregate leadership time spent arbitrating them vastly exceeds the effort of building the framework. BizOps spends a lot of time on this kind of work: fixing problems whose individual instances are too small for anyone to champion but whose cumulative cost is quietly draining the company's decision-making capacity.
The politics of definitions is the least discussed and most important dimension of this work. When you propose that the company adopt a single definition of "customer," you are not making a technical suggestion. You are, implicitly, telling two or three teams that their version of reality is no longer the official one, and the teams whose version gets deprioritized experience this as a loss of status even if they would never articulate it that way. I once proposed a standardized definition of "active user" that would have replaced three department-specific versions. The definition was analytically sound. Two of the three departments rejected it, not because they disagreed with the methodology but because adopting it would have made their engagement metrics look worse than what they were currently reporting to leadership. Nobody said this. What they said was that the definition "didn't capture the nuance of their user base," which is the corporate version of "I don't like what this mirror shows me." I backed down. I picked the battle I could win, which was getting Finance and Product aligned, and left the third team on their own definition for another two quarters. This is the kind of compromise that BizOps lives in constantly: the analytically complete solution that nobody will adopt versus the partial solution that most teams will actually use.
I have started to think of BizOps as a kind of organizational interpreter, in the linguistic sense. You sit between groups that technically speak the same language but mean different things by the same words, and your job is to translate in real time without either side noticing that a translation is happening. "Pipeline" means something different to Sales than it does to Finance. "On track" means something different to Engineering than it does to the CEO. "Strategic" means, in most contexts, "I want this funded but can't justify it on the numbers." The interpreter role is useful and also quietly corrosive, because the longer you translate, the more the organization depends on you to translate, and the less incentive anyone has to learn each other's language directly. I have been the bottleneck I was trying to eliminate, and the realization arrived slowly enough that I am not entirely sure I have finished arriving at it.
There is a specific company size, somewhere between fifty and two hundred people depending on the industry, where informal coordination mechanisms break down faster than formal ones can replace them. I think of this as the hallway-to-meeting transition, and it is more disorienting than it sounds. At fifty people, you can resolve a forecast discrepancy by walking to someone's desk. At two hundred, the same resolution requires a meeting invite, an agenda, a shared document, and the political navigation of making sure the right people are included without making the wrong people feel excluded. The coordination cost does not increase linearly with headcount. It increases in something closer to a phase transition: one quarter everything works, the next quarter nothing does, and the company spends months wondering what happened before someone starts building the connective tissue that replaces the hallway.
I want to be careful here because the line between "seeing what the organization needs" and "accumulating influence by positioning yourself as essential" is genuinely thin, and I have walked on both sides of it. The first time I was invited to an executive meeting that was not technically part of my role, I felt a rush of validation that had nothing to do with the organization's needs and everything to do with a desire to be perceived as important. The meeting was useful. My contributions were likely helpful. And the motivation was, at least in part, genuinely self-serving. These things coexisted comfortably, which is what makes the dynamic so hard to self-diagnose. You can be doing good work and enjoying the status that comes with it in proportions that shift without your noticing, and the shift matters because the person who is primarily serving the organization makes different choices than the person who is primarily serving their own position within it. The first person hands off work when it is stable. The second person holds onto it because letting go means losing the access that comes with being the only one who knows how the model works.
I once reported to a leader who treated planning as a decision tool rather than a reporting ritual, and the work thrived. Then that leader left. On paper, nothing about the reporting line changed. In practice, the ceiling dropped. Cross-functional work that had moved with a quick nod began to require negotiation. Department heads who had previously engaged started to wait me out.
I learned something I wish were more widely understood: a function built on influence borrows authority from the person above it. That borrowed authority is hard to see while it exists. You notice it the moment it no longer does, though.
The "schedule three separate conversations" approach is, I have come to believe, one of the core competencies of BizOps, and also one of the things that makes the work so exhausting and so difficult to put on a resume. You are, in effect, running a distributed negotiation where each participant believes they are having a one-on-one planning conversation. The outcome is a plan that everyone supports because everyone arrived at their portion independently, with context you provided about the constraints, without anyone feeling like they were told what to do. This is useful and also, if I am honest, closer to orchestration than facilitation, though I prefer the gentler word. The alternative, the transparent version where you put everyone in a room and say "your plans don't add up, figure it out," produces defensiveness, political maneuvering, and a plan that reflects who argued most convincingly rather than what the company actually needs. I have tried both approaches. The distributed version is slower, more tiring, and produces better outcomes roughly eighty percent of the time. The other twenty percent, you should have just put everyone in the room.
The invisible work problem is, I think, structural to BizOps in a way that it is not structural to most other functions. Engineering ships features you can see. Sales closes deals you can count. Marketing produces campaigns you can measure. BizOps produces alignment, which is not a deliverable anyone has ever successfully put on a dashboard. The closest proxies are "decisions made faster" or "planning cycle completed on time," both of which sound like project management metrics rather than strategic contributions, and neither of which captures the actual value, which is that the decisions were better because someone spent three days untangling definitions and surfacing tradeoffs before the meeting where the decision was made. The person who presents the analysis in the meeting gets the credit. The person who made the analysis possible by reconciling six data sources and navigating three political landmines gets a Slack emoji and the quiet satisfaction of knowing the decision was informed. This is fine, most of the time. Some of the time, it is corrosive in ways I am still sorting out.
| Published | 6 July 2025 (8 months ago) |
|---|---|
| Reading time | 18 min |
| Tags | org structure, finance |
| Views | – |
Reply
I’d welcome your thoughts on this essay. Send me a note →
