You’ve probably heard the conventional wisdom that teams should be aligned around a common goal. But while it’s important to have a shared business objective, the idea that everyone needs to have the same goal is selling your engineering team short.

Productive tension is beneficial for organizations. In my engineering group, I have at least five teams with five different goals:

  • Product managers want to ship features as fast as possible
  • QA wants to ship features with zero bugs
  • Developers want to ship features with no technical debt
  • Operations never wants to ship new features
  • User Experience wants to ship features that users understand intuitively

These teams should have different goals. Each brings a unique perspective and different aspects of a project to the table, and while all of their goals are important, they are not singular. If one team is winning out over the others, you quickly learn that a single goal never creates the best product for customers. Having different goals drives teams to have critical conversations. And the necessities of business force a compromise that creates the best outcome.

People sometimes ask me if I favor a product-led or developer-led culture. When you’re running a business, you always need to be customer-led. Product managers can’t run the show on their own. Neither can developers. If one team wins out, the goal of creating the best product falls by the wayside.

For instance, if product dominates, you ship features more quickly. But you accrue more technical debt, so developers can’t achieve their goal. You also ship more bugs, so QA can’t succeed. And your UX team doesn’t have time to test new designs with end users, so they miss their goal, too.

On the flip side, if developers are in charge, any semblance of a timeline disappears, as developers work at their own pace. Product managers get derailed because they have no idea when things will ship. QA gets too much to test at once, making it hard to eliminate bugs. UX still has to fight for the time to iterate and test. And Ops isn’t ready for the onslaught when features are finally released.

The ultimate goal of satisfying customers causes different teams to dominate at different times. We’ve held a product for months if our beta users found it confusing, and spent more time in UX and development to get it right. We’ve also shipped features early, with pieces missing, to gain a quick hit in customer recognition, and then added to the product over time.

To mitigate these extremes, all teams need to have a voice and be heard. They also need to be sympathetic to each other’s goals and able to compromise. There needs to be understanding and tension.

A healthy tension leads to creative solutions. If you’ve organized your teams in the right way, taking into account personalities and opinions, each faction will be advocating for something unique rather than toeing the line of the dominant party.   

One solution our team has come up with to balance these tensions is with an internal beta program. The rest of the company acts as the voice of the customer and helps us figure out when we’re ready to ship. This allows us to ship as early as possible and still please our customers. By not setting arbitrary ship dates, we can focus on speed and quality and leave our customers out of it until the product is ready.

Of course, internal betas aren’t the only solution. If your teams keep pushing to do their best work, advocating from their particular perspectives, and being sympathetic to each others’ goals, they’ll be well-positioned to get the best product out in a reasonable time.