Common Objections to Empowering Teams (and How to Rebut Them)

Managers have built their careers excelling in the current way of working. They have worked their way up the ladder, following the orders of those above them. They are now in a position to influence the direction of the products and they are now being asked to relinquish that control. But they are also going to stay accountable for the success of the products. Admittedly, it is a hard sell.

Empowering teams breaks processes, alignment methods, governance approaches, team structures, funding models, and more. So any company considering adopting the approach is likely to have reservations because, as I mentioned above, any failures will come back on the managers leading teams. Let’s review the most common objections.

Wasted Time and Effort

Objection: If management doesn’t choose initiatives and teams can decide what to build, how do you ensure they choose the right things?

Response: Good decisions are based on:

• Context: Teams need to understand the product vision and strategy.

• Shared Values and Principles: A strong foundation for decision-making.

• Incentives: Teams should be aligned with business outcomes.

• High-Quality Data: Teams must have direct access to real user data.

• Experience: Teams learn from past successes and failures.

There are two teams type when it comes to empowering teams: The Product Team staffed with the Product Manager and Functional Leads and the Stream Teams staffed with the marketers, designers, developers and others building the product.

The Product Team is responsible for setting the right context with the values, principles, vision, strategy, product metrics, quarterly objectives, and team incentives. Stream Teams are accountable for the success of their value-stream (part of the Product).

It isn’t easy ensuring that everyone has the right context. It is much easier just to tell teams what to do. But the effort is worth it as it is more scalable and it frees up time for functional managers to work on more strategic work instead of admin work. But it isn’t completely hands-off. The Product Manager, in particular, operates on a Certify, Don’t Brief model where they retain oversight of what teams are doing, but not dictating what they do.

Another bonus of the decentralised model is that, since Stream Teams are closer to the actual data, they can often make better decisions than management because when information moves up the chain, it gets distorted and sanitized, losing valuable insights.

Teams Will Waste Time Duplicating Work

Objection: When teams can decide what to work on there is a risk that they will all end up chasing the same ideas and duplicating work. Have a management overview of work stops this from happening.

Answer: One of the key ingredients in an empowered team is autonomy. And autonomy covers many dimensions:

1. Decision autonomy - teams need to be able to make decisions about what they are working on

2. Scope autonomy - teams need to have a dedicated part of the project that is their own

3. Code autonomy - teams need to own their own code related to their areas of scope

4. Release autonomy - teams need to be able to release when they want to

One of the key challenges for Product Teams is to design the boundaries between Stream Teams to ensure that they are independent. This isn’t easy, and often requires a number of iterations to get right, but it is critical for the success of the teams. Without autonomy teams will never be truly accountable.

There is a second issue though, we don’t want every team to re-invent the wheel. There will be pieces of functionality required across the product. For this we need to introduce a new team: Internal Product Teams.

Internal Product Teams abstract away some of the repeated complexity from Stream Teams so that they can focus on the delivery of business value instead of repetitive work. Some common examples in many organisations are Design System teams as well as Platform teams.

There are two reasons why I call these internal product teams instead of platform teams. The first is that they need to think of themselves as products. The risk with a centralised team is that they start to act as a monopoly, and monopolies are not known for being great at customer service. By acknowledging that they are products, they need to engage in the same continuous research, continuous design and continuous development as customer-facing product teams.

The second is that this also includes internal departments such as Finance, Legal, Research, Marketing etc that might see themselves as service providers rather than products. But everything can be productised. Operations > AWS. Logistics > Fulfilment by Amazon. Finance > Haier Finance. In each example an internal department productised so successfully that it offered its service externally (and incredibly profitably).

That’s How We Work Already!

Objection: Agile keeps renaming things, but nothing really changes. One of the main arguments for empowering teams is reducing backlogs which slow down delivery, yet you still have backlogs in your new process (e.g., In Validation, Later, Next, Awaiting Release).

Response: There is a fundamental difference between a backlog as a handover mechanism and a backlog as a to-do list. In empowered teams:

• The backlog is created by the team as working notes rather than as documentation for a handover.

• This means that the level of detail is much lower, allowing for flexibility in the implementation

• WIP (Work in Progress) limits ensure that backlogs remain lean, keeping items fresh in memory rather than letting them sit for weeks or months.

With empowered teams, you change from working as a team of functions to a cross-functional team. This subtle wording difference is actually a significant change in how people on the teams work. There are no internal handovers within the team. You don’t create detailed documentation to handover between two people within the same function today. Cross-functional teams extend that concept to the full team.

Low Detail Documentation = Low Quality Work

