What do you call the people you write software for?

For most of my career I have referred to the people who I write software for “users”.  It just made sense, they are using the software so they are users?

Interestingly enough at Amazon we call them customers.  Not to say that the word user has been stricken entirely from the vocabulary, but it makes me wonder if it should.  Here is my thinking.  Something different happens in my mind when I think of the people I am writing software for when I use the word customer.  It is hard to describe…but maybe this story will help you understand what I mean…

When I worked at Microsoft I worked in the consulting division and we would help people make sense of the variety of ways to write code on the Windows platform.  Often times some of my customers (aka clients) would have come up with a unique way to solve a problem using some piece of Microsoft software.  When I would relate this back to the product team (another aspect of my job).  More times than not the question I would get back would be “why would they do that – that is not what we intended”.  We used to refer to this as the RDZ – reality distortion zone; which was the invisible field that hung over Redmond that prevented the product teams from understanding how people really used Microsoft product.

When I think about how a customer centric Microsoft would have been different – then the response back to me would have been something like “that is really cool, we never thought of that – how can we make it better”.

Try it.  It may just change the way you think about things.

If you smelt…you dealt it

nofartNo this entry is NOT about flatulence.  Ironically, there is a Wikipedia page that is – here.  Instead my intent is to opine on the practice at my employer about developers supporting their own code – which means that if you broke something then you are going to be the one to fix it.

When I was managing the production support team at my previous employer; the team’s responsibility was to focus on the operation of key systems and ensure that they were available and meeting SLAs.  This team did a good job at keeping things moving – if something broke they got to be pretty adept at fixing issues.  If you look at this as an outcome with a fixed cost (which is how we structured it) then it can look pretty attractive.  But in the end the people on the team had many concerns/issues/complaints/etc about the challenges they faced in sustaining this model.  In the end – I feel that this model takes too short of a view of life cycle of a system and therefore is flawed.

amazonlogoFirst it is worth noting that Amazon has a list of core leadership principles that they live and breath.  I have done a lot of chin rubbing around these as of late and the more that I play with them the more I like them.  When considering this post there were a few in particular that I felt applied…”Ownership”, “Invent and Simplify” and “Insist on the Highest Standards”.  If you read the short descriptions for each of these they are all pointing to how separating support from development is flawed.

If developers are not responsible for keeping their own code running or seeing how it behaves in production then how they doing any of these things?  Sure it is possible that you get outcomes in this direction; but it is not likely – especially without the ownership.

A related topic to this is how we work this into our Agile methodology to ensure that we still get things done on time.