What makes some software delivery teams thrive while others struggle to keep up? The answer often lies in how they’re organized. Poor team structures undermine stakeholder alignment, slow down delivery, and breed frustration.
Often when I join or consult for a new company, this reality hits me immediately. The first thing I notice is if teams are organized around software components—independent, siloed pieces of software deployed to production—rather than value streams. While this seems efficient on paper, it creates walls and fosters an “us vs. them” culture while delivering, at minimum, questionable value to customers.
This practice becomes more evident due to the existence of competing priorities that result in multiple roadmaps, lack of innovation, low morale, and even mistrust among teams. Sounds familiar? Here's how I work with my teams to change it.
Breaking Down Silos: From Disconnected Teams to Unified Value Streams
Inefficient cross-functional teams cause stress and inefficiency. I saw it plenty of times in my career.
Problems of a Fractured System
In many cases, teams are structured around software components rather than the value they delivered to customers. Each function—Product, Engineering, QA, Cloud Engineering, and InfoSec, among other functions you might have—operate mostly in isolation. As a result, roadmaps get disconnected, priorities clashed, and collaboration is stifled. This usually gets even more confusing because some team members must be shared across multiple groups. Stress and unhealthy tension is unavoidable, given:
- Multiple roadmaps: Shared team members are pulled in different directions, creating inefficiencies and delays.
- Conflicting prioritization: Teams are focused on competing priorities rather than aligning with the business’s most critical needs.
Each function—Product, Engineering, QA, Cloud Engineering, and InfoSec, among other functions you might have—operate mostly in isolation. As a result, roadmaps get disconnected, priorities clashed, and collaboration is stifled.
Aggravation Through a Sub-class of Engineering
Some of these teams tend to be grouped dynamically, forming “squads” to tackle stimulating business problems. Structures that are literally called “maintenance teams” or “Shield teams”- these are typically teams responsible for taking care of legacy software components. Regardless of how these teams are called, what begins as an attempt to “protect” the strategic teams from handling customers interrupts, bugs and maintenance work, often backfires horribly: no-one wants to work solely on something soon to become obsolete. These squads start to see legacy work as their own private gulag.
The Power of Value Streams
So how did I see teams to reduce stress and foster a sustainable development environment that energized teams again? Simple: by reorganizing teams around value streams instead of software components. A value stream (also called a Product Line) is the sequence of activities an organization undertakes to deliver value to customers, from conception to delivery.
A value stream (also called a Product Line) is the sequence of activities an organization undertakes to deliver value to customers, from conception to delivery.
How Team Organization into Value Stream Works
Value streams are all about delivering value to customers. Keep this principle at the forefront when planning, prioritizing, and evaluating team output.
- Unified Leadership:
Each value stream has a leadership triad formed by representatives from Product Management, Product Design, and Software Engineering—the corners of the Iron Triangle. This collaborative structure creates innovation-driven workflows, aligning every decision with the company's long-term vision, user needs, and technical feasibility. - Multiple Delivery Teams, Single Roadmap:
All requests flow through the product line leadership, not directly to delivery teams. This ensures prioritization aligns with 6-12 month investment goals, ROI, customer impact, and strategic objectives. They do however receive strategic input from external stakeholders (i.e. Customers) and internal stakeholders (i.e. Customer Facing Teams such as support, sales and professional services, as an example). - Dynamic Tension:
The balance of decision-making power across the triad ensures value-driven yet achievable solutions. Product evaluates market needs, Design focuses on user experience, and Engineering guarantees scalability, security, and maintainability. - Parallel Delivery Teams:
Shift from project-based funding to product-based funding. This creates a more stable environment for teams and ensures long-term alignment with customer needs. Delivery teams become cross-functional units with representatives from each function (e.g., Product, Design, Backend, Frontend, QA, and Security). This ensures complementary perspectives within every team, fostering synergy and efficiency.
Undeniable Benefits of Fully-Integrated Teams
When you ensure that all internal and external stakeholder requests flow through the product line leadership triad, delivery teams are able to focus solely on executing the priorities set by this group. Over time, this translates into:
- Cross-functional teams, ensuring alignment with shared objectives and connecting all work to the company’s North Star.
- A single source of truth for goals, priorities, and processes.
- Sustainable work-in-progress (WIP) throughput. Reorganizing around product lines eliminated redundant processes and brought clarity to team roles.
- Enhanced innovation and morale, driven by the #OneTeamOneHeart philosophy.
For added performance, empower teams to take ownership of their work, and measure success by how effectively they deliver value—not just by speed or output.
I also recommend you keep Guilds alive. These cross-stream communities of practice focus on advancing specialized areas of expertise. They share knowledge, establish standards, and promote best practices across the company. It's a great horizontal layer of consistency across the organization, while delivery teams remain focused on the day-to-day execution.
Lessons Learned: Organizing the Roadmap Workflow for Success
A clear and centralized roadmap workflow is the backbone of any successful software delivery team. Without it, teams fall into chaos, with conflicting priorities, disconnected goals, and wasted effort.
Teams who align around a shared vision produce exceptional results—delighting customers and driving sustainable growth.
How we now put things in motion: All in all, here's what I learned from the multiple companies I've seen this and how we've structured the workflow for alignment and impact:
- Adopt Transparent Prioritization Standards:
Define and document how decisions are made. Use a scoring system that considers business impact, user needs, and technical complexity to avoid bias and ensure consistent prioritization. - Create Execution Pathways:
Break down strategic initiatives into actionable work assigned to specific delivery teams. Ensure clear ownership of tasks and seamless integration between teams when cross-stream collaboration is required. - Establish Regular Checkpoints:
Hold quarterly roadmap reviews and frequent triage meetings to adjust priorities and align on progress. Incorporate feedback from guilds and delivery teams to refine processes and address bottlenecks.
I hope this case is enough evidence that the way software teams are organized directly impacts the company’s ability to innovate and deliver value. Teams who align around a shared vision produce exceptional results—delighting customers and driving sustainable growth.
