In recent conversations with technology leaders from mid-sized companies (under 1000 employees), I've noticed a recurring challenge: the absence of effective frameworks for scaling product teams.
When you're operating with a single product team, life is relatively simple. Your developers, product managers, and designers select Scrum, Kanban, or whatever methodology best suits their needs. With two teams, coordination becomes necessary but manageable. At three teams, the coordination overhead becomes noticeable. By the time you reach ten teams, coordination without a proper framework becomes virtually impossible.
Surprisingly, this problem remains largely unsolved, even among experienced Heads of Product and CTOs. Several frameworks claim to offer solutions, but fall short in practice:
SAFe often functions as waterfall development in disguise, bringing substantial overhead
LeSS improves on some aspects but ultimately suffers from similar issues as SAFe
Nexus shows promise but doesn't scale indefinitely
The Minimalist Approach to Scaling
The most effective solution I've encountered focuses on reducing overhead by creating truly independent, autonomous teams:
Keep teams small enough that members can directly witness the impact of their work
Make each team fully accountable for their success
Prioritize technical autonomy by minimizing dependencies between teams - can they achieve goals independently? This is absolutely critical!
Establish "contracts" for inter-team communication: Technical contracts (well-documented APIs) and social contracts (communication standards, meeting cadences, dedicated channels on Slack/Teams)
This approach creates the optimal foundation for scaling product and engineering organizations effectively.
When formalized, this philosophy aligns with Team Topologies or unFIX methodologies. Both discard hierarchical scaling in favor of clear agreements about responsibilities, capabilities, and communication patterns between teams.
The result? Maximum team autonomy, structured communication, and clear accountability - all without unnecessary hierarchical complexity.
What I read
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:
How LLMs Work — A Visual Deep Dive: Visual technical walkthrough explaining the architecture, training stages, and data processing pipelines of large language models.
Things I’ve Learned as a Senior Engineer: Hard-won engineering lessons covering career growth, code simplicity, documentation importance, and the value of changing companies.
Stop Prompting Blind: Spec-Driven AI Development: Prevent AI coding errors and rework by using a structured specification template to provide necessary technical and business context.
Two side notes:
1. What I find interesting is that this article even admits that some sort of framework - or, let's call it organizational overhead - is necessary in the first place. I have compiled my own list of options, including the two mentioned here, and Flow as a general principle.
2. All 3 mentioned scaling frameworks have or had Scrum as the basis. In other words, the basic assumption was that every single team would use Scrum. I would be highly skeptical of prescribing the same way of working to all teams. In the end, you need to manage certain connection points to the bigger company and flow of information. How a single team works on the inside should not be management's business most of the time.