Objection: This approach sounds like a recipe for low-quality work. Handover documents ensure that there is a certain level of quality achieved before work moves from one phase of delivery to the next.

Response: Detailed documents lock in assumptions. Even when teams invest in upfront design and prototype testing, risk is reduced, not eliminated. True validation happens only when real customers use the product.

When everyone is involved in customer interviews, ideation, and testing, there’s less need for lengthy documentation - everyone has the context that would have been written about in the handover. Also, since WIP limits are so low the context is fresh when people pick up an item and do not need to rely on extensive documentation to refresh their memories. Instead, teams should:

• Use customer quotes directly in backlog items - to keep the problem that is being solved front and centre.

• Focus on the identified opportunities (outcomes) rather than excessive documentation (outputs).

• Iterate quickly to get the product into customers’ hands as soon as possible.

It’s Inefficient - People Will Be Idle

Objection: If strict WIP limits are enforced, some people will be idle, leading to wasted resources. For example if the developers are busy then the designs are stopped from doing more work until the developers have capacity again.

Response: This issue arises when teams are structured around functions rather than being cross-functional. To solve this:

• Move from a team of functions to cross-functional teams.

• Instead of people working on different parts of the process separately, the team should work on all parts of the process together. This means designers working with developers while coding and developers working with designers while creating prototypes.

• While pairing is a good approach, you can take it to the logical extremes with a mob programming/teaming approach. The whole team works on a single computer. Therefore everyone is focused on the task at hand.

With this setup, no one is idle - everyone is either contributing or upskilling, and decisions are made faster with higher quality.

Teaming Is Even More Inefficient

Objection: A whole team working with one computer is inefficient. Wouldn’t it be faster if everyone worked separately?

Response: Typing speed is not the bottleneck in software development. Product development is a design problem. And like other design problems the quality of the design makes a huge impact on the success of the product.

The biggest inefficiencies in software development are, in priority order):

• Products that customers don’t actually want. This can be caused by locking in solutions too early in a Big Design Up Front, or by miscommunications that occur when handovers occur during delivery.

• External Blocking sign-offs. When teams are blocked waiting for official sign off or confirmation to proceed.

• Backlogs increase lead time for development

• Internal blockers: Code reviews and pull requests introducing delays and rework.

• Bugs: Issues that cause the team to have to rework previously finished items.

• Context switching, as people get asked questions about items in a backlog or for a code review, reduce productivity.

• Onboarding: Bringing new team members up to speed on the product, business and ways of working.

Empowered teams solve the first two issues, by being held accountable for outcomes rather than outputs. If the product doesn’t achieve it’s goals then it isn’t finished. Empowered teams also get to decide what they build so they do not get blocked waiting for external sign off.

Mob programming eliminates the other inefficiencies by ensuring:

• Zero internal backlogs, since the team are all working together.

• Real-time decision-making, because all of the experts are in the room together it removes any internal blockers.

• Higher code quality, as more people reduce the likelihood of bugs slipping through. And the way of working increases the level of knowledge across the team reducing the risk of low quality code and associated bugs.

• No context switching, as the team works on each item until it is completed before picking up the next item.

• Faster onboarding, since new team members learn by doing.

Hunter Industries, where software teaming originated, were so satisfied with the efficiency of the approach that they expanded it from the test team to all teams in the company. In a testament to the quality of the approach, they reported zero production bugs for over 1.5 years.

What If People Don’t Want to Work Like This?

Objection: Teaming requires constant engagement, which some people may find draining. Some people prefer working alone.

Response: Software development is a team sport. While some individuals may prefer working solo, this approach leads to the efficiency and effectiveness problems that we have today.

If there is pushback, it is best to try to uncover where it is coming from:

• Some people resist teaming because they feel exposed. Remind them that the goal is to fill knowledge gaps, not highlight weaknesses.

• Some prefer solving problems alone for personal satisfaction. It feels great to solve that difficult problem - its an ego boost. When teaming those big challenges often disappear because the team can work through it much more efficiently. Try to get people excited by the product vision so that progress is rewarded.

• If people claim to be introverts, that is true of almost all software teams. Yet when people who do teaming are asked whether it has an impact on the success of the team they say no.

In sports, one superstar doesn’t win games—teams do. The same applies to software development. Try to encourage people to give it a shot. Listen to their concerns and do your best to accommodate them, where realistic. IF there is a particularly effective person who strongly prefers working alone they might be better suited for an Enabling Team rather than Stream Teams.

We’re Relying on Each Person Being an Expert

Objection: This works in theory, when everyone is an expert at their role. But in real companies there is a mix of different skill levels. A cross-functional team might have only one person per skill set. What if they aren’t experts?

