Developer Powered Innovation

There is a very common fallacy about developers in our industry, and I think it hurts countless companies.

Have you ever heard the old accusation that developers only want to solve problems for themselves?  They’ll spend countless hours, often on their own time, to create amazing tools for themselves and the developers they work with.  But just try to get them excited about building something for “the business” or “the customer” and good luck.

I’ve been accused of this myself.  For the first 20 years of my career I was either building tools for other developers, or leading products designed for other developers.  It wasn’t actually until eBay that I was responsible for creating products for people other than developers.

I have been increasingly vocal lately about the critical role that developers must play in consistent innovation.  I’ve been raising the volume on this because despite what I consider overwhelming evidence to the contrary, I continue to find teams where the CEO, the product managers, and the designers think they can figure out the product themselves, and they don’t want to “bother” the engineers with anything that distracts from their coding time.

I’ve written about this several times before but while my writing talks about the critical need to include developers, it has not addressed this belief that developers only want to solve problems for other developers.

Don’t get me wrong, it’s easy to see where this misconception comes from.  Developers get hugely excited about building things for other developers, and progress on the engineering tooling front has been near constant because of that (consider DevOps as just the latest example).  So it’s easy to see why people think this is all that can excite developers.

While it’s easy to understand where this opinion comes from, I argue it is dead wrong.

Here’s the key:

It’s not that developers only want to build products for themselves.  The vast majority of developers are passionate about solving real problems for real people.  The problem is that in the vast majority of companies, the only people that the developers are actually exposed to directly on a regular basis are other developers.  They see the problems their colleagues are dealing with, and they want to help.

However, how often do you see the developers brought along to the actual customers?

I have long said that “the magic happens” when you connect the developers with the actual users and customers, and let them witness – first hand – the good, the bad and the ugly.

When a company keeps their developers sheltered from their customers, they are hurting themselves and their customers.

One of the worst things you can do is try to shelter the developers from the ugly truth.  Give them the chance to see the issues themselves, and I am betting you will see a level of motivation and passion around solving the problems that you may not have realized possible.

Note that we don’t need every developer to engage with customers, but we do need some.  It’s usually the more senior developers.

One last warning about this.  While it’s essential to get developers out there interacting directly with your users and customers, you do need to make sure that they know the proper etiquette (for lack of a better word), especially if you have a direct sales organization.  It’s not unusual to have some form of “charm school” for the developers.