Three Guiding Principles for IT Decision Makers Part 3: NoIT

In part 1 of this series of posts I introduced readers to the first of the three principles of 3IT namely NoDev which asserts that:

If you’re not in the business of IT, don’t make IT your business

and to

Only engage in development projects that deliver applications which demonstrably, unambiguously and unequivocally generate revenue for the business or enhance customer experience

In part 2 we discussed NoOps, an existing practice for which there is good precedence. I’ve tried to distill three assertions from existing NoOps practice, these are:

Eliminate all dependencies between application teams (development teams) and infrastructure teams (Networks, Storage, Database and Middleware)

and

Deploying code into any environment is the job of the application team that owns the code; not the infrastructure team that owns the infrastructure

and finally

Eliminate all human intervention in IT

Originally I used the word “manual”, but I was won over by arguments to use the word human instead. Readers should refer to my previous posts to obtain the context in which these assertions should be applied.

In part 3 of this series I’d like to take our principles to their logical conclusion and derive a third principle with its own assertions. As readers may have guessed the third principle in 3IT is NoIT.

As a career technologist I haven’t suddenly given up my enthusiasm for technology and turned into a Luddite. Despite having witnessed some misguided uses of technology and computers.

Let’s start with the first assertion of NoIT:

Eliminate IT systems that demand the attention of humans

To put it another way, when you decide to introduce that shiny new risk tracker, architecture taxonomy repository, knowledge management system, document management system, procurement system, etc, etc, etc if the intent is to expose these systems to others to populate with data and use, then it has to be the responsibility of the team that is introducing this system to ensure the highest standards of user experience. The highest standard of user experience for any administrative function, is that the user doesn’t experience it at all.

Systems that demand end users to acquire the expertise to use them in order to fulfill a demand which is not directly related to the most productive aspects of their roles, are essentially miss-allocating resources — en masse. As more of these IT systems creep into the organisation you’ll notice the following change to the talent composition within organisation. Those individuals that can either totally avoid the demands being made by these systems or those that master the management of non-essential IT, prosper.

Your organisation acquires a wealth of process savvy employees whether or not that was the intention. Either they can raise a PO, request various services, fill out vendor management questionnaires with their eyes closed or they can convince someone else to do it for them.In the meantime your attrition rate saws to new heights, technology stagnates and innovation becomes a costly exercise hiring and firing new “innovation” teams.

There may be justifiable reasons for having such systems but if there is, then the teams that own them must be held accountable for ensuring they place a minimal burden on other employees. For example I have worked in places were as a technologist I barely noticed that I was placing a purchase order, liaising directly with data centre staff, filling out vendor on-boarding requests etc. But I’ve also worked in places where as a technologist it has felt like such operations have taken months to complete; dealing with both IT systems and people that simply didn’t “work”.

The difference between these experiences is a function of how IT is perceived and used by the organisation, i.e. were customer centricity and user experience values held highly or not? Where the experience was painless there were invariably people that would volunteer to do the administration for me, mostly from the very team that owned the system, but on some occasions just other people in my own team. Where the experience was a nightmare, the system owners would only tell me about the system and process in great detail (information that I really did not want nor need to know). They would be quick to tell me why they, and I, were forced to use the system and they would even extol the many benefits of the system. They never, ever, offered to do the administration for me. That is the tell tail sign of costly and poorly designed IT.

Let me be clear, I am an advocate of self service but only for services that improve my productivity, not functions that are required to satisfy the administration of the business. The distinction I draw between a service and a function is simple, services generate revenue, improve productivity and create value. Functions pertain to process efficiency for administrative, bureaucratic, audit, compliance and regulatory demands. Well designed functions can save time and money, but they never generate revenue.

Summarising the above we arrive at our second NoIT principle:

Use IT to expose services to customers and employees not administrative functions that should be carried out by specialists

It is easy to spot when a function is being exposed to employees in the guise of a service. When you attempt to use the “service” you end up learning a huge amount about the underlying process from all the various people that you have to liaise with in order to guide you through the system. In effect, all the IT is doing is shielding the team responsible for the function from doing their work. Instead it is offloading the work to unsuspecting employees that have ended up straying into an administrative malaise.

It is not uncommon to find these administrative teams staffed by an army of contractors that have no empathy for the employees that get caught up in their systems. Indeed the longer it takes to get the job done, the more people that are involved and the more complex the process is, the better it is for them, for obvious financial reasons.

It should be noted that such teams are an extremely attractive target for optimisation and transformation within the enterprise. Not only will you reduce costs significantly by, reforming them, but the unintended consequences are extremely positive for employees, customers and investors alike.

Moving on lets look at the third assertion of NoIT

Eliminate IT duplication across the enterprise

It’s bad enough to have to deal with a myriad of administrative IT systems that demand human attention but the problem is compounded by duplicate and competing systems owned by different divisions. Sometimes the duplication is in IT services as well, for example having two “Enterprise Standard” services buses.

I’m not going spend too many words on this subject, suffice to say, pick one service, create a migration plan to cover any barriers to adoption of that service, which should include resourcing to fill functional gaps and notifying customers of the improvements they can expect. Set a date to decommission the duplicate service and finally ensure that duplicate service is decommissioned. This is not rocket science. It simply requires leadership and the will to execute the decision. If migration fails, the first people that should be relived of their duties are the management of the duplicate service. Then rinse and repeat.

In my next post on 3IT I will argue that if you are not in the business of IT the lions share of any innovation budget should be allocated to innovating how you your organisation appropriates innovation and not innovation itself i.e. don’t misallocate resources to technical innovation. So we’ll assert that:

If you’re not in the business of IT, Innovative appropriation is the most valuable form of innovation