Response: This is an issue that needs to be addressed. The answer is that we need to upskill people a lot quicker than we do today. There are three elements that we need to improve:

• Knowledge: Understanding of all of the different aspects of the role and the best practices.

• Skills: Applying those practices effectively.

• Experience: Having the situational awareness to know what to do in each situation.

We need to introduce a new team type to address this challenge: Enabling Teams.

Enabling teams are staffed with the most senior functional experts and have a few different areas of responsibility to help address the skill gaps above:

• Knowledge: Enabling teams define role levels and expectations for each function, create best practice guides and organise Communities of Practice to encourage cross-team sharing

• Skills: Creating curricula and workshops to upskill people as well as more hands-on mentoring as required

• Management by Walking Around: One risk is that people are not aware of the areas where their skills are lacking. If there are no other experts in the team then these gaps can go unaddressed. Enabling Teams need to observe different teams in action to pick up on these gaps and address them.

One of the benefits of a long-lived cross-functional team is that they become experts in their value streams. However we need to balance that local expertise with broader business context and expertise. We can address this by periodically rotating people across teams.

How Do We Upskill Junior People?

Objection: It’s unfair, on both the person and the team, to expect a junior employee to be the only designer or developer on a team.

Response: That’s true. It would be unfair. But we need a way to upskill both junior people, as well as new hires, quickly. To do this we can adopt an apprenticeship model. This gives people real, practical experience in how to operate on teams. An apprentice should rotate across 3-4 teams before moving on to their own team. The length of the apprenticeship on each team really depends on the level of upskilling required.

My Teams Aren’t Mature Enough

Objection: This might all work great on teams with high agency people who are ready and willing to take on extra responsibility. But it won’t work with my teams.

Response: A lot of people try to throw this back at manager blaming them for hiring low agency people or lacking trust in their team, but I don’t think that is fair. There are definitely people that prefer the current approach of doing as they are told. The additional accountability of having to decide what to do will not work. If you tried to make everyone work this way tomorrow it would fail.

But there are some people who want more ownership, who want more autonomy and who are willing to step up. You should start there first.

There is always a bit of risk involved when empowering a person or team for the first time. But there is a Catch-22 that unless you empower people they cannot demonstrate that they are capable of being empowered.

My Organisation isn’t Mature Enough

Objection: I’m on board. But I’ll never be able to convince senior leadership. It’s just a step too far for us.

Response: Without senior leadership buy-in, any attempts will fail. I’ve seen amazing empowered teams fly under the radar for a short period of time before being noticed and their way of working being crushed.

Before investing significant time and effort it is worth getting a quick feel for executive buy-in. Most executives already know that they don’t achieve the benefits of their business case and they believe software development can be more efficient. But how much are they willing to experiment with. A simple, anonymous vote would tell you how likely any transformation efforts will be:

How willing are you to experiment with the following (options are: Full experimentation, limited experimentation, cannot touch)

1. Process - how product work is identified and delivered

2. Structure - how teams are structured and their reporting lines

3. Funding - how funding is allocated to teams - a.k.a. business case changes

4. Governance - how we track that teams are working efficiently and effectively

5. Alignment - how we ensure that teams are working on the highest priority items

If anyone answers “cannot touch” to any of the items it is not likely that you will be able to convince them. The more “limited experimentation” answers you receive the bigger the challenge will be. Nobody will want to say out loud they will be a blocker so it is really important that the survey be anonymous.

Once you have executive buy-in, you can start small, with a single team on a medium complexity and importance area. You don’t want to go too high and risk a costly failure, but equally you don’t want to go too low where people will ignore your successes.

I Don’t Like It / I Don’t Believe You

Objection: I really disagree with the whole ZeroBlockers approach. This all sounds theoretical, but does it actually work in practice?

Response: That is fine. There are many incredibly successful companies out there, each working in different ways. However, ZeroBlockers isn’t theoretical - it is all based on hundreds of real case studies. The framework is the result of years of working on the UXDX conference series sourcing case studies from companies improving their ways of working. The framework is the result of codifying their experiences so that people can stand on the shoulders of giants instead of having to reinvent the wheel.

You can read over 180 case studies where people share how they are improving their part of the product delivery lifecycle on the ZeroBlockers site.

As W. Edwards Deming famously said: “It is not necessary to change. Survival is not mandatory.” Organizations can choose to continue working the way they always have, but those that adapt tend to thrive.

Conclusion

Empowered cross-functional teams challenge traditional ways of working, but they ultimately lead to higher efficiency, better quality, and faster decision-making. Addressing these common objections with well-structured responses can help organizations successfully transition to this model and reap its benefits.