There is a specific moment in every technical founder's journey that I call "The Pivot Point." It’s not a pivot in business strategy. It’s a pivot in identity. It is the moment you realize that writing the best code is no longer the highest leverage use of your time.
For me, this didn't happen overnight. It was a painful process of unlearning the very skills that got me to the starting line. It required a complete shift in mindset, similar to what Paul Graham describes in Maker's Schedule, Manager's Schedule.
The Engineering Trap
Engineers are trained to optimize for determinism. Input A leads to Output B. If it breaks, there is a stack trace. You can fix it. Validation is instant: the tests pass, or they fail.
Business is arguably the opposite. It is messy, probabilistic, and deeply human. There are no unit tests for a sales negotiation. You can do everything right and still lose the deal. For a long time during the early days of Frakton, I retreated into code whenever the business side got too ambiguous. Code was my safe space. It was controllable.
The Bottleneck Discovery
When we hit around 25 people, the company started to stall. I was still reviewing every Pull Request. I told myself it was about "maintaining quality standards," but deep down, it was about control. I was afraid that if I wasn't the gatekeeper, the product would degrade.
The reality was the opposite. By making myself the gateway for every deployment, I wasn't ensuring quality; I was throttling velocity. I became the single point of failure. My "high standards" were actually preventing my senior engineers from growing into leaders. I was clipping their wings to protect the nest.
Refactoring the Mindset
The shift happened when I stopped viewing the codebase as my product, and started viewing the company as my product. This is a profound shift for an engineer. As you scale, you stop optimizing algorithms and start optimizing team dynamics.
- Your architecture isn't microservices; it's your organizational chart.
- Your technical debt isn't messy code; it's undocumented processes and unclear responsibilities.
- Your features aren't login screens; they are the hiring, onboarding, and sales pipelines you build.
Sales is Debugging Human Needs
Another major hurdle was Sales. Like many engineers, I viewed sales as "manipulation" or "fluff." I hated it.
Then I realized that good sales is actually just high-level requirements gathering. You are debugging a client's business process. You are looking for the error in their workflow (the pain point) and proposing a patch (your service). Once I framed sales as "debugging," I became dangerous. I wasn't selling; I was solving. That authenticity resonated with clients far more than any polished pitch deck.
Two Exits Later
Years later, after navigating partnerships, mergers, and eventually the acquisition by Kin + Carta and later Valtech, the lesson solidified.
When due diligence teams came in to assess Frakton, they didn't care about the clever recursive function I wrote in 2017. They looked at our retention rates. They looked at our gross margins. They looked at whether the business could run for a month without me answering the phone.
If you are an engineer looking to found a company, here is the hard truth: You have to fire yourself from the codebase. You have to mourn the loss of that direct, tactile creation. But what you build in its place—a living, breathing organism of people and culture that achieves things you never could alone—is infinitely more complex and rewarding.
