I was a manager of developers in an organisation for a few years, and during that period I learned a lot. But if I’m honest, I learned far more about being a manager from leading a large open source project for 10 years, because that taught me a lot about what makes developers tick. Of course, I’ve always been a developer myself too, but you often don’t think that clearly about your own motivations.
Open source developers are usually volunteers. They choose to spend their own time contributing to your project – maybe they do it as part of paid work or their own projects too, but even then it takes extra effort to contribute back in a meaningful way, since the quickest and hackiest option usually isn’t the one that will be accepted upstream. These guys are going out of their way to help, even though no-one is cutting them a check in return. Crazy? And not only that, they usually defer to project leaders or core team members, changing their contributions or beefing them up based on their suggestions even though they don’t have to. Curious?
‘Meritocracy’ is a word that’s bandied around a lot, but in open source it’s an accurate description; people only listen to your opinion, or accept your direction, because they want to, and trust you enough to respect your decisions. This is a two-way street; the leader essentially builds this trust not only through leading by example, but also by accepting feedback from others, even when it’s conflicting with their own current stance, with good grace and consideration.
Because there’s no strict ‘hiring’ process as such (it’s more of an ‘onion skin’ sort of approach where developers are given increasingly more power as they soak into the community and contribute more), and geographical locations are irrelevant, you often end up with quite rag-tag band of people in an open source project, each with their own strengths and opinions, arguably a more diverse bunch than you’d find inside a single company. This mixture of experiences, ages, cultures and languages can be a challenge sometimes, but it also brings things to the table that could really only occur when you throw this sort of melting pot together. I learned a vast amount about dealing with people just by being exposed to that variety over the years.
But most of all, I learned that motivating smart, creative people can be done entirely for free – you just have to have the right attitude.
A lot of managers seem to believe that carrot and stick techniques coupled with metrics and monitoring are the best way to ensure employee productivity. You can encourage people with salary and benefits, make sure they work hard by applying metrics on time and task completion, have disciplinary proceedings when those goals aren’t met, and so on. You have none of those in open source, and yet great work gets done anyway – by some metrics, projects can be equivalent of millions of dollars of investment. Why does this work?
Well, as it happens, what pushes the buttons of creative people like developers most of all is the work itself, and the experience of doing it. Sure, we all need money; we need to live somewhere, eat, buy expensive shiny gadgets and so on, but actually, the good developers would be (and indeed are) writing software regardless of whether someone paid them to do it. For most good developers, what really matters once they’re comfortable with their financial situation is:
- To work on projects they care about
- To learn new and interesting things
- To have creative control/influence over their work
- To be treated like adults and not micromanaged
- To be recognised for their work
Open source projects put a big tick in all of these boxes, and that’s why they can be so successful despite there often being no money involved. As a manager, if you concentrate on these 5 things, you’ll increase your chances of attracting good developers – the salary and benefits have to be reasonable too of course, but those 5 will tip the balance.
Of course, rather than ramble on like this I could have just pointed to Maslow’s Hierarchy of Needs; all managers are familiar with that and use it to guide their management style, right? Right?
Home