Managing by Anarchy

futurelab default header

I’ve done a fair bit of work over the past couple of years on how organisations can adapt structures and resourcing to better equip themselves for the world in which we find ourselves, and so I’m always interested to read about approaches that challenge the norm. James said I should look at the way Github works, so I found and read this piece by Ryan Tomayko, Github’s ‘Director of Engineering’ which describes a non-hierarchical, self-organising approach to resourcing and working that many would call anarchic, yet one that has some clear themes.

Thus, employees work on whatever they want, with autonomy bringing it’s own kind of efficiency (‘instead of assigning 100% management duties to individuals, the basic role of management is spread between 1) every single employee, and 2) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects’). Leadership is less about authority and more about enabling and inspiration (‘lead by example as loud as possible’), which brings another kind of efficiency (‘telling people what to do is lazy. Instead, try to convince them with argument…If you can’t convince people through argument then maybe you shouldn’t be doing it’). The currency of the workplace is trust and contribution (‘…go build the thing in your head, show me how you got there, and then sell it to me and all your peers’).

There are challenges that come from working in this way, as this post authored by a Github employee acknowledges, but as the post also notes these can be outweighed by some pretty meaningful benefits. Whilst the founders of the company set the vision, having everyone take responsibility for deciding what to work on is a way of both empowering and motivating employees. Ensuring that each person has the responsibility to sell their ideas to the rest of the company means that there is a natural efficiency (‘I quickly learned that if I can’t get anyone else interested in the project that I want to work on, then either I poorly articulated my vision, or more likely, it does not benefit the company’). If, as Dan Pink suggests, what really motivates people and drives high performance and satisfaction is autonomy, mastery and purpose then this is a structure designed to give employees just that:

‘Anarchy works wonderfully in a small group of individuals with a high level of trust. Everyone at GitHub has full access and permission to do whatever they want. Do great things and you earn respect. Abuse that freedom and you violate everyone’s trust.’

I’m not suggesting that such an anarchic way of working would suit every organisation but I often think that there are learnings to be had from engineering driven cultures where everyone feels direct responsibility for the product and the output, a large degree of autonomy is framed within broad strategic objectives or principles, and resourcing for projects incorporates more voluntary working and is focused around small, nimble, self-organising teams. Especially for companies that are working hard to increase agility and address organisational silos (and if you’re not trying to do that right now you should be). They are learnings that I’d argue should be applied beyond tech teams and into wider organisational practice.

Click here for the original post.