UXDX Blog
The UXDX Blog has its own subscriptions, separate from our newsletters.
The Product Model #265 - Upskilling On Cross-Functional Teams
The strength of cross-functional teams lies in their diversity of skills and perspectives. However, this same characteristic presents a unique challenge: functional isolation. With typically just one person representing each speciality, if someone lacks proficiency in a critical
Read edition ↗
Upskilling on Cross-Functional Teams
Ideally, every team member would be highly skilled in their specialisation. However, in reality, people have varying levels of expertise. In functional silos, skill gaps are easier to identify and address through mentorship and training. On cross-functional teams, with fewer func
Read edition ↗The Product Model #264 - How Cross-Functional Teams Work
Cross-functional teams are tasked with achieving outcomes rather than outputs. This means that they can streamline the traditional product delivery lifecycle to remove the unnecessary blocking handoffs.
Read edition ↗
How Cross-Functional Teams Work
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
Read edition ↗The Product Model #263 - Why We Need Cross-Functional Teams
Functions are optimised for efficiency. But the efficiency of each function does not translate to the efficiency of the system. You would think that if each function is becoming more efficient, then how can it slow down the system? Backlogs.
Read edition ↗
Why We Need Cross-Functional Teams
In the early 20th century, Frederick Winslow Taylor revolutionised work with the principles of scientific management. The goal was simple: maximise efficiency by breaking down work into specialised functions, with each department focusing on its specific area of expertise. This a
Read edition ↗The Product Model #262 - The Hidden Barrier to Team Empowerment: The CapEx-OpEx Divide
In the push to empower cross-functional teams, one of the biggest challenges isn't technical, cultural, or even organisational—it's financial. Specifically, the division between capital expenditures (CapEx) and operating expenses (OpEx).
Read edition ↗
The Hidden Barrier to Team Empowerment: The CapEx-OpEx Divide
The seemingly mundane financial categorisation between CapEx and OpEx creates unexpected barriers to modern organisational design and team autonomy.
Read edition ↗The Product Model #261 - The Role Of An Enabling Team In The ZeroBlockers Framework
One of the biggest challenges when shifting from a project-based model to a product-based model, is that the different functional experts can become isolated from each other. Instead of working, and often sitting, together, functional experts are scattered across multiple teams.
Read edition ↗
The Role of an Enabling Team in the ZeroBlockers Framework
In the Team Topologies framework by Matthew Skelton and Manuel Pais, there are four fundamental team types: Stream, Platform, Complicated-Subsystem, and Enabling. An Enabling Team is a specialised group composed of domain experts who help Stream Teams (and sometimes others) becom
Read edition ↗The Product Model #260 - The Evolving Role of the Functional Manager
If we move to long-lived, decentralised teams, what happens to the functional managers who were leading the functions? People belong to their team now, and not a function anymore so there is no need for resource allocation and budgeting.
Read edition ↗
The Evolving Role of the Functional Manager with Empowered Teams
Historically, functional managers juggled numerous responsibilities: resource allocation and budgeting, stakeholder management, strategic planning, endless meetings and reporting, process definition, technical leadership, team culture building, problem-solving, and talent develop
Read edition ↗The Product Model #259 - The Role of the Product Team in ZeroBlockers
I think the term "Product Team" is often misused in the software industry. Often it is used interchangeably with the teams building the product. However, a product is typically too large for a single team to build, requiring multiple teams to focus on different value streams. The
Read edition ↗