My friend and I were chatting the other day about the balance between keeping your developers and customers happy. Essentially we were discussing whether these were diametrically opposed things or could can both be managed easily.

Initially my thoughts were: of course they can be managed! I mean isn’t creating stuff that customers want to use going to allow a developer to be at their creative best and thus happiest?!

To that there is, seemingly, only a single truth: no (or at least, probably not.)

You see, as developers, we can be singly minded and very focussed on the task at hand. This is true whether we are working on a clean HTML5/CSS3 based GUI or a low level security framework for passing messages at high megabyte throughputs. Turns out that therein lies the problem. Whilst on the face of it the GUI task might be directly relatable to the customer it’s highly likely that the developer is focussing not on the overall picture, but on the one specific aspect that has piqued their interest - it might just be a happy coincidence that this is something that the user cares about too.

So what’s the reason for this? Well, I’ve been a developer and utter techie geek for many many moons, and for a long time the only thing that really drove me was creating and getting to play with interesting things. It’s actually very difficult to put these tendencies aside and concentrate on what the customer (however you define that) actually needs. However, through experience, what I’ve found is that you must do this. Customers can’t buy something that does something really cool using the latest technology if it doesn’t solve the problem(s) that they actually have.

Customers generally care not just about the way their tools look, but how easy they are to use, and how few bugs they have. Thoughts about whether the system is based on Rails, Django, or Node.js are usually nowhere near the top of their list - unless they have specific hosting requirements or in-house support teams specialising in one technology or another.

A developer might jump on any one of these customer aspects with a cool idea or technology in mind, but in reality once the initial prototype has been done and all of the technical challenges are out of the way its just down to the “drudgery” of making it work well, or ridding it of all the annoying little foibles that prototypes generally have. This is where most developers lose interest, but when your customer tends to bite the most - “wow I want that”. Now someone has to deliver that, or face the real possibility of losing that customers business (or at best, some reputation) when you can’t deliver what the customer has already seen.

Perspective is also a game changer here. If you work for a small-medium sized company then you are directly influenced by the needs of your customers. Margins are tight and there is less scope for doing things just because they are cool or interesting - ultimately you need to bring in the money so that your employees can put food on their tables. This means that doing things that your customers don’t want or need isn’t going to bring in any new revenue - but you still need to remunerate that developer for his efforts.

Larger organisations can (generally) afford more leeway. A single employee or small group of employees can more easily be allowed to work on some speculative technologies since there is a larger revenue pool available with which to dilute this non-customer focussed task either through regular revenue streams or through assets of some kind. However unless this is harnessed in some manner the developers will just drift from thing to thing never really finishing anything. Even here there needs to be an element of customer focus.

To sum up, whatever sized organisation you work in the customer has always got to be the focus. As talented, creative people, it’s up to us how we spend our days in work and we need to always be on the lookout for those challenges.