Most software engineers who want to get closer to “the business side” of tech end up becoming product managers. It’s a natural path that allows you to stay close to the technical problems, get more involved with strategy, and still speak the language of engineers. I eventually took that path too. But before I did, I had the rare opportunity in 2021 to join the newly formed BizOps team at Headway — not as a PM, but as a founding member of what was pitched as a SWAT team for the company’s hardest problems. This wasn’t your average business operations role. It was modeled after an internal team at Palantir (where some of us at Headway came from) — a group of scrappy generalists who embedded deeply into critical initiatives, rapidly built context, and moved mountains to unlock growth. It turns out my time as a software engineer, especially in ML, prepared me far more for this chaos than I expected. And the more time I spent on BizOps, the more I realized how much the two disciplines can (and should) learn from each other. Here are two lessons that stood out.
Defining north star metrics looks a lot like tuning objective functions
As a Forward Deployed Engineer at Palantir, and later on a software engineer at Arena AI, one of the fields I spent time on was ML Engineering. As any ML Eng knows, a good amount of work goes into fine tuning objective functions to optimize for a specific model output. Figuring out the right balance of input variables and adding in countervariables quickly became one of the most time-consuming parts of the job. Tweaking a loss function ever so slightly and end up optimizing for a totally different behavior.
Solving operational problems often works the same way — especially when designing incentive systems and tracking success. At Headway, for example, we work with thousands of mental health providers across the country. Early on, we measured our sales team on the number of signed providers. But that didn’t necessarily translate into provider activations, given that many signed but never saw patients. When we shifted our north star metric to activated providers (those who successfully completed onboarding and saw patients), the way the team operated changed almost overnight. It was also interesting to see how the idea of “pairing metrics” in ops was almost a perfect analog to counterweights used in model tuning - in essence, secondary metrics you define to provide guardrails for teams while they chase the north star metric (e.g. if reducing cost is the north star, one could use customer satisfaction as a pairing metric)
Lesson: A clearly defined North Star metric deserves as much obsession as inputs to an objective function in model tuning – a small change can go an extremely long way.
Great abstraction and handoffs are necessary for great teams, not just great software
Lots of good software is made up of good abstractions. You define clear interfaces, orchestrate systems cleanly, and decompose complexity into composable modules. The more consistent, intuitive, and cleanly defined the API contracts between services, the more scalable, reliable, and high-performing these systems tend to be.
The same applies to high-functioning ops teams. Whenever we stood up new teams, from payer partnership to revenue cycle management teams, I quickly realized how much time we had to spend, especially for larger teams/teams of teams – being thoughtful around ownership of metrics (see above point), handoff points, and where to draw the line between areas of shared ownership to balance individual ownership and shared context (similar to how different services in software may need to reference shared state). I found myself drawing from my engineering past more than I expected: treating teams as services, writing “interfaces” in the form of well defined metric ownership structures, etc.
Lesson: Building good ops teams shares a lot with building good software, benefitting from deliberate abstraction, clear contracts, and thoughtful orchestration.
Closing Thoughts
In many strange ways, my time in BizOps didn’t take me further from engineering. In some ways, it brought me closer; not always to the code itself, but certainly to the mental models that make engineers effective. If you’re an engineer curious about transitioning towards the business side, don’t underestimate how transferable your toolkit is. The abstractions are messier. The inputs are a little noisier. But under the hood? There’s a whole lot of systems thinking.