Developers are their own breed

I recall having a conversation with one of my peers when I was working at Intel many years ago. We were discussing what motivates Software Developers, and how to best manage them. I have often thought back on that conversation, and thought I might share some thoughts about that this morning.

In the end, most developers just want to work on "cool stuff". They want to know that people like their software, and that their baby isn't ugly. Some developers don't even care if the end-user likes their code - they are motivated by knowing that they have "slayed the dragon", and came up with some really cool way to connect the dots under the covers of the application - the end-user will never even know just how cool it is.

So, how do you motivate developers? Personally, I have learned two things that I believe are invaluable:

1. Learn how THEY like to be managed, and change your management style to match it. Some developers prefer to talk out each step of their solution, and get your approval of everything they do. They like to me micro-managed, although that term has a bad connotation in today's management theory. If they are more successful because they talk through their solutions with you, then you need to be happy to do so.

On the other hand, some developers simply want to take an assignment and run with it. In this case, make sure you have clearly identified the desired outcome, and leave them to it. You hired them to solve the problems, so let them do it - and judge the results based on how well it solves the problem - not on whether it was the way you would have done it or not.

Which leads us to the second lesson:

2. There is not "one best way" to solve any problem. When I was a developer, I was quite arrogant, and really thought that I knew the best way to solve any problem. If someone else didn't do it my way - well, it might work, but it won't be as good, or last as long, be as maintainable, or as user-friendly as my solution.

I remember vividly when I realized just how wrong I was. I had been assigned to work as an Architect, and had to learn and understand three different product lines with the intent of bringing them together under one architecture. As I sat down with the top technical minds behind each product line, I realized that they were all solving the same problem, and had to answer the same questions as they went along. Of course, they all answered them differently (some with java, some with C++, some with client-server, some with SAAS, etc). I remember one day thinking that no one actually came to work one day and said "how can I really screw this up?" - they all had solid reasons for making their design decisions - and they all were now working on very successful products, based on very different architectures and technologies. They had all looked at many of the same technologies and architectures, but had made different decisions along the way. In the end, they all had happy customers and great products.

Developers, especially the good ones, tend to be a bit arrogant, and believe that there is really only one way to solve a problem. This reminds me of Abraham Maslow's comment that "he who is good with a hammer tends to think everything is a nail."

Bottom line is that in order to understand developers, you need to know what motivates them and help them achieve that goal. For some it will be more money, for others it will be a technical leadership role, for others it will be public recognition, and for others it will be to just work on cool stuff and have happy customers.

Regardless of what motivates them, however, the most important thing you can do as a leader is let them do what you hired them to do. They are smart people, and you hired them for a reason - don't try to do their job as well as yours or you will both fail.