Notes on being an operator in someone else’s system
A short essay on what it means to run growth infrastructure inside a SaaS company you don’t own — and the discipline it requires.
There’s a particular kind of work I keep returning to in my career: running growth infrastructure inside someone else’s company. Not as a founder, not as a contractor, not as a consultant exactly — as an embedded operator inside a system that someone else owns.
It’s a strange position. You have enough autonomy to architect real systems. You also have enough accountability that you can’t hide behind advice-without-execution. You’re inside the company, but you aren’t of the company in the same way a founder is.
After enough cycles of this work, I’ve started noticing patterns in what makes it work and what makes it fail.
Commit deeply to a system you don’t own
The first temptation is to keep emotional distance from a company that isn’t yours. To stay rationally detached. To remind yourself constantly that you’re a hired operator, not a founder.
This protects you from disappointment but it also caps the quality of your work. The systems I’ve built that compounded best are the ones I committed to as if I owned them — making decisions on behalf of the company’s 24-month future even when my own contract was 6 months.
The discipline is committing without confusion. You commit to the work because that’s the only way to do good work. You also remember that the company will continue without you and that your job is to leave the system stronger, not to make yourself indispensable.
Commit to the system as if you own it. Run the engagement as if you don’t. Both at once, without contradiction.
Patience with other people’s pace
When you can see the right move clearly, the hardest part of operator work is letting the organisation get there at its own pace. The temptation is to push, to argue, to over-articulate. Sometimes that works. More often, it produces resistance — even to ideas that would otherwise have been adopted naturally.
The pattern I’ve learned: present the analysis, propose the decision, then make space for the team to actually own it. The decision often arrives a week later, in a meeting where someone else articulates it. That’s the goal. If the team feels like the decision was theirs, they execute it better than if you forced it through.
This costs ego. Operators who can’t tolerate the ego cost end up being correct and ignored — a worse outcome than being correct and adopted, even if the credit pattern feels backwards.
Leave it better than you found it
The simplest rule I’ve internalised about operator work: the system should be stronger after you leave than it was before you arrived. Not just in metrics — in capability. The team should know how to operate the architecture you built. The documentation should outlive the engagement. The decisions you made should make sense to whoever inherits them.
This is uncommon. Most operators build systems that require their continued presence to function. The flex is that the company can’t fire them; the failure is that they’ve made themselves a dependency rather than a multiplier.
The harder discipline is building systems that don’t need you. The output is a less dramatic-feeling engagement — you spend more time on documentation and team enablement, less time on heroic execution — but it produces a far better company and a far better operator reputation.
Bring your judgment, not your playbook
Every operator engagement is tempting to approach with a playbook. “Here’s what worked last time; I’ll apply it again.” This works partially, then breaks. Every system is shaped by specifics that the previous system didn’t have. Playbooks miss specifics by definition.
The skill is bringing judgment instead of patterns — the underlying reasoning that produced the pattern, separated from the surface tactics. Judgment transfers; tactics don’t.
This is harder than it sounds because judgment is harder to articulate than tactics. “I’ve seen this work before” is easy to say. “Here’s why this specific situation requires a different approach than the surface similarity suggests” is harder. The operators who can do the second consistently are the ones who add value across multiple engagements.
Say no clearly when something isn’t a fit
The most expensive operator engagements are the ones where the fit was wrong and nobody named it early. Both sides suffer for months, the work doesn’t produce results, and the engagement ends badly.
The discipline I’ve had to develop: name fit problems explicitly within the first 30–60 days. Sometimes the company isn’t ready for the work I do. Sometimes I’m not the right person for what the company actually needs. Sometimes both sides assumed the engagement was about one thing and it’s about something else.
Naming this early — even at the cost of losing the engagement — produces better outcomes than enduring it for 9 months and ending in mutual disappointment. The companies I respect most are the ones where I or they said “this isn’t the right fit” cleanly and we both moved on.
None of this is dramatic. The work of being an operator inside someone else’s system is mostly quiet, documentable, repeatable. You commit deeply, work patiently, leave it better, bring judgment, say no when it’s right. Do that across enough cycles and the work compounds — both for the companies you help and for you as an operator. Skip any of these disciplines and the cycles diverge from each other rather than building on each other.
I’m writing this as much for myself as anyone else. The disciplines above are easy to articulate and harder to maintain under quarterly pressure. The version of me that re-reads this essay in 18 months will probably need the reminder.
Operator note
If you’re a SaaS founder thinking about your acquisition system and want to talk this through, book a call – I take a small number of these per quarter.
-Yash