It’s time for a revolution in how businesses work with those who build their IT systems.

WHAT PROGRAMMERS should you employ? How many computer network administrators should you hire? How big an IT department do you need? Not everyone needs to ask these sort of questions. Indeed, the history of the last decade has seen a determined attempt by most businesses to avoid asking these questions ever again. We defer and outsource the problem.

We run our corporate e-mail on Google mail. We buy a bunch of desktop machines with Windows on it and leave it at that. Maybe at some point, we’ll pay someone to plug in a computer that ends up being known as the “N: Drive” and which nobody quite understands, but appears to hold on to Excel spreadsheets long enough for us to use, so who cares?

It is not as if we individually ask how many coal miners we need to fuel our corporate powerstations.

I still think, though, that we need a revolution in how businesses work with the people who build their information systems. And that may involve less palming off of the problem to giants like Google and more coming to realise that we need a more intimate connection to how our information technology works. What does that intimacy look like? There was a time when I looked at the example of the financial sector enviously, where brokers often have a personal relationship with coders, the better to automate and accelerate how they do business.

However, few people these days really take anything the financial sector has done in the last decade as an indicator of anything, except perhaps what not to do. I rather suspect that, like bankers, you have to have largely fictional amounts of other people’s money to spend before you can afford to have a one-to-one ratio of coder to other employee at your work.

I haven’t quite given up, though, on the hunch that we can still whittle better business efficiency by understanding the extent – and the limits – of computer automation.

I have spent too many years in offices watching people act as though they were slaves to the computer, instead of being able to bend it to their will; watching people using computers as though they were rickshaws to be dragged by hand behind you, instead of robots that can lift and carry you over obstacles.

The real solution, though, is how we employ IT professionals.

These days, we hand our data to Microsoft, Google, Salesforce, or even just your local ISP or web hosting company and struggle alone with how they manage our information. These internet- scaled companies provide valuable tools for millions by eliminating almost any kind of direct customer support.

That’s a brilliant innovation in its own right but it hides the fact that most of us will end up dependent on intermediaries: smart professionals who know how to navigate these mass-produced services and customise them for us.

By pretending we don’t need permanent IT staff, we are slowly surrounded by consultants wielding Sharepoint and Drupal and other magical items and we pay them a great deal to do something we don’t quite understand. We don’t need to understand it, but we do need to have a better relationship with those intermediaries.

It is 10 years since the Agile Manifesto, a famous declaration signed by 17 famous developers, hit the world of programming.

The manifesto initiated a revolution in how coders organised themselves and how they wrote software, discarding two decades of thought about rigid process and replacing it with an emphasis on speed, responsiveness and personal responsibility.

It is a little-known document outside the IT world, but I recommend anyone who uses a computer in their job read it at agilemanifesto.org. Looking back at it now, what hits me is that it is far less about coding and far more about the relationship coders should have with their customers.

It reads less like a declaration of independence and more like a series of apologies for how badly IT staff have catered for the people for whom they are supposed to be working and a promise that coders can do better.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software,” they wrote.

How would they do that? By welcoming change “even late in development” and “delivering working software frequently” as often as every “couple of weeks”.

In order to get that kind of responsiveness, the manifesto says, “business people and developers must work together daily throughout the project”.

A decade on, how many of us have that kind of direct relationship with a person who understands our business’s computing systems? I think many of us would reply to that question with a couple of our own. How many of us have the money? How many of us have the time? We have a business to run, after all.

Revolutions take time to run their course. Many of the most successful computer companies have taken the Agile Manifesto and applied it to their work. Many others have tried to and failed.

There is still plenty that coders need to learn about how to produce software as quickly and flawlessly as the Agile movement promises they can.

The rest of us, though, might well benefit from taking them up on the challenge; by asking and requiring that we have working, customised software that fits our needs in a matter of weeks and understanding what we need to do to make that happen.