I’ll come out and say it straight off the bat: I don’t like hierarchy in general.

I don’t feel like it’s particularly productive. I think it creates significant incentive for people to leave roles they’re good at for roles they’re not good at. I think it damages specialisation and craftsmanship. I think it creates unnecessary divides within an organisation. I think it removes accountability for decisions and promotes inaction.

The world of software development is doing great work in challenging how we think about hierarchy.

“Why is my manager above me? Why am I above those I manage?” — These are the kinds of questions most organisations implicitly cause their employees to ask.

Think instead about the set up of a team in a Scrum system.

You have a team of specialists. You have one specialist who isn’t focusing on the work, they’re focusing on removing obstacles faced by their colleagues. Then you have another specialist who determines what is required in regards to output and has measures to determine whether or not those criteria were met.

The scum team, the scrum master, and the product owner.

The product owner is not the boss of the scrum master, nor vice versa.

Nor, in a good system should the product owner or scrum master be considered the boss of the other members of the team.

You have specialists focusing on the task at hand, a generalist looking ahead to facilitate their work, and an organiser who links the actions of that team to a set of broader aims.

It is possible to run that team without having to practically call on hierarchy on a day to day level, at least.

Now, I’m not telling you to reorganise your entire company. But I feel the fastest and most effective way to implement agile ISO in your organisation is to take a leaf out of the above.

Treat the different members of your organisation as specialists and grant them not only the respect that comes with that, but the responsibility which comes hand in hand with that respect.

Get your teams to document their own process. It can be super simple at first. Any task they do more than twice should be recorded. It could be bulletpoints on the back of a fag-packet, just so long as they get the basic steps down.

The goal would be to then note these processes in Process Street (or another software or collaborative tool, I guess) and each time that employee starts that process in real life, they run the checklist for that process in the platform.

They follow the process and improve it if needed.

By doing this, simultaneously across the organisation, you can suddenly end up with documented processes by the bucketfull.

Of course, this won’t just happen in real life.

You’ll need to disperse materials explaining the importance of processes, talk about how we’re moving over to a process based system, and how that gives more control to each worker over their day to day job — gaining also the credits for the improvement of processes over which they hold singular or collective responsibility.

Your typical change management stuff, just specific to this particular scenario.

Practically, of course, it would help to build a folder structure inside Process Street with managed permissions so that you don’t create a chaotic mess of muddled documentation. I wrote about my recommended approach to that for large companies in my article here on process libraries — a combination of a live/staging folder hierarchy along with a Dewey Decimal tagging system.

After the point where your teams are operating with documented processes in place, you can start to make improvements.

Realistically, people may have documented the process but chosen not to bother following the process. That’s not a problem and you can fix that at the improvement stage.

If you create a mini-team of process specialists — it could be 1 person — then that process team can go along and meet with each team in the company and work with them to improve their (ownership is important) documented processes. In doing so, you improve output, reduce risk, and provide hands-on process improvement training to everyone.

Trust your teams and build out processes in an agile way starting from MVProcesses before building up toward your fancy automated options.

What could Agile ISO do to a company’s organisational structure?