The rolling eyes. The furrowed brows. The gnashing of teeth. “They just don’t understand”, they cry. “They just don’t understand!”
Any disintegration of the relationship has probably been years in the making, slowly eroding one meeting, one email at a time. Like any relationship, the one between IT and marketing needs to be built on trust and understanding. If it sounds like I’m setting myself up as a geeky couples counsellor, then yes. Yes, I am. In fact, I have five steps for a marketing team to take to bring back that loving feeling. So, put on some whale song, dim the lights and acknowledge that this journey is more important than the destination, etc., etc.
1. Share the big picture
Your IT team is not a machine. It’s made up of people who are looking to find meaning in their work. Just like you. So, share the overarching goals of your digital strategy. Explain why it’s vital to your business, and how it all fits together. A common theme between IT and Marketing is that IT doesn’t know why things are being done, so up throws a wall. So, start with the big picture. Which then leads to…
2. Explain the little things
One complaint I’ve heard from IT teams is that Marketing just lobs demands for changes over the wall, wrapped in the proverbial brick, with no explanation. The brief usually comes down to:
- We need this
- We need it yesterday
Which is never the most inspiring brief. It's the kind of brief that wouldn’t be accepted by an agency, so it’s no surprise that the IT team aren’t full of the joys of spring about it, either. An internal team needs the same amount of time and respect as an external team, arguably more so. The better the brief - including giving business reasons as to why the change is needed - the more respected your IT team will feel, and the better the final output.
3. Accept that there are no ‘small changes’
“All I wanted was to add bullets to the copy. That’s all. A tiny change.”
Your content management system is essentially software, like Word or Excel. Software is a tricky thing. So tricky, in fact, that it’s not often that what seems a small change actually is a small change. There are a lot of variables to consider. How will it render on mobile? Can the entry box in the Content Management System deal with bullets? Is there a style to deal with bullets in a good way? How will that work on the multi-lingual sites? You get the idea. Your best bet here is about re-framing the request to avoid getting backs up. Rather than saying “I want to add this...”, change that to “What’s involved in adding…?”. That’s the right question to understand the complexity that may lie behind your request.
4. Don’t put up with any jargon
All my career I’ve been surrounded by jargon. And it has its place - it helps people on the same team get things done quicker. When I was a lighting designer, it was easier (and more precise) to ask for two pieces of 213 for a Parcan than for a piece of a pale green plastic 255mm by 255mm for a theatre light.
But while it has its place, it jargon can also be used to exclude people, set nonsense boundaries and make people feel stupid. It can be used to undermine colleagues. And that’s unacceptable. I know, before I knew better, I used to do it a lot. I did it to mask my insecurities and pathetically build up my own self-worth.
When you mix IT, which is just dripping with jargon, a feeling of disrespect (regardless if this is true or not) and possibly having to deal with people who have a skill that they may not understand (=hipster marketing people) then you have a situation where shields are raised. And nothing is more impenetrable than the IT department chucking around API’s about CSS for AWS involving some guy called Jason. It makes you want to scream, “GTF!”.
If that happens, stop. Ask them to explain what they are talking about. It’s all pretty straightforward. API’s are software bridges between one system and another, for example. But, shine a light on the jargon, and you’ll learn what’s involved. You’ll then be able to be part of the conversation. That’s a good thing.
5. Remember Roles and Responsibilities
When you take a brochure to a printer, they tend not to question the content or the style. They may have some suggestions from a technical point of view, but they tend to know that their job is to print, on time and on. Budget.
This acceptance of roles sometimes doesn’t extend to the IT team. Traditionally, if it was on a computer, it was the domain of IT. Which is why you end up seeing IT teams involved in design decisions or content planning or whether to be on Facebook or not. I would argue that isn’t IT’s role. That’s a marketing function.
That’s not to say that IT doesn’t have plenty areas of input. Content Management Systems, where to host the website, look to understand the best infrastructure for the website, does it need a Content Delivery Network, what’s the best approach for caching? The list goes on. This isn’t to say that you shouldn’t be sharing your expertise across the teams - of course you should - but you need to be aware of who is responsible for what and why to make sure that you’re all working together at the best level you can.
Like any list, I’ve made some sweeping generalisations to get the point across. IT are not the bad guys; I even wrote an article that highlights how IT can love their marketing team. However, when we go in and talk to companies and start opening the lines of communication and understanding, it is impressive and heartening how quickly turnarounds for requests happen, better quality work is achieved, and teams start to look forward to meetings and to celebrate the work together. If you want to talk more about the best way to approach your IT team, drop me a line. I'd be happy to chat.