Being an Engineering Manager at Flo
Behind the scenes of the women's health B2C unicorn
Continuing the series of insider takes from Engineering Managers at exciting companies!
Previously we covered:
Today we are going to get a peek inside Flo, the women's health B2C unicorn. 2 guest authors joined me to give you a full perspective:
Eugene Sergueev - a Director of Engineering at Flo, has been in the company for 4.5 years.
Nihan Bircan - An Engineering Manager at Flo for the past 3.5 years. Previously, she was an EM at Spotify and an engineer at Microsoft.
Together we’ll cover:
Flo engineering structure (and how it affects delivery speed)
2 practical examples of Engineering Managers driving business growth:
Getting to 50 A/B tests a week with minimum engineering time
Understanding when it’s the time for platformization
How Flo measures delivery
The opportunities and challenges of working in a scale-up
This article is of course not sponsored!
Flo Health is the #1 downloaded women’s health app worldwide. Flo recently raised $200M in a Series C investment at a valuation of more than $1 billion, making it the first consumer women’s health app to become a unicorn!
Flo engineering structure (and how it affects delivery speed)
Eugene Sergueev
When I first joined Flo, I was impressed by how intentionally the engineering organization was structured. Instead of traditional department silos, we organize around six "Streams" - each focused on specific business outcomes:
Value Creation Stream: Builds features that keep users engaged daily
Value Capturing Stream: Focuses on monetization
Delivery, Core Analytics, and MarTech Streams: Provide platforms and tools that help other teams move faster
What makes this structure unique is how it shapes our technology decisions. For example, each team has just one iOS and one Android engineer, but 2-4 backend engineers. This isn't random - it reflects our backend-driven strategy.
Why? In today's world, waiting 3 weeks for an app store release feels like forever. By pushing more functionality to the backend, we can release 20-30 times per day instead of every few weeks. We've even built our own backend-driven UI system to enable this speed.
Your takeaway
Structure follows strategy. Don't just copy other companies' org structures - design yours intentionally to support how you want to build and ship software. Sometimes the constraints you create, like having fewer mobile engineers, can drive positive architectural decisions (called the “Inverse Conway Maneuver”).
2 practical examples of Engineering Managers driving business growth
1. Getting to 50 A/B tests a week with minimum engineering time
Eugene Sergueev
When I joined the Value Capturing Stream to lead the onboarding team, we faced a major challenge: experimentation was slow and engineering-heavy. Every A/B test required JSON configs and sometimes even app releases.
Instead of just accepting this as "how things work," we saw an opportunity. We set ambitious goals:
Increase experiments from 10 to 20 per week
Enable 60-70% of experiments without engineering involvement
We started small with an MVP on top of Contentful - the CMS we use for managing the content lifecycle and content operations. When feedback showed it was still too complex, we built a custom interface on top. This was transformative - suddenly PMs could configure simple experiments themselves.
The results? We now run 40-50 experiments weekly, with 70% requiring zero engineering time. Better yet, the solution was so flexible that other teams started adopting it for surveys, feature announcements, and more.
If you are interested in the technical details of our onboarding journey, check out the part 1 and part 2 articles on our Medium blog.
2. When it’s time for platformization
Nihan Bircan
1 year ago we were selling just 2 subscription packages: Tier 1 and Tier 2. Today we have 13(!) different packages.
How did we get there? At first, we had just the free version and the Premium version. Then in addition to basic Premium, we began selling a Family plan (called Tier 2) where you can add up to 5 members to your plan and they all get Premium access.
As everything was hard-coded, it took us 2 weeks to create a new package and wire all the features to be part of a given subscription. Then the business wanted to create more and more packages to experiment with - and we figured out it was time to scale our operations and reduce engineering efforts by platformization.
We built a service where you can create new “entitlements” and put them in packages. Entitlements can be seen as “access rights” that the user buys. The app will react to these - enabling Premium, showing some extra features, or changing the content.
Example 1 - The user has a Flo subscription. She pairs her account with her partner. The partner gets access to Premium features tailored for a partner, via partnership entitlement. The partner doesn’t have a subscription themselves.
Example 2 - The user gets a symptom checker entitlement and unlocks this widget:
We have built a Product Price Catalog where our product managers can see and edit these packages, play with the entitlements in them without any involvement from the engineers (once the features are hooked to our APIs).
In the end, we reduced the time it takes to create a new Tier with various features to 5 mins, down from initial ~2 weeks. We have saved $125k/year by making the package creation self-service and dynamic.
Your takeaway
Look for bottlenecks that affect multiple teams. Solving these platform-level problems can have a huge impact on both the business and your own career growth.
How we measure delivery at Flo
Nihan Bircan
Flo is a super-app where tens of changes happen in a day. More importantly, these changes happen in as small increments as possible, to deliver product value quickly and learn from it. Efficiency is our goal. How do we make sure we are an efficient engineering team? In order to measure that, we use a set of metrics:
Cycle time
Ideally, each story should be broken down to 1 story point (~1 day). 2 and 3 story points are acceptable, 5 should be a reason for concern. This means we can deliver value in the shortest time possible.
At the end of the sprint, we measure the “cycle time” - how long a task spent in each stage after it was picked up by an engineer: In Progress, In Review, To Test, In testing (and finally moved to Done).
From our experience and measurements, our 1 story point tends to be completed in 1 day so the ideal cycle time would be around 1 day for each task.
Once we see the data, we ask questions to help us identify the outlies and bottlenecks:
Is a task spending too much time in the review stage? Do we need to improve our code review process?
Is it in “to test” for several days - Does it mean our QA has their hands full and we need to find another way?
Amount of tasks delivered
In addition to cycle time, we also measure the total amount of tasks delivered in a sprint - after all, it’s about delivering as much as possible, as quickly as possible.
Note that we are not measuring the number of story points delivered here. Ideally, we’d break down the tasks into atomic increments so the amount of story points would be equal to the amount of tasks. This is what we are striving towards.
We also measure the amount of tasks delivered per engineer - a value that shouldn’t be affected by absences, and should hopefully stay stable (or increase!).
Benchmark and goals
Every team and company has its own way of measuring things, but in Flo, each team operates by measuring the same metrics against the same goals:
Issue cycle time < 3 days
PR cycle time < 1 day
Defects MTTR < 2 days
Unlinked PRs < 5%
Sprint competition rate > 80%
In the below benchmarks, we can see that the team is doing well in most of these areas, but the unlinked PR percentage is high. This causes some work to be unaccounted for, as we don’t track what task was completed with it. It can signal an issue with encountering roadblocks around infrastructure and fixing them ad-hoc.
The opportunities and challenges at Flo
Opportunity #1 - Having top talent
Eugene and Nihan
One of our greatest strengths is our commitment to maintaining a high hiring bar. We specifically seek out people with 7+ years of experience. This approach means there is no hand-holding or babysitting - our engineers are really the best in class and deliver with high quality.
Opportunity #2 - Push industry boundaries
Eugene
Our position in the healthcare space lets us pioneer solutions that push industry boundaries.
The best example is our development of Anonymous Mode, a feature that sets new standards for privacy in women's health apps. This technology allows users to access the app without providing their name, email address, or any other identifying information. It uses advanced cryptography to separate identifying data from health data, ensuring that even if a breach occurred, sensitive health information couldn't be linked back to individual users.
We even collaborated with Cloudflare to develop a first-of-its-kind technical solution for this level of privacy protection. Since its launch, Anonymous Mode has become an industry benchmark, with other health apps following our lead in prioritizing user privacy.
Challenge #1 - Multiple focuses
Nihan
One of my bigger challenges is having multiple focuses in parallel. We want everything and we want it now :)
We want to run several experiments at the same time but it diverges our attention from doing one thing well. Sometimes we mistake a lack of prioritisation for a lack of resources!
Challenge #2 - Duplication
Eugene
As our organization scales, we sometimes find multiple teams independently developing solutions for similar problems. While this parallel development can lead to innovation, it also creates redundancy.
A key area for improvement for us is increased investment in platformization (which we hope we proved to you is super useful!) and dedicated R&D teams. These teams could develop solutions that benefit the entire organization, reducing duplication of effort and ensuring more consistent user experiences across our products.
The balance between maintaining growth and building sustainable, scalable solutions remains a challenge - but it's exactly this kind of complex problem-solving that makes working at a scale-up so engaging and rewarding :)
Final words
Huge thanks to Nihan and Eugene for sharing their insights and putting so much effort into this article!
I found it really interesting to peek inside a company during rapid growth. There’s something unique about that stage and the challenges it brings. It’s a nice reminder of how much thought goes into building not just products, but the structures and processes behind it.
If you work at an interesting company, and want to share your lessons from it, go over my guidelines and ping me :)
What I enjoyed reading this week
- . Another great post in this anonymous publication.
How to Ship Faster, Safer, and With Less Drama by
Applied "Software Engineering at Google" by
.
 | A guest post by
|
 | A guest post by
|
Wow, now I feel the urge of wanting to apply to Flo :D
I found the backend strategy towards mobile super interesting! I worked in a mobile team for some months that struggled a lot with delivery (for different reasons), and I loved seeing how Flo approach this problem while being super customer centric.
Amazing article.
Given that I lead a machine learning discipline, I was wondering how data scientists are embedded in Flo’s structure.
I saw in the stream diagram something related to ML and it seemed that 2 data scientists were part of the engineering “squad”. Is that correct?
It would be great to ask the engineer manager of that squad how does she/he deal with having such a different discipline within the squad.