Make Core Values Explicit
By Simon HarrisA developer friend of mine asked me recently what he should do when he discovers that a feature he is working on looks like it’s going to take longer than expected. Of course I recommended alerting the team lead, project manager, etc. “Well that’s fine, but then they just tell me to do it in less time and I can’t!” was his response, to which I replied “Of course you can, just take some short-cuts.” My friend retorted “but I don’t want to compromise the quality of the code!”
The problem here is that as a Developer he wants to write the best quality code he possibly can - irrespective of whether he is capable of doing so or not. His Project Director on the other hand has a deadline to meet. Unfortunately no one has made it explicit which one of these values is more important.
We all live our lives by certain values. When we do stuff, we make value judgements. We decide whether one thing is more important to us than another. Some people are aware of this others are not. Some people are acutely aware of their own values while others aren’t. For some people these values are explicit while as for others they are implicit.
Projects are no different. In fact I’d say it is critically important that the values for the project be not only explicitely enumerated but also prioritised. If this isn’t done, there exists too much opportunity for ambiguity. Ambiguity leads to conflict and conflict leads to the dark-side.
When we start any project - or restart as we have just done - one of the first things we do is to get the stakeholders in a room and prioritise the core values. Things like (honestly in no particular order):
- Time-To-Market;
- Within Budget;
- Customer Satisfaction;
- Adding Value;
- Functioning Software;
- Software Quality;
- Team Satsifaction;
- Stakeholder Satisfaction;
- …
It can be tough to do and some people may be a little shocked by what they find out. In my experience for example, Team Satisfaction is almost always at-or-near the bottom with Software Quality hovering around the middle and Time-to-Markert and Within Budget right at the top. When developers see this they initially freak out. “What!? They don’t care about us?”
No, they do care, it’s just that if there’s a choice to be made between you staying back to meet a deadlne and you going home to <insert favourite TV show and-or-computer game here>, then guess which one wins out?
Of course priorities can change and there are no hard and fast rules but if decisions are being made that would appear to contradict the agreed priorities then alarm bells should be ringing as clearly, more communication is needed to work out why.
I dare say companies ought do the same thing. When an organisation says that it considers employee satisfaction to be the highest priority, why not make it explicit? I don’t know about you but rating employee satisfaction above say having everyone billable or customer satisfaction, is highly unlikely but hey, some organisations do tout themselves in this way. I’m sure some employees would be shocked to see the order of values that their managers have in their minds.
The fact is that it doesn’t really matter what the priorities are so much as they are made explicit. Once everyone knows, then decisions can be made and, importantly, made with the full understanding of why and how the decision was reached. The alternative leaves people assuming and expecting things based on their own set of values. Allow people to make informed decisions.
So the next time you’re asked to comprise, realise that it’s probably because the decision is not being made based on your values. Instead, find out what values are being used. If it’s on a project then put the responsibility back on to the person holding the purse strings to make that choice. It’s not a choice you should be making nor one you should even be allowed to make. Then, get over it and do your job :)