From Output to Outcome

Back in 2018, I joined Doktor.se, one of Sweden’s fastest-growing healthtech companies, as Android Lead. One thing that puzzled me was how rarely I saw our CTO.

He spent most of his time in meetings outside of the team rather than looking at code or discussing technical solutions. At the time, I couldn’t understand why he wasn’t more hands-on with the product.

Fast forward a couple of years, and I found myself as CTO at Baby Journey, a startup helping expecting parents navigate pregnancy. Initially, I did what felt natural - reviewing PRs, making technical decisions and prioritizing features.

As I grew our tech organization from a single developer to ten people, I started noticing a pattern. More and more decisions needed my input, at the same time as I was pulled into more and more meetings.

This meant that tasks ended up in a state where nothing happened, because people were waiting on me to make a decision. I had became the bottleneck.

Something had to change. I started looking at what actually moved the needle for our product. Sure, I could spend hours perfecting a feature, but was that the best use of my time? The most impactful decisions weren’t about code at all. They were about where to invest our team’s energy.

This made me realise that my metrics were all wrong. I was measuring success by the number of features shipped and bugs fixed. Those are good metrics for managing releases. But what really mattered for the company was how many parents we helped feel safe during their pregnancy.

The solution for this was of course to find new metrics. Instead of measuring our output (features shipped), I started measuring outcomes (impact of shipped features). Talking about what was important to our users, rather than what was important for “The Boss” (aka me).

That’s when I realized that my job wasn’t about managing which features got built. It was about painting a clear picture of why we existed as a company. I started talking about how expecting mothers used our product to feel safe during their pregnancy. How we helped them navigate one of the most important moments of their lives.

I remember one particular feature discussion where the team suggested adding gamification elements to increase engagement. In my previous role, I would have jumped straight into implementation details. Instead, I asked how this aligned with our mission of reducing anxiety during pregnancy. This simple question led to a completely different approach - one that actually served our users better.

The team didn’t need me to tell them how to build features. They needed to understand why we were building them in the first place. And as I removed myself from the day-to-day operations, the team started moving faster. No longer did they have to wait for my approval on every decision.

Sometimes I caught myself wondering if I was too removed from the details. But having written code, reviewed PRs, and shipped features myself gave me the context I needed to make strategic decisions. Knowing how to do something doesn’t mean you should keep doing it.

Looking back, I wish I’d had someone to guide me through these transitions. Which is why I now coach CTOs making similar journeys.