Scaling up a development team should make everything faster, right? More people, more hands, more velocity—at least, that’s what we thought. But instead of accelerating, we hit a wall. Merge requests piled up, onboarding turned into a bottleneck, and suddenly, no one knew who was responsible for what. What went wrong?
We thought we had the answer: Team Topologies. By structuring our team with clearly defined roles—Guide, Scout, and Artisan—we expected a smooth and efficient workflow. But as we soon realized, we misunderstood the framework entirely. Team Topologies isn’t about rigid roles—it’s about structuring teams for fast flow, adaptability, and shared ownership. And we were about to learn that the hard way.
Team Topology is a framework designed to optimize team structures for software delivery by focusing on fast flow and minimizing cognitive load. It introduces four key team types: stream-aligned teams, enabling teams, complicated subsystem teams, and platform teams. Stream-aligned teams focus on delivering customer value, while enabling teams focus on providing support by helping to bridge knowledge gaps. Complicated subsystem teams handle highly specialized components that require deep expertise, and platform teams create shared services to enhance developer productivity. Organizations can create an environment that supports efficiency and collaboration by aligning team structures with these principles.
Newforma is a leader in Project Information Management (PIM) technological solutions for the Architecture, Construction, Engineering, and Operations (ACEO) industry. Nexapp joined forces with one of Newforma’s teams for a co-development initiative aimed at delivering critical features promptly. Camil, the Product Owner, and the rest of the team were instrumental in pioneering this collaborative strategy and managing subsequent adjustments, ultimately leading to significant success.
As our team nearly doubled in size, growing from a tight-knit group of five to a diverse team of eleven, including experts, seniors, juniors, and individuals with leadership, product, and coaching ambitions, the complexity of coordination increased significantly. Adopting Team Topology principles provided a structured way to improve efficiency while keeping cognitive load manageable.
We structured our team around three roles—Guide, Scout, and Artisan—believing this aligned with Team Topologies. However, we misunderstood the core principle: Team Topologies focuses on team structures, not predefined individual roles. That mistake wouldn’t become clear until we scaled up.
“To be honest, this was an adjustment, and it does not work for everyone. If you are a manager who micro-manages, forget it! If you have little to no trust in team members or your employees, don’t even try!”
—Camil Lafrenière, Product Owner at Newforma
At first, our roles seemed aligned with the four fundamental team types:
👨🏫 Guides took on mentorship and knowledge-sharing, much like Enabling Teams, but they also owned feature development, creating a split focus between coaching and execution.
🔍 Scouts worked ahead to refine features, somewhat resembling Stream-Aligned Teams, but their role didn’t quite fit since they weren’t directly delivering.
🛠️ Artisans focused on high-quality implementation, making them similar to Stream-Aligned Teams or even Complicated Subsystem Teams, but rigidly assigning this role led to silos rather than adaptability.
While we thought this structured approach would increase ownership and efficiency, it actually had the opposite effect. Instead of empowering individuals to step into responsibilities as needed, it constrained them within predefined boundaries.
This realization set the stage for our biggest challenge yet: scaling up while maintaining efficiency.
With nearly double the team members and an increasingly diverse skill set, our previous working methods no longer scaled. But, scaling up felt like an exciting opportunity. With more team members, we expected to build, test, and ship features faster. We approached it with confidence, believing that a well-defined strategy would maintain efficiency. As we mapped out roles, responsibilities, and workflows, we didn’t anticipate the real challenge. Growth wasn’t just about adding more hands to the project; it also introduced new layers of complexity. Instead of moving faster, we ran into unexpected bottlenecks, forcing us to rethink everything we thought we knew about delivering software efficiently.
As we scaled, we realized that structuring work through rigid roles didn’t improve efficiency. Instead, it created friction. The focus was on optimizing flow, reducing cognitive load, and structuring team interactions, but we mistakenly enforced rigid responsibilities on individuals instead. Instead of empowering the team, rigid roles restricted adaptability. People hesitated to step outside their assigned categories, even when it made sense. It took time to recognize that responsibilities should emerge based on need, rather than being dictated by predefined categories. Once we moved from static role definitions and embraced adaptive ownership, we saw a significant improvement in how our teams collaborated and delivered results.
Reality hit hard as our team rapidly expanded. Onboarding became a chaotic process that disrupted the workflow of many team members. Instead of accelerating our velocity, we found ourselves facing:
Onboarding bottlenecks—Getting new developers up to speed slowed team members.
Merge request pile-ups—Everyone assumed “someone else” would review them.
Merge requests began piling up, and no one felt a sense of urgency to review them. The larger the team grew, the easier it became to assume someone else would take care of it. This was a classic case of the bystander effect, a psychological phenomenon where individuals are less likely to take action when responsibility diffuses across a group. Since no single person felt directly accountable, code reviews stalled, leading to significant delays and slowing feature releases.
Feature ownership confusion—Information wasn’t distributed efficiently, leading to misalignment. Without clear ownership, duplicated efforts and miscommunication plagued the team, making feature ownership nearly impossible. We quickly realized that adding more people didn’t equate to delivering software faster.
It became clear that adding more people wasn’t the answer. The team struggled with ownership, accountability, and alignment, leading to bottlenecks instead of speed. At this point, we had to rethink our approach. We realized that restructuring into smaller, focused sub-teams would provide the clarity and efficiency we were missing. We improved collaboration, communication, and overall performance by allowing each person to contribute where they were most engaged. To ensure that each person worked on what they were most passionate about, we completed a self-selecting team workshop, as described in my colleague Maxime’s blog post. This paradigm shift allowed teams to take full ownership of specific areas, improving communication, accountability, and ultimately accelerating delivery.
“You need to ensure that it is okay to fail, because you and the team will, and often. There needs to be an open environment to try, that does not mean jumping off a cliff, but the ability to work with the team to hedge their bets.”
—Camil Lafrenière, Product Owner at Newforma
However, even after restructuring, challenges remained. We found that roles needed to be fluid rather than fixed. But the Artisan role had its drawbacks. The term made members seem like executors, like they couldn’t take responsibilities because that wasn’t the role that was attributed to them. We also noticed similar issues with the other predefined roles. Guides, for example, often struggled to balance mentoring and development work, making it difficult to commit fully to either. Scouts, whose role was to refine upcoming features, found themselves disconnected from execution, which limited their impact. These rigid divisions unintentionally discouraged flexibility, making it harder for team members to step outside their designated roles when needed. This structure had the adverse effect of discouraging team members from acting on urgent tasks or addressing unexpected challenges that did not clearly fall into their assigned category.
Restructuring into smaller, self-selected teams improved team alignment and accountability, making ownership clearer and reducing bottlenecks. However, broader communication and engagement across teams remained a challenge. Cross-team initiatives often lacked momentum, and predefined roles still discouraged people from stepping outside their designated areas. Over time, we noticed that the most effective moments happened when individuals naturally took responsibility beyond their assigned roles. This shift led us to rethink our approach. Emerging roles, where responsibilities evolved based on need, proved to be far more effective in fostering collaboration and adaptability. This approach allowed individuals to choose where to contribute, explore new initiatives, and develop leadership skills without predefined roles constraining them. It encouraged proactive problem-solving and ultimately helped the team become more adaptive and resilient.
Even with our smaller teams, unexpected issues still disrupted progress. We needed a way to handle unplanned work and cross-team collaboration without overloading individuals. Enter the Juggler Initiative. Inspired by the baseball idiom, “dropping the ball”, we designed the Juggler role to ensure that we didn’t overlook any critical tasks, hence no balls dropped.
Each week, we designated one sub-team as the “Juggler Team of the Week.” The Juggler’s primary responsibility was to facilitate task management, ensuring that they promptly addressed unplanned work and production issues through delegation and collaboration. Rather than completing tasks themselves, Jugglers ensured that they were appropriately assigned and followed up on, preventing bottlenecks and maintaining team efficiency.
This initiative encouraged cross-functional collaboration and promoted a culture of shared responsibility. Team members became more engaged by stepping into different areas of the development process based on their interests and the team’s evolving needs. By rotating the Juggler role, everyone gained exposure to various aspects of the project, fostering a deeper understanding and investment in the product’s success.
The Juggler initiative significantly improved response times, reduced bottlenecks, and strengthened our ability to deliver software quality faster. It empowered individuals to take ownership of unexpected challenges and contributed to a more adaptive and responsive work environment.
Early on, we focused on structure. Later, we learned that adaptability mattered more. Instead of adjusting to emerging challenges, we stuck to our predefined roles and processes, sometimes to our detriment. We stopped defining roles in advance and let responsibilities emerge as needed.
Through workshops and team bonding events, we built a culture where everyone felt connected to the product’s mission and took ownership of both the successes and failures of the features we developed. This shift helped the team overcome the first dysfunction of a team: lack of trust. By fostering trust and shared ownership, we were able to deliver software faster without compromising on quality. We let team members gravitate toward work they were passionate about, creating a sense of shared ownership. We discovered that taking a role felt less engaging than taking a responsibility. This fostered a stronger sense of personal investment and accountability. The hesitation to act and the passive reliance on others melted away.
“You need some level of trust. That does not mean carte blanche. You inspect what you expect. We built our inter-relationships from the start and over time, which helped immensely. Trust goes a long way here.”
—Camil Lafrenière, Product Owner at Newforma
Scaling up isn’t just about adding more people—it’s about working smarter. We learned the hard way that rigid structures kill agility. Once we let go of predefined roles and embraced adaptive ownership, we finally unlocked both speed and quality.
More people don’t fix bottlenecks, and more structure doesn’t guarantee speed. The real key is giving teams the autonomy to shape their own workflow.
Team Topologies helped us rethink our approach, but the real breakthrough wasn’t diagrams or frameworks—it was trusting our team to adapt.
“I never doubted we could do it, and what the team was capable of. When it worked… it is like the flood gates opened up! In the end it exceeded my, the team’s and leadership’s expectations. It was hard to keep up, a very rare but nice problem to have.”
—Camil Lafrenière, Product Owner at Newforma