Operations Goal to Not Exist
"The goal of business operations is to not exist... Functional ops roles, whether it's product ops or marketing ops or whatever, they're a hack to deal with some sort of functional issue on your team. And it's totally okay to have functional issues... but if the way they deal with that functional issue is by building larger and larger operations teams and roles, that's basically exacerbating an inefficiency issue." - Casey Winters
What It Is
A framework for how operations roles should function within organizations. Rather than viewing ops as a stable, growing function, this framework positions ops roles as temporary solutions whose explicit job is to identify inefficiencies and eliminate them through process or software—then move on to the next problem.
The danger Casey identifies: normalizing ops as a distinct, growing function leads to empire building rather than efficiency gains. Having marketing ops or product ops can be a sign you "suck at marketing" or product—not that you're sophisticated.
How It Works
The Problem with Traditional Ops Thinking
What Often Happens:
- Team has a functional issue
- Ops person hired to handle it manually
- Ops team grows as complexity grows
- Manual processes become institutionalized
- Efficiency problem is exacerbated, not solved
What Should Happen:
- Team has a functional issue
- Ops person hired to investigate and solve it
- Ops builds process or software to automate
- Ops role becomes unnecessary
- Ops person moves to solve the next problem
The Intercom Model
"The goal of business operations is to not exist."
This means:
- Every ops initiative should aim to eliminate itself
- Success is measured by problems solved permanently, not team size
- Building larger ops teams is a red flag, not a sign of growth
Casey's GrubHub Example
Casey ran a double-digit million dollar marketing budget at GrubHub without marketing ops because they invested in:
- Automation
- Process design
- Software solutions
The first instinct should be "how do we automate this?" not "who do we hire?"
How to Apply It
For Ops Professionals
Treat every task as temporary - Your goal is to make your current task unnecessary.
Document to automate - Every manual process you document is a candidate for automation.
Measure inefficiency eliminated - Track what you've permanently solved, not what you're busy doing.
Build skills that transfer - You'll be moving to new problems; develop generalizable expertise.
Don't fear success - If you eliminate your role, you've proven value and will be wanted elsewhere.
For Leaders Hiring Ops
Frame the role correctly - Hire to solve problems, not to do tasks indefinitely.
Set automation expectations - Make it clear that building process/software is part of the job.
Watch for empire building - Growing ops team size is often a warning sign.
Celebrate role elimination - When ops automates themselves out, that's success.
Provide growth paths - Great ops people should move into other roles, not stay in ops forever.
Questions to Ask
- Is this ops investment solving a problem or institutionalizing one?
- Could this be automated? Why haven't we?
- Are we hiring people or building systems?
- Is our ops team growing proportionally to our business or faster?
When to Use It
- Hiring ops roles: Set expectations correctly from the start
- Evaluating ops efficiency: Is the team solving problems or managing tasks?
- Process design: Default to automation over manual handling
- Resource allocation: Question ops headcount growth
- Career development: Help ops people build transferable skills
Source
- Guest: Casey Winters
- Episode: "Why most product managers are unprepared for the demands of a real startup"
- Key Discussion: (31:26) - Casey explains his philosophy on operations roles
- YouTube: Watch on YouTube
Related Frameworks
- Product Operations Function - How product ops should work
- Do Things That Don't Scale, Then Scale Them - Manual processes should eventually become automated