Let me start by saying that I’m a disciple of Scott Brinker’s vision for how marketing teams should structure their relationship with technology. The rise of the marketing technologist is a thing. I’m also a big fan of Andrew Chen’s ideas. Growth hacking is a thing. But hidden behind all of the enthusiasm for experimentation, agility and customer centricity lies something that kind of scares me.
What does your typical interaction with your company’s IT department look like? Let me take a guess:
“Hi, this is {name} and my {critical piece of software/hardware} isn’t working and I need it fixed in {impossibly short amount of time} or else {seemingly terrible outcome}.”
I say this knowing that people reading this kind of blog are probably more advanced users–at least you tried restarting your system first, right?
There seems to be a fundamental truth about IT. No matter how much time they spend on implementing new systems, application development and other fun stuff, their resources still get eaten up by support. Smart IT managers will dedicate staff for day-to-day support, but the fact of the matter is, when something breaks, it’s all hands on deck.
So, if in the interest of innovation marketing is to own its technology, how do we avoid getting dragged onto the support treadmill? And, how do we do it without being the spoiled kid who made a big mess and expects someone else to clean it up? To me, ongoing, mundane, support tasks, as well as training, are the gray area in the marketing technology movement. Here are two personal examples that provide different ways of thinking about this.
Exhibit A: Implementing a landing page platform
In early 2012, I pitched my boss on the need for a better landing page management tool, and we chose ion interactive’s Liveball platform (the aforementioned Scott Brinker is CTO at ion, FYI). The setup and integration of our Liveball console couldn’t have been easier. We paid a reasonable premium to get the folks at ion to help us build our first few experiences, and their documentation gave me everything I needed to get Liveball talking to my company’s systems. Months later, we had everything running smoothly and the volume of landing page requests began to overwhelm my small team. So, I started suggesting that other people in my department learn to build their own landing experiences, with support from my team on the trickier parts. I set up an hour-long training session that went like this:
- Spend 10 minutes showing people where things are
- End the meeting. Tell the audience, “There’s a support link in the upper right corner. Click it and you’ll find tons of videos that will tell you everything you need to know. Since you’ve got the next 50 minutes blocked on your calendar, dig in.”
The lesson: by choosing a strong SaaS partner, I was able to leverage their staff and other resources, which resulted in an easy experience. My team stays out of the day-to-day support grind, for the most part. Our users read the documentation and if that fails, we get someone from ion on the phone.
Exhibit B: My custom lead processing tool
Let’s contrast my Liveball experience. Long story short, my company determined that we needed an application to handle some processing tasks on incoming sales leads prior to those leads being stored in our database and sent to the sales team. Luckily, I saw it coming in advance and had speculatively scoped out something that was pretty close to what we needed. My project got green-lit immediately and I got a nice big budget to make it happen. I hired a third party to handle development, gave the project a cute name and got to work.
Fast-forward a few months: the application is basically finished and we’re beginning to integrate our data vendors. There is no documentation yet; if I need documentation, I either wait for my outsourced developers to provide it, or I write it myself. When others in my department want to learn how to use the application, there are no handy videos for me to point them to. And, the best part: we needed to stand up a couple of new servers to support the app and for a variety of reasons, we chose to use an external data center. All of a sudden, I am worried about load balancing and other stuff that’s out of my league.
The lesson: custom development is sometimes necessary, can be tons of fun, is harder than it looks, and the product itself is just the tip of the iceberg.
The marketing technology gray area
You’re probably thinking, “Yeah, idiot, SaaS is easier than custom development. Also, the sky is blue.” That’s not the point. Most marketing technology projects will have support requirements that fall somewhere between the two examples above. You might be in charge of getting a project up and running, but what happens then? Do you have a clear idea of what kind of ongoing support and maintenance will be needed, and have you figured out who’s going to handle it? I’ll bet that the average marketing team doesn’t have the resources to handle very much support, and that IT isn’t going to be thrilled if you just throw it their way. Luckily, I had kept my IT team in the loop and they were happy to run point with my data center guys to get everything running smoothly.
Conclusion
The promise of the marketing technology movement is that marketing, ever innovative and unburdened by IT’s need for reliability, security and consistency, can become master of its own destiny. But how many initiatives can you support before you lose the agility to start new ones? Or, worse, before your team burns out and loses the desire to innovate? When you’re sizing up a technology project, you have to forecast its long-term support needs and ask yourself, “do I currently have the resources to handle that?” If the answer is anything other than, “Yes, NBD!” then you need to start thinking about how you can grow your team, or how you you can bring IT into the fold in a constructive manner. The gray area can be avoided, but you’re going to need a little foresight.
The post The Marketing Technology Gray Area appeared first on AndrewSzatan.com.