IT leaders: get to know your software

Because hope is not a strategy

Before immersing myself into corporate IT, I was an IT manager for a 100 people manufacturing operation. My main guideline was to just automate the hell out of everything so I would free up time to do more automation. Note that while small, this was a 24/7 operation so you had to be careful when applying any change. The main process here was figuring out who would be impacted, alerting them ahead of time, getting confirmation they understood what was going to happen, do the change and notify them they could go about their business again.

This generally worked well, especially if we choose to ignore the botched memory upgrade during office hours or the security breach involving a disgruntled ex-employee.

In hindsight, I notice two things: the drive to automate rather than document and a reasonably compact line-up: there was me, and the users.

Then, I moved into corporate IT. After spending some time there I noticed a couple of things: first off, there were many people in the IT department who were non-technical, and sometimes even proud of it. So, they were all about the ‘I’ then. But where was the ‘T’?

In terms of people, somewhere else. In another building, in another country or working for a different company. In terms of actual software and hardware, referenced to in vague terms. People were talking about project management, stakeholder management, business-IT alignment, change management and enterprise architecture. Projects had to have steering committees and project managers needed to be PRINCE2 or PMI certified. Project results had to be transferred to operations departments which would be all about ITIL and would make a big fuss about taking things into production.

When peeling off the layers however, I found, somewhat reassuringly, that the basics were the same: running software on servers in a way that it would help people do their jobs (to varying degrees of success, that is). But it seemed you just needed a whole lot more overhead to make this happen in a corporate environment.

Today, I work at the Software Improvement Group (SIG). At SIG, we look at code — a lot. I have been working with code and advising IT executives on how to go about theirs. One common theme is most of these advisory projects is the fact that we are the first ones to advise these executives through the perspective of their actual software. We aren’t typically replacing anyone like one outsourcing partner or hardware vendor would be replaced by the next. This implies that looking at software is not a common way to manage IT. This thought was actually confirmed by my memories from the pre-SIG days:

Software was virtually absent in daily life.

Need another data point? Look at IT auditing. This is mostly a paper-based exercise. Auditors look at your processes and how you go about them, but they don’t look at the actual software these processes are managing. There are typically no checks in place to see whether the actual software is any good. If you let this sink in, you realize that IT is managed by managers checking processes, hoping that the products will come out OK.

Yes, hoping. There really is no other word for it. And it really is weird, for two reasons:

1. Looking at software is incredibly easy, especially if it’s custom code. You can measure its size and quality and use that to assess cost, risks and opportunities of your entire portfolio
2. It makes sense. IT departments are typically judged by whether or not they are able to run software to the satisfaction of their users, not by the quality of the people and processes behind it. So why not look at the real thing instead of a derivative?

Of course, this is not an entirely new thought. Agile ways of working typically put the product center stage and slim the process tremendously compared to traditional ways of working. The essence of devops is to change from a process-driven change-inhibiting thou-shalt-not-pass way of working to a product centric way of working that emphasizes the ability to deliver and sustain an ever-evolving product. If you follow a company like Netflix, you’ll know that they like talking about the products they build rather than the processes they follow.

Going back to my earlier statement: managers should check their software products and use that data to improve their processes.
Think Product!

Are processes irrelevant? No, but they should be driven by the actual product they serve. ‘But what about people?’ people ask, being somewhat appalled by the tech-centric nature of this line of thinking. Well, here’s the good news: the people you need will like this, because they like tech. And they like solving problems for users using tech. You can call this an engineering culture, and again, this is not new. If you’re reading this, it’s likely you’ve been notified of the ‘Spotify Engineering Culture’ videos more than once.

So, what does this all add up to? For IT leaders, to the following to-do list:

• Know your software. Be able to articulate the size and quality of your portfolio in quantitative terms. Only then you can properly assess the impact, risks and opportunities of your organization’s digital transformation initiatives. It starts with the product.
• Move process to product. If you understand your software, you’ll know where you can assign devops teams and incentivize them to automate manual steps, moving process into product. Remember, an automated process is faster, cheaper, more reliable and more fun to boot. This applies to your entire portfolio, so not only your hipster-compliant front-end but also your more experienced back-end.
• Bridge the gap, don’t fill it. Yes, historically there has been a gap between IT and the rest of the organization, but most of what Business-IT alignment has brought is a plethora of roles that produce words and drawings, not software. I call them ‘non-touch’ people as opposed to the ‘touch’ people who actually work on your software. Redesign your organization into a bridge-gap organization by starting with the essentials, users and touch people. Then add non-touch as desired, like architects who think about stuff your users don’t, like middleware or UX designers who make your users love your software.

I know this is a tall order for most organizations, but it’s a required one. Rest assured, you don’t need to address all of it overnight, you can start small. And in a way, it’s going back to basics: making the tech work to run a business. And talking about business, let’s stop using that word in the IT sense, i.e. the part of the organization that’s not IT. After all, if you’re part of a business, but the business is somebody else, then who are you anyway?