Generally speaking tech companies try to get good at investigating and reflecting on their own processes. Often this results in exciting ideas that challenge the traditional ways of running organisations. At GitHub there is pride in the lack of managers, or, as Ryan Tomayko puts it, the fact that “everyone at GitHub is a manager”; “each responsible for managing a single person: their self”. Valve has no formal corporate structure. Everyone can pick what project they work on, so the desks are furnished with wheels for setting up impromptu temporary teams. Decisions are made by getting enough supporters across the company who will want to work on the specific project. Their employee handbook describes exactly how it works and it’s a fascinating read.
But there is a philosophy that at first doesn’t seem quite as radical, though it seems like the entire software making world is practicing it: the Agile philosophy. I can quote the entire Agile manifesto in here, it’s this short:
We are uncovering better ways of developing
software by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Happenstance was supposed to help consider was whether any of the Agile philosophy of making software could be useful to arts organisations. Obviously, there are many differences between the ways in which software and art are made. The biggest difference is probably in the way they are funded – arts funding is mired in bureaucracy, paperwork and reliance on relatively few bodies, who can grant money to projects that fit within their goals and agendas.
For a while I was wondering whether the Agile approach is even useful – Lighthouse is a small team working in the same room. Most of the work they do is about strategy, planning and managing, rather than making things. But as I kept it brewing on the back of my mind I realised that the agility comes from a specific culture within the organisation and has relatively little to do with making things or technology. The idea that face-to-face conversation is the best way to convey information surely applies outside of the software-making world. Agility comes from not fearing change or small mistakes and learning to respond to them quickly and efficiently. It’s about responding to change.
Recently I felt like I’ve gained enough trust among the team the Lighthouse to be able to propose anything and that they would at least try it out, knowing that I’ve got their best interests at heart. So I decided to give it a go, and completely banned email as a means of internal communication. Now, obviously I have no way of of checking up on everyone, but judging from the feedback and the amount of work related discussions that are happening in the office they decided to follow it.
I’ve also introduced daily stand-up meetings, when we very briefly describe what we were working on yesterday and what we’re going to be doing today. Somehow the format stuck and we describe what we did on days off, too – and it’s actually really nice to be always in the loop, and occasionally hear a funny weekend story. It made me realise how much and what kinds of work everyone does, all the boring bits: catching up on emails, reviewing things, etc etc. that even Offbott doesn’t always hear about.
So after these things were practiced for a while, what good did they do? I find it hard to quantify it after a short period of time, partly because I don’t actually work on any of their projects, so I can’t tell whether things are easier, better, worse or without change yet. I will gather more feedback and then I will report on it.