How motives, metrics and time divide business and tech

Business and tech approach problems differently

Why do the business and technical sides of an organization so often frustrate and disappoint each other? This is the second of four articles in which I explore that question, along with some possible solutions.

Business teams focus on the outcome, while technical teams focus on the problem.

This separation results in two very different approaches to problem-solving. And that can seriously handicap effective collaboration between the two teams.

In our client work over the years, we have repeatedly seen three underlying factors that cause this:

• Different motivations

• Different metrics and incentives

• Different understanding of time.

If your project requires a cross-functional business and tech team, and you want to set them up for success, it will pay to understand and address these three potential derailers.

Different motivations

Businesses make decisions or take actions to bring about change. They want to improve the performance of the company, and they are motivated by achieving this outcome. Technical folks, on the other hand, are often motivated by solving interesting problems.

They got into this field for the pleasure of figuring it out, and they are trained that a “problem” is more like a puzzle. It’s what someone tells you to get an “answer” to, but there is rarely a connection to making a change in the real world.  

What could possibly go wrong? A debacle we have seen play out more than once is when the business asks the technical team to build something expensive (a real-time dashboard, for example). The technical folks build it because it’ll be fun to try out these new tools, and besides, the business folks said they needed it, right?

Many months and a lot of money later, both sides are disappointed and angry. Why? Because the business had already decided that a real-time dashboard was essential to achieve the outcome they wanted, before they asked the technical team to build it. And the technical team didn’t ask what outcome the business was trying to achieve, and whether a real-time dashboard was the best way to get there.

Different metrics and incentives

The business usually measures success by how much its investments have improved performance, so it looks to things like revenue and profit, market share, productivity, cost reduction, supply chain efficiency, speed to market, and so on. The business team’s incentives will be tied to those metrics.             

The definition of success for the technical team is usually about how well they solve problems, not how much they improve outcomes. Their metrics and incentives will typically focus on things like system uptime, time to recover after a failure, task throughput, and accuracy of development effort.

Badly chosen metrics can unintentionally incentivize the very behavior you don’t want. Sometimes, for example, technical folks take those “t-shirt estimates” of the work and then start defining success based on how many tasks they get done and how hard they expected those tasks to be. This encourages the technical team to overestimate how hard the work is, and later to deliver exactly what was planned or they will be expected to always deliver to those higher levels.

Measuring programmer productivity by “Lines of code” is another example of focusing on output instead of outcomes, as the metric incentivizes quantity over quality.

Different understanding of time

When you don’t understand what it takes to get it done, every task looks quick and easy. One of the biggest red flags for any technical team is an urgent and unexpected request accompanied by the phrase “this should be easy.” It rarely is.

Here’s why. The systems that the technical experts build and use are complex and interdependent. Largely because of this, the sequence of the work matters and so does the approach. The work to develop or modify a system that will produce the outcome the business wants is like scientific research. It’s a series of “experiments”, that are modified and repeated until you find the “formula” that delivers the results you need without damaging anything else in the process.

Results take time, so there is often a “backlog”.  Technical folks also have a really high cost of context-switching. Introducing an unexpected “this should be easy” request into this scenario can be frustrating for both parties as it disrupts flow for the technical team while still failing to meet business ideas of urgency. This is where really experienced technical leads try to set appropriate expectations.

Ignoring the interdependencies of technical systems causes two other time sinks we often see. Either one can damage the durability of the system.

Building a robust system is very different than building a one-off. Business folks and inexperienced tech folks underestimate this very badly. So, then you have the business person going to the one tech person who “gets stuff done for them quickly.” Except it’s wrong. The result? The technical team loses a lot of credibility, while the business loses momentum.

The second time sink weakens security. It happens when unqualified technical folks are assigned to set up your systems securely. They end up flailing around and doing it badly. Eventually you give everyone admin access, because that’s the only way people can do their jobs at all. So much for security.

In this and our previous article we have focused on some of the common missteps in the relationship between business and technical. In the next article in the series, we will explore how to lay the foundations for successful collaboration.