Why communications break down

The gap between technical and business

Writer Ambrose Bierce once defined a conversation as “a vocal competition in which the one who is catching their breath is called the listener.”

If you have ever sat in a meeting between technical and business teams, then you have seen his definition in action. Unfortunately, the real-life consequences of this miscommunication can be anything but funny.

Why do the business and technical sides of an organization struggle to communicate and collaborate effectively? This is the first of four articles in which I will explore that question along with some possible solutions.

In this piece, I will focus on three common obstacles that I have seen repeatedly frustrate efforts to get technical and business folk to work together as one team on a project:

• Different mindsets

• Different assumptions

• Lack of curiosity about each other’s world.

Let’s take a closer look at each of them

Different mindsets

The business team has usually agreed on the strategic objective of the project before they bring the technical folks into the conversation. Consequently, the technical folks don’t hear the nitty gritty debates about how much information is “enough” to make a decision or what would be useful to achieve the strategic goals.

This gets compounded if the information that the business folks then ask for is not exactly right. For example, if the request leaves out something that really matters to the business, and it’s not obvious to the technical team.  Oddly, the business team often thinks they already know what needs to be done technically to deliver the results. They don’t always value the perspective the technical team can provide on how to achieve the business goals.

To help bridge this gap, we’ve found it helpful to make both sides a little uncomfortable as they meet in the middle. We have the business side present their goals first, without recommending solutions. We then ask the technical team to suggest possible solutions, along with how those solutions might realize the goals. The business side might realize they were missing a crucial requirement, and a healthy debate ensues as the two sides come together on what should be done and how to do it.

Perverse incentives can also gum up the works sometimes. As an example, business folks love investing in Minimum Viable Product (MVP) and Proof of Concept (POC) projects because these stripped-down versions can greatly reduce the investment required to see the potential benefits. Technical teams know that these projects are only a first step towards a working system.

The biggest red flag for the technical team is when the business folks say, “this should be easy”.  It so often isn’t easy for reasons the tech team knows intuitively, but can’t put into words, so they refuse to give an estimate of how badly things could go.

Without that push back, the business team doesn’t take a hard look at the expected ROI and whether the project is worth doing at all. The technical team sees the trouble coming, but that ‘risk’ is left out of the discussion.

Different assumptions

A lot of data analytics projects run aground on the rocks of unspoken assumptions that not everyone shares. 

Business folks have a vague understanding of how technical work gets done and assume that if you have a proof of concept, you’re a stone’s throw from the real deal. Unfortunately, it’s rarely so simple.

The technical side might build the POC, and the business says “this is great, lets ship it next week.” This situation is a nightmare unless the POC was overengineered. If it was, and they don’t go on to publish it, you wasted energy and time. In either case, the company loses rooted in different assumptions.

Technical folks have some insight as to which things are hard, and which are easy. Often, they’re wrong too, so they assume it’s better to go with vague statements like “this might be harder than you think” instead of getting specific. It’s crucial everyone has the same information like “last time we did something similar it took 100 hours. It might be faster this time, but at what point is this feature not worth it?”

Analytics work often suffers from another assumption made by the business team, that the data we’re working with is “good” or at least “good enough.” The risk is that analytics models exaggerate the bad information, so just a little bad info can lead to disastrously bad output.

This surprises the business folks, and leads them to condemn the whole model, because people have been successfully working with the same data already.

One of the most misleading assumptions is that when the business team ask for something, they know what they want. I’ve written about this before, using the idea of “requirements” versus “desirements.”

Business folks have a different understanding of how useful a certain thing might be, and often the technical folks have their doubts, but they keep quiet and deliver what they were asked. The resulting mistake could have been avoided with better communication.

Shared lack of curiosity

This is the hardest to forgive and the easiest to fix. Both sides are guilty of maintaining an almost willful ignorance of how the other side thinks and sees the world.

How many business people know why their technical teams use “t-shirt sizing” to estimate how hard (and therefore how expensive) some piece of work is? The idea is to prioritize better, even though that’s hard when so much is unknown.

So the technical team says, “This task is a Large, and this other one is a Small.” Which is supposed to mean that the large is roughly 4x the work the small, but also “who knows?” The business team is left out entirely since they work in dollars, not difficulty.

On the other side, the technical folks often prefer to focus on whether the model is technically accurate without thinking about the practical impacts. How to successfully handle change management is one of the first questions a business team might ask, while the technical folks believe that’s someone else’s problem.

There’s a saying among analytics professionals that “all models are wrong, but some are useful.” The real world is highly complex, and we can never model it fully. Business folks often don’t know what that really means, or they think it’s preposterous to even try. Many technical folks feel the same way.

That is a failure of curiosity on both sides. The challenge is to discover which are the imperfect but useful models. This is where operations researchers and other experts in modeling take a contrarian stand. We say you have to try because good decisions depend on it.

Have you seen analytics projects fail because of poor communication (or none) between business and technical teams? Let me know in the comments.

In the next article in this series, I will highlight another aspect of the divide between business and technical: their different approaches to problem-solving.