Tension has a bad name

tension gives us beautiful music

As long as you can dispel it, tension can be very positive (in life, business, and everything)

I have been trying to keenly observe organizational dynamics and structures, and I find myself interested in the myriad of startups who are mindfully choosing how they grow their structure (a la Holacracy but not necessarily the full dogma).

Although you can look at tension as somewhat an analogue to balance, we think of it very differently.

How do we use the terms in every day language?

He is balanced
I want to be balanced


He is tense
I don’t want to be tense

I took a peak at some definitions, and you see the various different angles of tension:

  • A force tending to stretch or elongate something
  • Mental, emotional, or nervous strain
  • Barely controlled hostility or a strained relationship between people or groups
  • A balanced relation between strongly opposing elements

It Always Comes Back To Solving Problems

Being mindful of organizational changes is tantamount to looking at the problems that you are solving and why vs. just looking top down.

One of the simplest tactics is to list out the problems that you want to solve in priority order, and assign the correct amount of resource to tackle the problem, including correct and real ownership of the problem.

When I think of it that way, it reminds me of tension. Tension occurs when that problems to solve list builds up. If you are making progress and delivering solutions the tension isn’t a bad thing at all.

You have probably felt that with todo systems. You feel like you have won when you check something off and may even be the type of person who after doing a quick task that wasn’t on the list, added and checked it off, just to get that feeling!

It isn’t always easy finding the problems

You can’t solve problems and get that feel good check if you haven’t found them in the first place. Nailing the core truth of a problem is more than half the battle. Working it out is tough, and next you have to prioritize. It takes a lot of work before you get to the execute step.

Rethinking tension in a good way

This brings me back to tension. Let’s talk about organizations for a second. In an ideal world you have the smallest possible team of people going after a problem that is well understood by the team. Unfortunately it is rare to work in this fictional universe. Chances are there will be some dependencies between teams, and as soon as that happens you have to deal with a different level of communication normally due to an alignment mismatch.

The misalignment isn’t (normally) malicious, but natural. You want small teams to have clear goals and outcomes. Ideally these would trickle down from the top, but just like trickle down economics, in practice this isn’t so simple.

If you grabbed a random employee and asked them to walk the trickle chain, do you think they would be able to follow this?

“I am working on $A …
… which helps the goals of the next release due to $B …
… which helps push on the outcomes for my team $C …
… which ties to the strategy of $MyGroup $D …
… which rolls up to the strategy of $MyCompany $F.”

You want the teams to be aware of the goals, and for their to be a clear escalation path.

How about some examples? I work on a team that focuses on mobile solutions in the retail space. What makes a great mobile retail experience? Some answer “a responsive great mobile app!” Well, what does great mean. It is important to get the application made as well as possible, but this is not the long pole. Some of the most important experience drivers are “assortment”, “discovery”, “fulfillment” [e.g. shipping] and “value”. These are not about some UI in the mobile app. This isn’t about lipstick. This is about the holistic experience for the user.

There are often many silos put in place that are for legacy/political reasons. There seems to be a similar pattern that occurs when a revolution or technology/market shift occurs.

  • The current org isn’t setup to take advantage of the change (and it may be in innovators dilemma territory)
  • The org creates a new lean small group to tackle the change at speed
  • At some point the two worlds are misaligned and it doesn’t make sense to have separation and we see things fold in.

Let’s look at the examples of the Web, and the mobile revolution:

  • A group is running commerce in brick and mortar
  • The Web happens, and a group is created to build the eCommerce arm of the company. At first this may include a separate marketing group, sourcing group, engineering group, etc.
  • Eventually there is so much overlap that it makes sense to bring together ONE marketing group that cares about online and brick and mortar. THERE IS ONLY ONE CUSTOMER.
  • Mobile happens, and a group is created to build the mCommerce arm of the company. At first this may include a separate marketing group, sourcing group, engineering group, etc….. even separate from the eCommerce groups (look familiar?)
  • Eventually there is so much overlap that it makes sense to bring together ONE marketing group that cares about desktop online, mobile online, and brick and mortar. THERE IS ONLY ONE CUSTOMER.
  • [rinse and repeat]

We are seeing this transition again for mobile. At first many companies would outsource the development of their iOS / Android apps. Then they moved to create internal swat teams. Now they are looking to infuse mobile into every team (hard to find the talent isn’t it!)

Many screens, many front ends

We are now in a world of multiple front ends. We have the desktop Web, mobile (Web and apps), “tablet” being somewhere in between since it is “touch” and “not a small device”, and much more. So many contexts, and these are exploding. How do you build out experiences? I was just watching a Pixar movie and thinking about the world that goes into the collective product: the movie, the music (albums), the rich applications, the web site experiences, the toys, the rides, and more. Phewph. I can only imagine the tensions that come up between all of those teams. What is shared vs. what can the separate teams fully own? Think about the time lines involved and the communication overhead?

I would imagine that there are many inputs, and many people acting as sensors for information across all of this work. At first you can imagine frustration, but if you deal with the inputs and allow people to act on them to dispel the tension then you are actually in a better place.

I think it is universally acknowledged that having “yes men” is not a good thing. Group-think comes in different shapes and sizes. Sometimes it is a herd following a lead sheep in which case you aren’t getting thought value from the other sheep. If you are working on something where the act of following is where the value comes, then this is a feature. Another pattern that you see is when consensus drives to a poor solution for all. Not only do you get the “lowest common denominator”, but you also see folks all “being nice” and this leads to people driving somewhere that no one wants to be “I thought you would have wanted this… you don’t?”

Service Oriented

With so many silos or screens, you start to see people wanting to “services oriented” (with a lower case “s”). This lead to horizontal organizations with “services teams” and “mobile teams”. If those teams have their own goals, then you will need to break a lot of ties:

“The mobile team is dependent on service X from the services team, but they are focused on fighting a fire on service Y!”


Then you see teams oriented not around a platform, but around a set of features, or ideally around a customer. Imagine a pharmacy team that has all kinds of engineers, product managers, and designers all focused on the pharmacy business across the various screens. The experience is for various pharmacy customers, and the outcomes trickle down from there.

What if someone on the pharmacy feature team has a different idea for something that is part of a particular platform? You need a way to break that tie.

An Aside

“We need a butt in the seat”

Time and time again you hear people talk about how you shouldn’t lower your bar. It can be hard to keep that will power when you have pressing demands and ship dates to make. The competence issue that arises from this really shows through when you get someone to fill a role in a competency, and someone else from another discipline can actually do a better job.

Imagine an engineer who is great with product or design. It can happen the other way around too, but that seems to be more rare probably because engineers will care about product or design more so than product / designers may care about coding say.


I believe in the fly wheel effect when it comes to delivering product. Get good at tightening the turns. Rinse and repeat. Want to get better at shipping software? ship more.

Want to dispel tension? Find some areas to do so easily and take care of it.

Also, what is a great way to relieve tension in the physical body? Focused diaphragmatic breathing.

If in doubt, breathe.

Leave a comment

Your email address will not be published. Required fields are marked *