do you even tech, bro?

I’ve been working in enterprise IT in one form or another for 29 years. Over that times, I’ve observed more than a few trends and common themes. The so-called “innovation” of midrange systems virtualisation (mainframe had thought of it many years prior). The constant pendulum swing of outsourcing and insourcing, matched more recently by the pendulum swing of cloud, and so on.

All of those things have been trends that you watch over decades; sure, innovation happens quickly in enterprise IT, but most patterns of behaviour form over 5-10 year windows. The affect they have on business is at times immense, and can be highly disruptive. But there’s one pattern that consistently happens on a far quicker scale (sometimes in the order of months, others in the order of weeks and sometimes even days), and I’m willing to bet is far more casually costly and disruptive to business than anyone is willing to give it credit for.

The pattern itself is simple: the mistaken belief that you can insert technology and get a better outcome when in fact it’s process that’s required.

do you even tech, bro?. Credit: Bigstock.

In that sense, I’ve been lucky to have most of my career form around enterprise data protection. Backup and recovery – and everything that revolves around it – touches almost every part of an IT environment, and by extension, is therefore impacted by (and has the potential to impact) a lot of the business that is making use of it. So because of that meshed connectedness, you observe the interplay between IT and business near constantly.

Lots of IT people seemingly spend vast stretches of their career desperately trying to avoid process, as if it’s the naughtiest of all the rude words. (As an Australian, let me assure you, it is not. It doesn’t even live on the list.) Somehow, process is distasteful. Why solve with process when you can just dive in and do it? Of course, the distate seems to creep in when processes are documented; when a process becomes a procedure. Procedures are documentation, documentation is boring, hence process gets tarred with the same brush. Over, and over – and over and over and over – again. I can intuit a lot more about the maturity of an IT organisation with just a few questions about process than can be gleaned through in-depth studies of all the technology stacks in use.

The application of technology to a problem without an appropriate backing process will either fail, or it will fail successfully. What do I mean by “fail successfully?” I mean it will work, but either as a pure fluke, or (more likely) because someone has accidentally incorporated a process into the technical solution.

If you think I’m hunting for edge cases when I say “someone has accidentally incorporated a process into the technical solution”, you’d be quite wrong. It happens all the time – in automation. People will often attack a problem with automation believing they’re solving the problem with technology. Nothing could be further from the truth. They’re not solving the problem with technology, they’re using technology to solve the problem with a process, since automation is nothing more a technical application of process. A process doesn’t need to have been written down to be a process; writing it down simply turns it into a procedure. And, sorry to burst one more bubble – an automation is a procedure, just one oriented towards machine-readable format.

Another great example of where process is needed before applying technology is User Experience (UX) design. A common mistake when looking from the outside of UX is that it’s all about “mocks”. So much so that I actually get quite nervous about referencing “mocks” when talking about UX. Not because mocked up user interfaces aren’t part of it (they are), but because someone describing UX as “mocks” has about the same accuracy as your octogenarian non-computer using relative saying that someone working in IT is paid to type.

Good UX – and who doesn’t want good UX? – doesn’t start with mocks. It starts with the careful consideration of the fundamental question, “what problem(s) are we trying to solve for the user?”, and the key follow-up question, “and what will the user’s workflow be to solve this problem?” Workflow. Workflow is process. To get the UX right – to get the mocks right, you first need to actually understand the optimum (or at least an optimal) process the user is going to follow in order to get their workflow done.

The requirement for process first, then technology, has been a constant theme for me in my career and my writing. In one of my books I went so far as to have two headings, one following the other: “It’s never about the technology”, then “It’s always about the technology”. You should always start attacking a problem in IT by looking at the non-technical aspects of the problem, and a key part of that is understanding the process that fits the business needs to solve the problem. It’s only after you’ve got those details sorted out that it’s safe (and yes, I mean safe) to move on to the technology. Why, safe? Because if you start with the technology, without considering the process with which you’re going to apply the technology, you won’t really get the solution you’re looking for. Again, you’ll either fail (at a cost), or fluke it (unlikely) or accidentally subsume a process into the technology. (And the problem with accidentally subsuming the process into the technology is the inevitable assumption that it was done incorrectly, which just leads to the next attempt – and maybe the next, until a catastrophically expensive mistake is made.)

If I have one key piece of advice to give to any starting IT worker, it’s this: embrace process. It will save you time. It will save your business money. And you’ll have to, in the end.

Disclaimer: All content is the work of the individual and is in no way affiliated with or representative of any employer, past or present.