You’ve most likely heard the term ‘healthy tension’ before, in work or otherwise, here are my thoughts on why it’s an essential part of an effective, happy Product team and beyond.

What is healthy tension?

My handy definition:

Healthy tension is the productive disagreement between two or more individuals, where all parties agree on a shared objective but disagree on how to get there

There are a few things here to unpack and I will share some examples of this from my experience below, but for now the most important addendum is that if the tension is arising from anyone feeling that they themselves are being criticised then that is not healthy tension. It’s the other thing. I can be critical of an idea, a method, or a plan, but it is not helpful or constructive to be critical of a person.

A team is defined by a shared objective that’s clear and actionable (in Product this is classically something like grow the overall audience of the product or identify opportunities to fulfil an underserved audience need). Ultimately, everything that team does will be aimed at achieving that objective. A shared objective can of course reach far wider than a single team – a product development team, marketing team, and sales team could all be focused on delivering profitability to a company, for example – and this enables healthy tensions between all sorts of different groups, especially in smaller companies.

Productive disagreement is completely dependent upon a shared objective. In this context, what I mean by ‘productive’ is that the outcome is improved by the additional consideration that disagreement generates. Sometimes this is a very explicit thing, like a compromise which considers both business value and the health of the team (see example 1 below), but far more often the benefit is subtle – it manifests in the evolution of approach or attitude deployed by individuals in that team (example 2). Without a shared objective, disagreements may either go unresolved, be resolved by hierarchy/authority, or one group may become uncomfortable and back down – in these cases the outcome has certainly not been improved by the disagreement.

What enables healthy tension in a team?

There cannot be healthy tension within a team if there is not respect. In a workplace scenario we can break respect down into two basic beliefs:

1. I believe that the person is authentically engaged in achieving our shared objective
2. I believe that the person has something useful to share (this is always the case – never underestimate the power of a second opinion from any source)

Respect within a team is not quite enough by itself – healthy tension is dependent upon healthy debate. This is a whole other topic, but effective debate rarely involves absolute language like wrong, better/worse, don’t, etc. Effective debate creates wiggle room and allows people to shift their perspective without feeling they have abandoned their original position. Effective debate is a living demonstration of empathy and give and take.

Examples of healthy tension

Here are a couple of examples of healthy tension I’ve experienced. There is no right or wrong decision here, there are at least two valid options, but in both cases I feel the outcome was improved by the productive disagreement we had in the team. I hope this helps you to reflect on your own experiences and how you can introduce more healthy tension in your environments.

Example 1: I am working on a re-platforming programme for a client's subscription-based service, and my team are under pressure to deliver improvements fast as momentum on the programme has slowed due to political issues in the organisation. The design lead on the programme has revised a template that a developer has already started work on. I don't want to have the developer re-work the UI to match the latest version of the designs due to time pressure, but the design lead has solid user-centric reasoning for the change. 

Myself, the developer, and the design lead get together for a 20 minute review of the changes, and assess the level of effort - we're able to identify some straight-forward aspects of the latest designs which can be incorporated with very little effort - the developer handles these, and the design lead reverts what was left in the new version to match the build. We've collectively lost a couple of hours of productivity.

I could have rejected the design lead's updates outright. After all, they knew the work had started, and we did in fact end up losing time. But had we found no compromise, the designer may have felt that we were not equally invested in building a great product, and any future sparks of inspiration may have been snuffed out. Ultimately, the quality of the product may have suffered, which could further damage our reputation with the client.

Example 2: It's a Friday afternoon and I want a bug fix released fast. Users are complaining on social media and the product's reputation is at risk. Our project manager argues that we should never release to Production on a Friday, because if something goes wrong there will be no support over the weekend to resolve it. I'm insistent that the fix has low technical risk and it is worthwhile to release it. 

The project manager reminds me of the team members we would need to coordinate the release, and the responsibility they would take on should something go wrong. It seems to me it would place unnecessary risk on the team to proceed on that basis. I agree to delay the release until the following Monday. 

I could have pushed through the Friday release. I had validated the technical risk with our tech lead and it may have given us a boost with our audience going into the weekend. But if something had gone wrong with the release - the process itself, some unexpected bug it introduced, some delay in approval on the App Store side - then I would have created extra work for my teammates when they should have been winding down for the weekend, and for nothing. Even if it had gone well, in future I might be emboldened by the experience and push for a Friday release for a minor issue, gaining less value but with the same level of risk. Ultimately, the stability and predictability of workload on the team was more important than getting the value from the fix a few days early, because a happy team will perform better over the long-term (and don't forget: the kind choice is never the wrong choice).