How Cross-Functional Teams Work

A New Goal

The success of cross-functional teams hinges on a fundamental shift in how we think about accountability and autonomy. In traditional structures, teams are held accountable for delivering predetermined features within specific time and cost constraints. However, cross-functional teams operate best in environments of uncertainty, where the goal is to uncover the best solutions quickly. This requires a different approach to accountability – one focused on product success rather than project delivery.

When teams are truly accountable for product success, they need the autonomy to decide what to build. Without this autonomy, accountability becomes meaningless. Teams will naturally distance themselves from outcomes with the attitude of "I just did what I was told to do." This is why cross-functional teams need to own the entire process from idea generation through to customer satisfaction.

Process Ownership: A Shift in Mindset

One benefit of a cross-functional teams owning the entire process is that we can streamline the process and eliminate a lot of the steps. We no longer need to do handovers for triaging ideas, getting approval or creating business cases. We can also remove old functional states like Analyse, Design, Develop and Test as all of these will be managed together by the team - there is no need for a handover. The process can be simplified to the following states:

• To Validate – Potential ideas that need further research.

• In Validation – Actively testing ideas for feasibility and value.

• Later – Deprioritised but not discarded ideas.

• Next – Ideas that are up next for development.

• Now – The team is currently working on these items.

• Awaiting Release – Completed work waiting for deployment.

• In Verification – Post-release monitoring and validation.

Some might argue that this is irresponsible because all of the governance checks have been removed. It’s not that all governance is completely gone, it is just done differently. The Product Team should be aware of the progress that is happening and raise questions if there are concerns. The major difference is a shift from asking permission to signaling intent.

Build End-to-End Speed into the Process

The goal is to get products in front of customers as quickly as possible. Backlogs are the biggest time delay for software development, so we can define our process to minimise backlogs, and therefore ensure high throughput speed. A key technique for achieving this is using Kanban with strict Work in Progress (WIP) limits.

From Push to Pull

Traditional development follows a push process, where work is pushed from one function to the next based on how quickly the first function can complete it’s work. Instead, cross-functional teams operate on a pull process, where work is only started when capacity is available. This approach keeps backlogs minimal and ensures rapid feedback cycles with customers.

But this raises an important question: What happens when some team members appear to be idle? Consider a scenario where designers have completed their work in the "In Validation" state, but the "Next" column is at its WIP limit. The traditional response would be to start new design work, creating a backlog. Instead, in cross-functional teams, designers help with development work.

The immediate objection is usually "But they don't have the development skills!" This is precisely the point. By participating in development work, designers learn how developers think and work. They provide immediate answers to questions, gain insights into technical constraints, and develop a deeper understanding of what information developers need most. This reduces documentation requirements as direct conversations replace detailed specifications. And the short WIP limits ensure context remains fresh, unlike large backlogs where details are often forgotten or misinterpreted.

Cross-Functional Collaboration in Practice

Cross-functional teams embrace teaming, where the whole team works together on the same problem at the same time. This approach moves away from siloed roles and towards collective ownership.

The entire team observes customer interviews, either in person or remotely, gathering firsthand insights rather than relying on filtered summaries. Ideation sessions benefit from diverse perspectives, leading to more innovative solutions.

Daily activities center around intense collaboration. The team moves fluidly between activities – from designing prototypes to breaking down solutions into stories to writing code – depending on what's needed to get features into production quickly. Problems are addressed immediately rather than waiting for scheduled retrospectives, maintaining momentum and preventing issues from festering.

You’re probably wondering if you read that right. But I really did just recommend to have a whole team working with one computer.

At first glance this appears incredibly inefficient - why have multiple people work on the same task when they could be working on different ones? However, the speed of writing code is not the bottleneck in writing high quality software.

1. Massively Reduced Rework – By having the full team involved in research, ideation and development we avoid the costly misunderstandings that happen whenever something as complex as a product is handed over between people. We also don’t need to do Pull Requests and Code Reviews anymore because everyone is working on the code at the same time.

2. Eliminating Context Switching – Since everyone works together on the same item, there is no need to re-explain requirements or revisit old issues. Studies on multitasking estimate that people can lose 40% productivity due to context switching.

3. Quicker Decisions - There is no need to put something on pauise to get input that you need. All of the brilliant minds are there so you cna get answers straight away.

4. Fewer Bugs – Because you have multiple people reviewing the code as it is being written, bugs get identified earlier. Companies like Hunter Industries have reported going over a year without a single bug in production due to the team-based approach.

5. Faster Learning and Growth – As members gain skills outside their primary discipline, gaps in the team shrink, and no single person becomes indispensable.

6. Systems Thinking & Continuous Improvement - With full end-to-end visibility of the process and all steps, wasteful processes are eliminated, and the team naturally optimises for efficiency.

Conclusion

This approach to cross-functional teams represents a fundamental shift from traditional software development practices. Instead of optimising for individual productivity, it optimises for team learning and product success. Rather than managing handoffs between specialists, it creates an environment where specialists learn from each other while delivering value together.

The success of this model depends on leadership's willingness to truly empower teams with autonomy and trust them to deliver results. It requires patience during the initial transition period when things might seem slower, and confidence that the investment in learning and collaboration will pay off through higher quality products and more engaged team members.

For organisations struggling with slow delivery, quality issues, or misalignment between technical solutions and customer needs, cross-functional teams offer a proven alternative. While the transition requires significant change in both mindset and practice, the results – faster learning cycles, higher quality products, and more engaged teams – make it worth considering.