While I was reading Delivering Happiness on my vacation, I got to thinking about how it applies to me. Tony Hsieh claims that a key factor in Zappo’s success was making sure his employees, customers and suppliers were happy. So what are the best ways to keep developers, management and customers happy in a software setting?

For open source projects, there is often no management. Developers are giving away their work so you would assume that if they weren’t happy they could just move on to a different project. Users of OSS are usually happy to get something for nothing but at times I’ve seen them get picky and demanding. The situation for companies is quite a bit different. Quite often management is telling a developer what to do. Marketing or sales has promised the world and customers are unhappy at what is delivered. Senior management is breathing down the neck of middle management to get the project done faster, cheaper and better. So why are so many talented people willing to give their time — which is worth a fortune — to open source and at the same time companies struggle to keep their developers happy and engaged? Why also are a lot of users (especially power users) satisfied with open source but not satisfied with commercial software? How can management simultaneously keep developers happy and also ship products on time and on budget?

Understanding and recognition

In a commercial setting, there’s often a barrier between who worked on the code and who the users (customers) are. Developers like to be recognized for their hard work like they are in open source. It gives them a sense of pride. It certainly does for me. Now I’m not suggesting that companies should tear down the wall between developers and customers completely and always have an easy direct line of interaction between them. However, there should probably be a door on that wall. Developers may be surprised at how their creations are being used and they can come to a better agreement about new features or a change of direction. Users also may better understand why a feature was done a certain way instead of simply thinking that the software was done poorly. Open source usually has a direct line but once a project is big enough there is also a users group to field the easier questions and concerns. This satisfies developers’ desire for recognition while also allowing for good communication with customers

Ownership – the key to happiness

The idea of having developers interfacing with and understanding the wants of customers suggests that the developers, not strictly management should be at least partially in charge of what features get developed. If management can’t convince developers that their work is important, the project is doomed to failure. Nothing can lower the morale of a team of developers faster than knowing that they are working on something that they view as valueless. People want to feel that their work is useful. Problems of code ownership are for the most part unique to commercial software since there’s always a sense of ownership with open source.

On the other side of the same coin, why have Fedex days at Atlassian and 20% time at Google been so successful at motivating developers even when management is removed from control? The answer, I think, is three-fold. Firstly, I think concept of pride and recognition play into it. Secondly, developers like to have that control and not always have management dictate to them. The other reason is that when a developer works on a codebase more than a certain amount, they become uniquely qualified to make certain improvements: refactors that only they can make or features that only they could think of. In a word, they become the master of their domain and they just need the time to show it.

There’s an entire TED talk on the topics of autonomy, mastery and purpose that is worth watching. While the conclusion is that those are better motivators, I think they also lead to more happiness.

So what about management?

So if management isn’t really as important in telling developers what to do, do we still need them? While open source projects get by just fine without them, I think managers are necessary for commercial projects. However, instead of telling people what to do, I think managers (and developers) would be happier if they functioned more like idea-men. They plant the seeds of ideas into the minds of developers and see what takes root. While emersed in a project, occasionally it is difficult to sit back and take in the big picture. However, somebody needs to keep it in sight while also having an eye for improvements.

What to do about it?

One other message from Hsieh’s book is that it is never too late for a change. If your management is draconion and completely removes you (the developer) from the process, it might be time to explore other options. Likewise, if you’re a manager and you basically function as a middleman and your superiors yell at you to go yell at your subordinates, there are better opportunities out there. You might also take these things into account as a consumer of software as well. You might just end up a little happier.

Update (March 15, 2011): There’s a good article at NYT about Google’s approach to management.

Here’s a picture of some of my friends on a trike taxi in the Philippines.