In the previous post I picked up on Aaron Levie’s analysis of complicated organisations and suggested the root cause was departments working to different agendas, compounded by technology which solidified current complicatedness. In this post I want to suggest how these things might be tackled.

First a disclaimer: I’m really not pretending this is easy. Change is difficult, and change on a large scale is really difficult. So these suggestions are really only small tools in any very large (business process re)engineering project…

1. Focus on business change programmes, not IT projects

Previously I wrote about different departments working to their own agendas which causes inefficiencies and complications. Some readers will recognise this as the premise behind systems thinking, which in this context is the perspective that employees’ behaviour is most significantly influenced by the system in which they operate, including their perceived purpose, targets, and so on. The solution, then, is to re-examine not just how a single department work, but how the entire system operates and focus that around the goal.

I’ll avoid the bigger management consultancy territory and instead stick to technology, because (a) this is a technology blog, and (b) I’ve just set technology up as Lucifer-incarnate, entrenching complicated systems. We technologists must bear responsibility for fixing the problem, and the solution is to examine the system as a whole.

Specifically we should stop delivering “IT projects” and start delivering business change programmes. To me the difference is this: an IT project delivers technology into an existing operation, while a business change programme actually questions and improves the way the business works, independent of departmental boundaries.

Indeed a really successful business change programme should break down boundaries, eliminate bureaucracy, and rewire the operation to focus on the real business goal. Layers of unnecessary interface-translation are removed as real, valuable communication takes place directly.

I can think of one project close to me that’s a good example of this. It involves a lot of complex technology,  and the people leading it on a day-to-day basis have a thorough understanding of that technology. But it’s not an IT project. The real change is in non-technology teams, who are having to reconsider how they work and what they regard as important — now much more recognisable as the purpose of the business.

Technologists are in an unusual position in that we operate across many departments. We need to exploit that to join people up and make things slicker.

2. Put the flexibility in the people, not the technology

That first tactic addressed the first problem, of departmental silos. This one addresses the second problem, of technology that entrenches complicatedness.

The approach here is to reduce the technology to its core purpose, removing the process-specific operations as much as possible and allowing people to do those. People are much, much more flexible than software (yes, software is soft, but people are softer), so when things need to evolve there’s no dependency on technology changes. The way a business works is constantly changing, so it should be easier for people to evolve than people+technology.

The software becomes Brian Prentice, of Gartner’s, conception of simple software: “when the next additional feature has no particular value to the majority of its intended audience”. The interesting stuff — the complexity — moves out of the software and into the people. I would hope this becomes empowering, rather than mechanical, work, and the people feel closer to the real goals of the business and continually thinking about improving it. Certainly, whenever I’ve seen complex processes taken out of technology and into more physical forms — people using index cards to manage requirements, or whiteboards to track progress on something — I also see people at liberty to be continually creative with their working practices.

Full circle

That discussion of simple technology takes us right back to Aaron’s original article. There was enough in that original piece to trigger a year’s worth of blog posts, but for me, most of all, it’s important to understand where organisational complicatedness comes from and how it might be tackled. We technologists might be guilty of creating some of the problems, but we can also lead with the solutions.