Everyone’s heard that you should listen to your users, right? After all, if you don’t, you risk alienating and losing them. My particular favourite take on this is Jeff Atwood’s, of Coding Horror, Stack Overflow, and now Discourse fame (and if you don’t know who Jeff Atwood is, where have you been?). He wrote a blog post called Listen to Your Community, But Don’t Let Them Tell You What to Do. You can see this way of thinking in a lot of successful websites and applications – if Facebook didn’t follow this path, it would have died years ago after reverting every change users complained about. In a way, this also applies to software products where customers pay for developments – by all means allow this, but don’t let that affect your roadmap or you will end up without a product.

Somewhat less popular, but still going strong (and perhaps growing stronger with the appearance of shows like Undercover Boss), is the idea that you should listen to your employees. An interesting take on this can be found in an article by Matt Linderman (of 37Signals/Basecamp) called Marketing to your own team:

You’re not just sending out a message externally, you’re sending one out internally too. If your employees don’t believe it, the whole plan falls apart.

It’s not good enough to just have meetings where employees talk to you – it’s all just platitudes if you’re not engaging in a conversation. Listen to your employees, market to your employees, or they will lose interest.

Of course, this is just one of the reasons you should listen to your developers. From a technical perspective, and in the absence of empirical data (such as usability studies), developers should be your first port of call when it comes to figuring out how to develop your product – they know your product inside out, to at least some degree they are invested in it, and they have an interest in what you’re doing (at least, I find web application developers have a general interest in the web). If they didn’t they wouldn’t be there. Their knowledge and their input is valuable, whether it’s suggesting improvements to customer requests, or strategic direction, because they understand the expectations of software products.

Ignoring developers’ input risks alienating them. It can demonstrate a lack of trust, and a removal of responsibility. And employees who feel alienated, or without responsibility, will soon leave. High staff turnover will in turn lead to other problems. Knowledge loss, leading to difficulties in maintaining and developing the products, is perhaps the most obvious. In the highly interconnected development community, it can also make recruitment difficult, which will make any recovery harder to achieve. And if the turnover cycle is short enough, you will end up unable to promote internally. For example, junior roles tend to last 2 or 3 years, and mid-level roles anything from 3 to 5 years. This means senior roles are generally available only after 5 to 8 years. If you’re losing developers after just 2 or 3 years, the knowledge loss will be severe, you’ll be spending a lot of time on training which you don’t get to see a return on, and you’d better hope the code is very well documented.

Photo by Ky via flickr.