Hate is a strong word to use. ‘Often dislike’ may be a better description. Whatever words we use, there is no doubt business stakeholders don’t love talking to IT teams.

It will come as no surprise to many of you to hear that there is a problem with business and IT teams communicating. If you don’t believe me, take a look at the years of Dilbert comic strips created by Scott Adams.

An important step in solving any problem is to understand it. If we can name the things that cause us pain, we stand a better chance of finding ways to improve. To that end here are the 10 most common reasons business stakeholders hate communicating with IT teams.

1. Business stakeholders don’t understand the words IT teams use

Jargon, technical language, accurate terminology. Call it what you will, but business and IT teams speak different languages.

Lack of a common language makes it harder for business stakeholders to talk to IT teams. When we have to put extra effort into communicating it makes everything just a little bit harder.

2. Business and IT teams care about different things

IT teams care about system stability and building it right the first time. They care about low technical debt, future proof, scalable solutions and more.

Business teams care about getting the problem fixed quickly and cheaply. They also want it done in a way that they never have to come back to talk about the issue again. The lack of common goals between business and IT teams is a major source of friction.

3. IT teams don’t understand the business processes and goals

IT teams often work in isolation from the business processes. Focusing on the systems rather than the user experience or outcome. Not knowing how technology supports business goals makes problem-solving discussions less effective.

Understanding the business processes and goals provides valuable context for the IT teams. When IT teams understand the processes their systems support, they develop better solutions.

The opposite is also true. Business teams should have some understanding of the systems that support their processes.

4. Business teams have to drive the communication

Company culture often results in IT teams not communicating proactively. The IT teams are business building the solution. This means communication waits until the weekly project meeting.

If updates are positive that is OK. But if there are issues and delays, waiting a few days to share this in a project meeting is frustrating. This leaves business teams feeling like they must drive all communication. More proactive communication from IT teams can help resolve this.

5. IT teams interpret requests literally (instead of trying to understand intent)

Developers, engineers, and other technical professionals tend to be quite literal. This is not surprising if you consider that computer code must be literal. partly down to the nature of the work — everything is ones and zeros.

These things all add up to a literal interpretation of information given by the business. The result is that IT builds what business asks for.

If a business team asks for a report that delivers X, Y and Z, that is what the IT team will build. If the business team don’t articulate the exact specifications, they will get what they asked for. Unfortunately, that doesn’t mean the business gets what they need.

The solution is for IT teams to take time to ask about and understand, the goals of business requirements. Developers are more likely to deliver what’s needed if they understand the goal.

6. IT professionals give too much detail — conversations take forever

I know it is a stereotype, but stereotypes sometimes exist for a reason. Technical professionals tend to take a long time to explain things. The thing is, it’s because the topics are so darned complex. It is also because of a lack of structured communications training.  IT professionals are not trained on how to summarize complex topics. Technical degrees and jobs come with little communication training. And yet employers expect great communication skills from technical staff.

The solution is to learn how to be clear and concise. Find out more about how to do that in The First Minute.

7. Even small change requests costs too much

IT changes are complex. They often involve multi-step design, build, test, approve, and release processes. It takes time to ensure the changes don’t introduce any new issues. More time to build and test means higher costs.

Business stakeholders are rarely aware of the steps involved to put a change in place. And if they are aware of the process, they don’t often understand the need for all the steps. This lack of understanding about development and release processes results in a perception that IT changes take too long and are too expensive.

8. Business stakeholders don’t understand why IT changes are so complex

Asking to add a new field or column to a report sounds easy. It’s just like adding a column in Excel, right?

What can seem like a simple request from the business can often be complex behind the scenes. The business stakeholders don’t have the system knowledge to know that a new field in a report might be complex. It may mean building new crosswalks between databases written in different languages. That’s a bit more complex than adding a column in a spreadsheet.

This lack of awareness leads to frustration. Especially when something a business stakeholder believes is simple ends up being expensive.

The inability of IT teams to articulate the challenges in ways the business understand makes this problem worse.

9. The business hates being constrained to release schedules

‘My customer has a problem today and you’re saying it will be fixed in eight weeks?’. If you work in IT you’ve probably heard some version of this. Maybe you heard it today.

When the business has a problem, they want it fixed today. Unfortunately, the need for scheduled releases makes daily updates impractical. OK, OK, so Google and Microsoft release code every nanosecond. But they are the exception. Many companies still operate on monthly release cycles.

Business stakeholders might be less frustrated if they understood the need for controlled releases. But, even so, IT release processes are often not fast enough for the business to respond to urgent needs.

10. IT teams ask the business questions they don’t know the answers to

IT teams want to understand the detail  (see 5 and 6 above). They need detailed information to be able to build the things the business needs. Unfortunately, the business teams don’t always have the answers. No one likes being asked questions to which they don’t know the answer. It reminds us of when the teacher picked on us to answer the complicated algebra problem at school.

This situation is frustrating for both sides. The solution is for the business and IT teams to work together. If both sides understand the intent they can find the information needed.

These 10 issues may annoy the business but none of these is the fault of IT. There is no blame here. The purpose of this list is to highlight some of the reasons we have a ‘them vs us’ culture between business and IT.

By calling out the challenges, we can take the first steps towards making things better.

Learn more with my online course

Get your message across

• Communicate effectively with people in different teams
• Discover how to create relevant messages your audience can relate to and understand
• Simplify complex ideas and communicate in a way that is jargon-free

$267.00

Please contact me for bulk purchase discounts.