Organizational evolution: From products to user needs Eugene Sergueev (Category Management)
I saw it. report Evgeny Sergeev talks about the evolution of the engineering organization at Flo Health, and I had a very strong sense of déjà vu. Summer. 6 Back in the day, I took a pretty similar path: turning an app into a super-app, Conway's Law, Conway's reverse maneuver, Team Topologies, trying to understand where team boundaries help a product, and where architecture and user experience begin to break. (There's one. My talk with Techlead Conf).
With Zhenya, we recorded a number of podcasts. (for example, Book Review: Will Larson)So watching the show was particularly interesting. But even without that personal context, the report seems to me very useful to tech managers. It's not so much about Flo Health as a company as it is about a more general question: how to evolve an engineering organization when the product grows and the structure of the past gradually becomes a constraint of the future.
The main message of the report is simple and correct: the organization should be designed as consciously as the product and architecture. An organization is a living product. It has users, constraints, feedback, accumulated debt, and moments when the old solution stops working. You can see that in the Flo case. The company has grown from a cycle tracker to a large health platform. 70+ million monthly users. At an early stage, the functional structure could be normal: separately mobile development, separately web, separately backend and other functions. Then it took a shift to a more product-driven model with autonomous commands around channels and capabilities. This accelerated growth, but over time created a new problem: different channels began to compete for user attention, and the experience became fragmented.
And the next shift was not about “let’s add another product team,” but about the transition to custom scripts and Jobs-to-be-Done. That is, the question changes from “how to develop a specific feature or channel?” to “what does the user need in a particular life scenario?”. For a health product, this is especially important: pregnancy planning, early motherhood, different health conditions are not a set of independent features, but related user paths.
This is where Conway's reverse maneuver comes in. Conway’s Law reminds us that the architecture of a system repeats the communication structure of an organization. The reverse manoeuvre suggests using this consciously: if we want a specific architecture and a specific user experience, we need to design commands, boundaries of responsibility, and platforms for that outcome. I liked that the report presented this as a management framework: aligning business goals, honestly assessing the current state, selecting appropriate patterns, making changes and iterating further. Without this, companies often optimise local inconveniences rather than system constraints.
Another good practice is Organizational Decision Records. It’s essentially an analogue of ADR, just for organizational decisions. Why did we change the structure? What problem was solved? What alternatives were considered? What compromises have you made? It seems like bureaucracy until a year later, no one remembers why teams were sliced like that.
The most practical example in the report is the onboarding experiment. If every change to a user scenario requires the involvement of engineers, then the bottleneck is not in the development of a specific feature, but in the way the value is delivered. In Flo, the share of onboarding experiments that could be run without engineers has increased. 20percentage 87%. And that's already changing the culture: instead of "can we build this?" the organization is more likely to ask "let's check it out quickly."
For me, the main conclusion is this: the technical manager designs not only people in the organizing chart. It designs the flow of value. Team boundaries, self-service platforms, interaction rules, architectural dependencies, and orgreshed memory affect development speed no less than frameworks and processes.
#Management #Architecture #Engineering #TeamTopologies #Product #Leadership