From Operations to Software: What 20 Years Running Businesses Taught Me
I spent nearly two decades running businesses before I started building software full-time. That experience didn't just prepare me—it fundamentally shaped how I think about products, teams, and execution.
The surprising thing? The principles that make operations successful are almost identical to the ones that make software great.
Lesson 1: Process is a Tool, Not a Goal
In operations, I watched companies build elaborate processes that nobody followed. They documented workflows, created checklists, and held training sessions—then wondered why quality was still inconsistent.
The problem: they fell in love with the process instead of the outcome.
"Good process serves the work. Bad process serves itself."
In software, this shows up as over-engineering. Teams build abstractions for problems they don't have yet. They adopt complex architectures because they sound impressive. They optimize for theoretical scale instead of current reality.
I learned to ask: "What problem are we actually solving right now?" If the answer involves future hypotheticals, we probably don't need it yet.
Lesson 2: Feedback Loops Beat Planning
Early in my career, I spent months planning initiatives before executing. We'd research, strategize, build detailed plans—then discover reality didn't match our assumptions.
The businesses that succeeded were the ones that shortened the feedback loop. Ship something small. See what happens. Adjust. Ship again.
This is now standard advice in software, but it came from operations first. The best operators I knew were constantly experimenting—testing new promotions, adjusting staffing models, tweaking workflows.
They didn't wait for perfect information. They preferred good information today over perfect information next month.
Lesson 3: Quality is Cumulative
Small quality issues compound. In operations, this meant customer complaints escalated, employee morale dropped, and eventually your best people left.
In software, it's the same story. A messy codebase doesn't stay messy—it gets messier. Each shortcut makes the next one easier. Technical debt is real debt, with real interest payments.
I learned to treat quality as a habit, not a phase. You don't "fix quality" in a sprint. You maintain it continuously, or you lose it.
Lesson 4: Communication is Architecture
The most dysfunctional operations I ran had one thing in common: poor communication. Not because people were bad at their jobs, but because information didn't flow.
In software, Conway's Law states that systems mirror the communication structures of the organizations that build them. I've found this to be absolutely true.
If your teams don't talk, your code won't integrate. If your product and engineering teams are siloed, your product will feel siloed. If information flows through a single bottleneck, you'll have a single point of failure.
Fixing communication is often more impactful than fixing code.
Lesson 5: Trust Your Instincts, But Verify
After years in operations, you develop intuition. You can walk into a business and sense what's working and what isn't. You learn to spot problems before they show up in metrics.
But intuition without verification is just ego.
The best operators I knew trusted their instincts to ask questions, then used data to answer them. They didn't ignore their gut—they investigated it.
In software, this means building systems you can observe. Logs, metrics, user feedback—these aren't afterthoughts. They're how you verify that your instincts are correct.
Bringing It All Together
Twenty years of operations taught me that great products aren't built by following a playbook. They're built by teams that:
- Focus on outcomes over process
- Shorten feedback loops and iterate quickly
- Maintain quality as a daily practice
- Prioritize communication and information flow
- Trust instincts but verify with data
These aren't software principles. They're business principles. And they work just as well in code as they did in operations.