When teams own customer-facing value end-to-end, use quantitative metrics to guide decisions, are organized around a value model, are accountable for outcomes and evolve with value streams, they become powerful engines for continuous value delivery.
For many years, organizations have talked about cross-functional teams as a desirable end state. The idea is appealing: Bring together people with different skills, remove handovers and let teams move faster. In practice, companies struggle with creating effective cross-functional teams. The teams may be created and have the right form but fail to embrace the deeper shift in thinking that makes them effective. The main challenge seems to be that many are concerned with the structure of cross-functional teams rather than with the value delivery that they’re expected to unlock.
The first characteristic of a genuinely cross-functional team is that it has all the skills and capabilities required to deliver customer-facing value end-to-end. This includes not only software development, but also architecture, testing, UX, data, operations and security, as well as non-technical skills such as product and business understanding. To determine if a team is truly cross-functional, we need to determine whether it can deliver value to a customer without waiting for or being dependent on another team. If not, the team isn’t sufficiently cross-functional. Obviously, this doesn’t mean that every team member can do everything. It means that the team as a whole has the competence and authority to take an idea from hypothesis to deployed, measurable value.
Different from traditional R&D teams that operate based on a backlog created, maintained and prioritized by product management, cross-functional teams own their own work. They based their work on quantitative metrics and the improvement of these metrics. Without data, teams tend to default to opinions, internal debates and local optimization.
Effective teams track two types of metrics. Progress metrics indicate whether value is actually being created (eg adoption, usage, conversion, performance improvements). These metrics are expected to improve in response to the team’s efforts. Guardrail metrics prevent unintended harm (eg reliability, cost, safety, technical debt, compliance). In R&D as well as in the rest of our lives, many decisions require tradeoffs between different aspects. So, a team may decide on a tradeoff, but the downside to the guardrail metrics may prove to be overly negative. As the name implies, these metrics set the guardrails between which the cross-functional team has autonomy to operate.
The progress metrics are typically tracked by management but primarily used by the team itself as a basis for steering decisions on a weekly or even daily basis. When teams can see the impact of their actions in numbers, alignment emerges naturally. And when activity doesn’t result in progress, the metrics provide a powerful signal to stop and reconsider, rather than try harder.
Although all cross-functional teams need progress and guardrail metrics, one of the most powerful ways of organizing teams is around a quantitative value model rather than around components, technologies or functions. While each company has to develop its own value model, such models typically connect customer behavior and outcomes, or product or system capabilities and business impact, like revenue, cost, risk, sustainability or strategic positioning. They capture the highest-priority KPIs and provide relative priorities between these metrics. That allows teams to trade off between, for example, revenue and reducing technical debt.
In companies that have a clearly defined value model, we can assign parts of that model, or even individual KPIs, to each team, rather than assigning the team to a specific technical subsystem. This makes trade-offs explicit and enables rational prioritization when resources are limited, which they always are. Each team can then focus on its progress metrics while respecting the guardrail metrics.
Many organizations celebrate team autonomy as the ultimate goal, but that’s beside the point. The real objective is accountability for delivering value. Autonomous teams without clear accountability often optimize for comfort, local success or internal milestones. Accountable teams, by contrast, are explicitly responsible for outcomes defined in the value model. They have freedom in how they work, but there’s no ambiguity about how success is measured. This changes the conversation from “Did we finish what we planned?” to “Did we create the value we promised?”
Finally, cross-functional teams shouldn’t be treated as permanent structures. In a value-driven organization, team composition is fluid and evolves with value streams. As opportunities emerge, mature and decline, the mix of skills required changes. Teams should be reconfigured accordingly, adding data expertise when learning dominates, strengthening operations when scaling and reallocating capacity when value shifts elsewhere. Stability is comforting, but value creation is dynamic. Organizations that cling to fixed teams inevitably slow down as their environment changes.
Cross-functional teams aren’t an organizational fashion. They’re a logical consequence of taking value seriously. When teams own customer-facing value end-to-end, use quantitative metrics to guide decisions, are organized around a value model, are accountable for outcomes and evolve with value streams, they become powerful engines for continuous value delivery. Anything less is simply rearranging the org chart. The challenge isn’t forming cross-functional teams; it’s being willing to let value, not structure, drive the organization. And that requires you to be crystal clear on what constitutes value. To end with an African proverb: “If you want to go fast, go alone. If you want to go far, go together.”
