More than 18 years ago I moved from IT to Marketing, and since then a great part of my work has meant interacting with Information Technology managers and teams. My IT counterparts have since then had to cope with me having “too much” understanding on IT issues. This has been for them a mixed blessing and much has depended on their willingness to work together for a common goal or on the contrary defending spending and quality of work.
When we were able to join forces results came and we really enjoyed the ride. At one point we were so well integrated that our work brought DevOps to a new level: MarketDevOps. A single, cross-functional team with a single objective, incredible time-to-market and unbelievable cost-efficiency. One day IT was reorganized and everything we so lovingly built broke apart.
In the last couple of years, I joined a new venture and had to start from scratch once again. In the beginning my help on the IT side was more than appreciated and just a plain necessity. There was little time, very few resources, so working together was mandatory a for quite a while I was a marketer with a pair of IT gloves. As the company grew and organized itself things kind of fell back in place and this form of extreme collaboration was no longer a necessity.
Marketing started to focus on its key activities and started driving IT developments in a more structured way. This is actually good. Together with this approach came the decision to externalize IT Program and Project Management and software developments. This has demonstrated to be very bad.
How do you handle a situation like this?
Approach #1 – Blitzkrieg, quickly engage war
As soon IT delivers the outsourced code, you spend the night analyzing what they have produced and the morning after you deliver an analysis of how crappy is the work consulting delivered and slam it in the IT managers face.
Even if it’s all true you will activate IT defenses in max alert, ruin your health, and also find yourself in having to explain technical perks to your top management. In the end you will at most earn yourself a gastritis with no progress at all.
Approach #2 – Sit on the side of the river and wait for the bodies of your IT to float by
Knowing that your IT has delivered crappy code you wait for the day when it will be clear to all (including your customers!!) of how bad your service is.
I have seen have seen this too often. Marketing knows but waits until the problem emerges knowing “it will be an IT responsibility”, in the end we all lose.
Approach #3 – Leverage Marketing Analytics
Even when you know exactly what is wrong in the developments released by IT, you approach the problem in terms of Marketing KPIs. This approach requires that you monitor a good deal of performance indicators and requires a significant effort. It empowers Marketing to approach IT on terms which are clear to top management and the entire company.
You must enrich the classic array of Marketing Performance Indicators with more technical ones like these that pertain to web e-commerce:
- Page size in bytes
- Number of CSS files and respective sizes
- Performance indicators:
- Google PageSpeed Insights (https://developers.google.com/speed/pagespeed/insights/)
- Pingdom Website Speed Test (https://tools.pingdom.com/)
The trick is to setup a small system that keeps historical track of these and other KPIs so you can approach IT with concrete Marketing Issues like:
“your last release has increased product page size by 20%, the page now takes 2 more seconds to load and this has reduced conversions by 20%.
We are losing XXXX€/day.”
You can expect everyone to be quite reactive with this approach and you will quickly obtain backing by top management.
I still miss the days when Marketing and IT could work together sharing responsibilities, goals and results but sometimes it’s not possible.
We live in an imperfect world with imperfect companies the key is finding ways to deliver progress nonetheless.