You know the future of your business involves data, and you want to invest in the right technologies to stay in the game … and win. But technology won’t solve the problem without this “magical” secret. The brief article below can get you started on that process.
Governance: the boring but essential part of your tech stack
You buy a technology to solve a problem, but often it only creates more confusion.
Case in point: You sign up with a service to manage the paywall on your website, but new subscribers are still being prompted to register. Why are “registered users” over here not lining up with “new subscribers” over there?
Something’s messed up, but how do you find it and fix it? And once you fix it, how do you keep it fixed once the programmer who found the bug has moved on?
New technology will not keep your tech stack clean. Technology is like a box full of neck ties. It’s gonna become a tangled mess unless you put some rules in place.
Forms, checklists, procedures and workflows
If you require your staff to follow set procedures, you run the risk of seeming like an overly bureaucratic pain in the rear. But if you don’t, the same problems will keep resurfacing.
Think how annoyed you (and your subscribers) get when the email goes out with the wrong “reply-to” address … again!
Technology isn’t going to solve that. You need to write out a clear process for how tasks are to be defined, prioritized, reviewed, completed, documented, and when or if they should be re-examined, deleted, or updated. Insist that your staff follow those procedures for each discrete task, and keep the documentation in a folder where your whole staff can see it.
Tech overlap
Individual technologies are designed to solve discreet problems. They don’t necessarily play well together.
Example: The audiences in a data marketing platform are not the same as the lists in your email system, which are not the same as the opportunities in your customer relations management system. This isn’t an evil plot by the tech companies. It’s just that these systems address different needs, with different assumptions.
A salesman will tell you they can solve all this with the 21st century equivalent to abracadabra: integration.
Here’s the ugly truth. There is no magical integration that’s going to fix that problem. The only solution is keeping everyone informed. The subject-matter expert (SME) for each of these systems has to be aware (at a high level) of what’s going on in all the other systems, especially when something is changing. And don’t rely on the SME remembering it all. The relations and inconsistencies between these sets of data need to be documented so the non-expert can understand what’s going on.
Few people like to write documentation. (I kinda do.) But two years down the road, when you don’t know why you made that little change to your store, you’ll be glad to have it written down.
Implement issue or trouble-ticket tracking
You can’t manage development by sending emails to the tech guy.
From: Sally
To: Joe
Can you look into adding umpty bump to our website?
From: Joe
To: Sally
Not sure how complicated that is. I’ll look into it.
[One week later.]
From: The Boss
To: Sally
Why isn’t umpty bump on our website?
From: Sally
To: The Boss
CC: Joe
I asked Joe to do that a week ago.
No, you didn’t. But at least there’s a trail in the email system. If this conversation took place in the hallway, it would just be finger pointing.
You’ll need a transparent, shared resource where you can schedule and track tasks. At a minimum, this system should identify the purpose of the task, who owns it at the moment, what is deliverable when, and what’s next. The whole team should review this resource regularly. It should also serve as a searchable source of documentation, and a place to schedule follow-ups, which alert the responsible party. E.g., SSL certificate installed on Nov. 1, 2020, be prepared for renewal in one year.
An auditor’s attitude
You should have reports that address each of your KPIs. But some of this data may depend on tech assumptions that might have changed.
Unintended consequences: Imagine a system where the daily update is set to overwrite a file every evening over an FTP connection. Your tech guys create a new rule requiring SFTP. The new data never shows up, but the report keeps happily running, showing the same day’s worth of data for three months.
It’s not good enough to report on things. You need a way to cross-check numbers to make sure they still make sense.
Don’t be paranoid, but build checks that verify things are still working the way you think they are. Just because you told the email manager to send the campaign doesn’t mean the emails were delivered.
The bottom line
Tech stacks are getting bigger and more complicated every year. It would be nice if you could simply add on a new system to fix things, but it doesn’t work that way. Every new system requires a new discipline. You need to create a culture where the right people are consulted and informed, projects are managed in broad daylight, and everything is documented in an open repository.
And if you or your staff hate writing documentation, I have a simple trick for you. Contact me and I’ll explain it. It makes documentation much easier.
