I’ve been reading the interesting “How will you measure your life?” by Clayton M. Christensen, which studies some of the lessons that can be taken from the successes and failures of large corporations and puts them in a more personal context, looking at things like our careers and personal relationships – the things that, in the modern world, we consider important when we think about self-worth and how well we are doing in life.
As well as the refreshing view that we should not be willing to make short-term compromises with relationships in return for “investing” in our careers (something I considered but fortunately decided against) my attention was captured by the chapter titled “What job did you hire that milkshake for?” which kicks off talking about how Ikea has been so successful, summarising their secret:
”IKEA has taken a totally different approach. Rather than organizing themselves around the characterization of particular customers or products, IKEA is structured around a job that customers periodically need to get done”.
The notion in this context is that a job is something we want to get done that we can buy a product/service to achieve. In IKEA’s case (which the author demonstrates with a story about his son furnishing a new apartment) they oriented themselves entirely around what people want to do – furnish rooms – and carried this through the entire way they worked, marketing, store layout, warehousing etc.
I know there are meatballs as well, but I suspect that’s not a massive money-spinner for them.
Anyway, so far, so insightful. But it inevitably got me wondering about how that simple question could be transferred over to my work life. What job are my users “hire” my team to do?
At a high level you could probably summarise it as “do our IT for us, we don’t want to worry about it”, which actually sounds like an alternative of ITIL’s definition of a service:
“A ‘service’ is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks”
That all sounds good, but doesn’t feel like a terribly useful piece of information – it’s certainly not enough to give us a steer on how to operate, or really to be sure that we’re really meeting user need.
Drilling down and looking at a granular level it’s a simpler (although perhaps just as unhelpful) question to answer – help me with my data, install this expensive piece of software, buy this shiny widget.
Sometimes the “job” we’re faced with doesn’t feel right to us, particularly in higher education where every pound is precious (indeed the financial guidance we’re given now is to effectively assume all purchases need due diligence until proven business appropriate). And so we push back, seeking clarification or escalating for approval – do you really need this widget? Couldn’t you achieve the same thing with this cheaper/recycled/supported widget?
So often at this level it is obvious that even the users themselves have often lost sight of the “job” they want to do and have been entranced by pictures of the latest shiny gadget. I’m sure this is a common experience for almost every professional IT organisation, but it is particularly prevalent where the user confusing their “needs” with their “wants” is also the one holding the purse strings.
Simply challenging the user’s request in an unstructured fashion will almost certainly bring conflict. I feel that there’s a middle ground here. As an IT operation we need more than the broad directive to be effective, but we risk inadvertently letting our users down when we rely on them too much to articulate the job they want to do or worse, ignore that question completely.
It needs be the role of IT to help users understand what they’re asking for by taking them back a step and asking what job they are trying to achieve and find a solution from there. Good technicians are able to do this in such a way that the user doesn’t feel they’re being told “you want what?!” The best technicians leave the user feeling that actually they came away from the encounter with their expectations exceeded, reinforcing the lesson for the user.
The challenge is, inevitably, not a technical one, indeed the technical bit can be the fun bit for many (and the reason they’re in the trade in the first place) and could (should!) be considered a reward for successfully steering a user down the right path. This is why we look for IT professionals with good people skills, not just technical experience.
We need to be able to speak to users at their level, avoid jargon and use terms that they understand. Use the right tone. There is a bit of learning to do here – watch body language as well as what they’re saying for cues.
And, crucially, ask the right questions – ultimately we want our users to frame their request as a question, i.e. “how can I best achieve X?” In most cases it’s not enough to just say “and what are you going to use it for?” Frame questions from the user’s perspective, making the conversation about outcomes. The point is to understand the “job”. It can be easy to undo all the good work by making the same mistake as the user and talking solutions prematurely!
This all feels a bit obvious, but of course this is all just customer service 101 really, while the concepts of business cases and use cases that can come into play have been around for a while in fields like project management. But it’s interesting to see how a good approach to leaving users happy (and possibly happier than they expected) needs is the same as the reasons for the success of a company like IKEA.