gothandy

You’ll more likely know the phrase “The Customer is always right” which was first used by Marshal Field or Harry Gorden Selfridge at the turn of the 20th century. At that time the mindset of most businesses was caveat emptor (let the buyer beware), in that context the principle helps shift the balance of power back in favour of the customer.

Herb Kelleher, the charismatic former CEO of Southwest airlines, the forerunner of low-cost airlines like easyJet and Ryanair, challenged the status quo. Herb made it clear that his employees came first. As he says “The customer is sometimes wrong. We don’t carry those sorts of customers. We write to them and say, ‘Fly somebody else. Don’t abuse our people.'”

So it is clear there are times when a customer is wrong. When they are being angry, abusive, rude, dishonest or plain obnoxious. In these circumstances the business must side wholeheartedly with the loyal employees.

So enough of the business history lessons. The context I’m keen to explore is that of my business. Delivering valuable bespoke software solutions to customers in a wide range of industries. How does the maxim “the Customer is never wrong” apply here?

Things start to get complex pretty quickly. First while the happiness of customers at any given point in time is important, it is the long-term success that really counts. We see time and time again a simple mentality of order-taking, where we ask “what do you want us to do next?”. This quickly leads to budget overruns, overly complex solutions and general long-term dissatisfaction.

So it is important, that we challenge our customers. It is important that we think about and question the value of the work we are being asked to do. We are often told by our customers that they don’t need “yes men”. But how do we know when and what to challenge? This is the art of good customer service. Challenge the wrong things day-to-day and we lose. Fail to challenge things in the short-term and risk losing in the long-term.

First I believe it is important to understand why a customer is asking our company to help them. In our case this is because of our deep technical expertise in software such as Sitecore and our experience gained from building enterprise systems for companies like easyJet, Sophos and Dyson.

We are rarely invited into an organisation to tell them how to run their company. We don’t understand the mind-set of fashion loving twenty-somethings like the marketing team at ASOS. We can’t hope to give any insight to WaterAid on how to better improve global access to safe water. So in these areas we need to trust our customers to understand their own business, listen and do our best to understand.

So to be an effective partner we do need to understand our customers as best we can. If we are to be able to challenge a customer, then we must first align our understanding of the desired outcome with theirs. Only once we have this shared vision can we make sensible suggestions. However these suggestions must always be made from the perspective of the customer, always based on their best interests, always with a balanced view of short and long-term goals.

We also need to be aware of our own limitations. Technical people tend to see the world from a rational, black and white perspective. However our customers are often creative and marketing people, who will not be able to write down a simple list of acceptance criteria, they will need to see our software in context, it will matter more how it feels than how it works.

So rather than “the customer is always right” I believe in the complex world of software development we look at some key principles of customer service.

1. Approach each other as equals. Demand professional behaviour from both sides.
2. Take time to listen, and understand the perspective of your customer. Be aware that what they believe is important might be hard for us to see.
3. Be humble in areas where they have more knowledge and expertise i.e. in their business domain.
4. Challenge the customer when you don’t believe what you’re being asked to do is in their long-term interests, but do so from their perspective.

In essence “always do the right thing for the customer”.

It seems to be stating the bleeding obvious to say that trust is important, but it is. When you trust someone you’re asking them to take care of something of value to you. Trust gets created when that person demonstrates care of the thing you have trusted them with. Trust gets destroyed quickly when that person demonstrates carelessness, neglect or a disregard for the thing you have trusted them with.

As the owner of a company I’m always asking people to take care of things for me.

• I ask them to take care of the companies best interests.
• I ask them to take care of the needs of our customers.
• I ask them to take care of the people who work for the company.
• I ask them to take care of the technology we build.

And in return they expect me to take care of them, their physical and emotional wellbeing, their salary, their careers and helping find them the kind of work they enjoy doing.

But trust is not about words, it is about deeds. People can sit in a room and talk for days at length about how they are going to do this, and do that, and take this thing that you care deeply about and nod and smile, and say “yes don’t worry you can trust me”. That’s all just a truck load of bullshit. Trust is built when people demonstrate clearly that they care for the things you care about.

I’m lucky to work with people who care a lot.

I have had the book “Zen and the Art of Motorcycle Maintenance” on my reading list for over 20 years. So it’s been interesting finally picking it up and reading it. Some regrets about not having read it earlier, but equally enjoying the experience of reading it now. I doubt it would be having the impact it is now if I’d read it when I was in my twenties.

I’ve not finished it yet, but just got to the bit where he talks about how Quality turns the usual dualism of Subject vs. Object, into a triad, with Quality being the third element.

I’ve found this insight fits very well with the similar questions I’ve had about Value. For starters I’ve been fighting the urge to define it. Of course I’ve tried, but never found the results either pleasing or able to stand even the shortest test of time. So when I read Phaedrus taking the approach of rejecting the need to define Quality I was intrigued.

So in this rather unfocused post I wanted to explore how Pirsig’s ideas of quality map to my specific context of how to look at the work we do. First as mentioned above, when you make Value an undefined term it frees you up to talk about it in relative terms. As Phaedrus did with his class, we can now ask people to make a judgement call on how much Value they see in a given piece of work for a given customer.

The whole Value concept was beautiful. It worked. It was that mysterious, individual, internal goal of each creative person, on the blackboard at last.

It’s not that long ago that we talked about something we called a Moment. These Moments allowed us to talk about how our customers felt when we delivered the work. As this quote shows however Moments only cover one side of the problem. 

Was Value something that you ‘just see’ or might it be something more subtle than that, so that you wouldn’t see it at all immediately, but only after a long period of time?

We still flip-flop between Moments, the bit you ‘just see’, and something else we call Flow which talks to the value which only becomes visible after a long period of time. Once you have these two concepts it is tempting to leave Value sitting somewhere between the two. However this leaves us with a Dilemma. Two conflicting ideas. You can take the viewpoint of the Customer and look at just their subjective thoughts and feelings about the Work as it is delivered, or you can look at the Work itself and the long term impact it has on the world of the Customer.

However there is a third way. To take Value outside of the Customer and the Work. To make it stand alone. In echo’s of Drucker’s quote about the purpose of Business we now have Value itself creating both the Customer and the Work.

This means Value is not just the result of a collision between the Customer and the Work. The very existence of the Customer and the Work themselves is deduced from the Value event. The Value event is the cause of the Customer and the Work, which are then mistakenly presumed to be the cause of the Value!

So rather than the general focus on how we can demonstrate the value of the work we have done for our customers. The new mindset is begin with the Value. Let the Value drive the process. Here again we have echos of a Lean Manufacturing mindset, but for me this approach would go much further.

‘The sun of Value,’ he wrote, ‘does not revolve around the Customer and the Work. It does not just passively illuminate them. It is not subordinate to them in any way. It has created them. They are subordinate to it!’

Put simply the hypothesis is that you should build your business around the Value. If you figure this out (in all it’s undefinable glory) then the Customers and the Work will create themselves. A bold statement. Not one I can stand by, but a mindset shift that I think is worth exploring.

I’d better go and finish the book now!

“I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.”

Frank Herbert, Dune – Bene Gesserit Litany Against Fear

When working on any project that requires estimating how much work is required, then making a commitment to hit some deadline then fear comes into play. However for teams to work effectively, and by effectively I imply they both to the thing right, and do the right things, they must not fear. Fear as my opening quote so dramatically puts it is a mind-killer. Fear will turn a perfectly intelligent set of individuals into a pretty dumb team.

It is my opinion that fear of commitment, fear of missing deadlines, fear of making a bad estimate is the real problem here. Without fear, estimates can be made, deadlines given and commitments made and the perceived negative effectives (symptoms in my mind) will be like water of a ducks back.

The key to giving estimates, deadlines and commitment is simple. They are given based on the knowledge the team have at that time. That knowledge changes and when it does the estimates, deadlines and commitment needs to change with it. This is where fear comes in. First people put off communicating out this new information. This makes the disconnect between what has been said previously regarding any given estimate, deadline or commitment and reality bigger.

As this gap widens so does the fear of communicating the gap. As the fear grows the teams ability to work effectively reduces. That is “doing the thing right” i.e. not making mistakes and “doing the right thing” i.e. working only on the stuff that is needed to hit the deadline.

So for example, if scope or your definition of done change, so you’re knowledge of what you’ve committed to changes, so make sure this is communicated early.

Also if you find that things are taking longer than estimated then use this knowledge to reset expectations about deadlines immediately. We all know estimates are as useful as a crystal ball at times, but you should not ignore the knowledge you’ve gained by doing the real work.

So repeat the “Litany against Fear” and communicate changes early as you’re knowledge of the situation changes.

Anyone who works with me will know that I believe the solving problems quickly with the most immediately obvious solution (or perceived best practice) will more often than not lead to long-term damage being done.

I’m talking here about managers, consultants, coaches, leaders etc. generally people without any skin in the game, but I’ll come back to that later.

The reason behind this fear are well documented. Peter Senge called it the Shifting the Burden archetype. Dave Snowden talks about complacency leading to catastrophic failure (the boundary between simple and chaotic).

However the point of this blog post is to explore where the burden of proof must lie with respect to the work done by managers. Assuming of course that the work managers do (and the others listed above) is largely based on intervening on a group of people in an effort to make things better without doing harm.

So the choice for me becomes simple. Does the burden of evidence lie on people to prove that the work the manager is doing has done them harm before the manager will stop doing it or is it that managers should assume all work will do harm (in the long term), and they must work to prove something is safe before doing it.

It is the kind of argument Nassim Nicholas Taleb uses about global climate change (in the book Antifragile). Should we wait for scientists to prove climate change or rather assume it is true until someone can show the effect of our CO2 emissions is harmless in the long term.

Back to our discussion about managers. What this means is we don’t have to wait to prove something is or isn’t causing harm. If there is a risk it will do harm, then we need to reduce the impact of that risk now.

In a recent management team retrospective we talked about some feedback from a team. That team felt that we often didn’t follow up on promises of things we would do for them. From our perspective this was due to changing priorities. So it was clear we were failing to properly set expectations and communicate well with that team. This was leading to a long-term problem with the trust they had in us to help them.

Following this insight we started to look at what other stuff we were doing might be causing the teams confusion. The discussion moved to a newly created Trello board that contained a list of items that we may or may not do to help one of the teams. Now there was no direct evidence that by listing these items on a board that we were setting expectations that these things will be done. However equally there was no evidence that this wasn’t the case. So what should we do?

The answer I propose is rather than debate whether something is the case or not. We accept that as a team we don’t know and instead manage the risk. In this case we look at the worst case i.e. the team has an expectation that everything on the list will be done by us at some point and act to remove that doubt with a simple conversation with the team.

So let me try and summarise my thoughts.

1. As a manager, coach, consultant, leader, scrum master etc. the burden of proof lies with us to show how the work we do causes no harm in the long-term.
2. We can avoid debates about whether something does or does not cause harm. We accept we don’t know and instead work to reduce the impact of the worst case outcome.
3. Without skin in the game i.e. unless you share the risk with the group of people you are working with, then you should reduce the impact of the worst case to zero i.e. make it “safe to fail”.
4. The gold standard for all managers, is that you own the worst case outcome, i.e. the intervention you make only has a positive outcome for the people involved and that you take all the worst case risk yourself.

The last two points are a bit of a jump. So let me explore with a quick example.

If you have a team working on a project with a deadline for completion. For example a non-moveable deadline related to a specific seasonal sale. Then as a manager, your aim is to give the team the best possible environment to achieve this goal, while reducing the impact of failure. That’s not to say you can reduce the chances of failure, just the impact that failure would have. Giving the team the message “do your best with the limited resources available” is a good thing. Making sure the team can have a minimum viable product in place well in advance of the deadline helps reduce the scale of the risk i.e. we can still meet the deadline we just don’t launch with one feature. Taking the pressure off the team, giving bad news yourself etc. etc.

For me you can derive a lot of agile from this basic principles of what it means to be a good manager. The irony of which isn’t lost on me given the generally negative perception of managers by the agile community.

Let’s start by setting the scene. If you’re writing software and the work you are doing is so repetitive that you can estimate effort with some degree of accuracy then “Why Don’t You Just Code Yourself Out of a Job and Go and Do Something Less Boring Instead?”

For the rest of us, estimating how long it will take to solve any given problem in code is non-trivial (to say the least).

So if you’re only estimating your work with a single time based measure, whether it be hours, days, t-shirt sizes, points or animals (usually dog breeds) then listen to the #noestimates folk and stop.

If you’re estimating complexity rather than time. If you’ve got advanced techniques that use derivatives of velocity or cycle-time. If you’re doing anything that ultimately boils down to a measure of time. Then in my opinion you’re just chasing the metaphorical bar of soap around the bath tub. Listen to the #noestimates folk and stop.

Good. Now everyone just breath. Don’t worry this is not the end of the story. If you’ve got this far and have, conceptually at least, stopped “estimating with time” I’ll explain why I think it’s a bad idea and if you are going to do estimates then why using time is only a tiny part of the big picture.

How often have you developed something that someone wanted, to only find that once they have it, what they wanted changed? We generally don’t have well defined problems. So trying to estimate how long the solution will take is unlikely to go well for you. The crux of the problem is we don’t have a crux of the problem.

Now the good news. You know all that time you used to spend estimating how long it was going to write the solution? You can now use that to start defining the problem better. I’m not sure I can help much with how to do that, most of what I know about this stuff is hard to write down and I suspect very specific to my environment, experience and customers. My only real advice is go speak to the people who are going to use the software you’re writing, it is their problems you’re trying to find.

So you’ve got a nice juicy problem. Well defined and well understood by the team. Good stuff. So you want to solve this problem. How are you going to do that? My advice is get as many ideas as you can together. Go crazy. Go boring. Go contradictory. Go lateral. Go dumb. The more (different) ideas you have the better. Now it is time to start estimating again.

We’re looking for two things related to each idea. What is the potential upside and what is the potential downside? Good old Risk vs. Benefit. Nothing new here. For each idea we’re asking the team to consider the likelihood that the idea will be successful, and if it is successful, how quickly it will show a return and then how much of a positive impact will it have on our customer’s problem. We’re also asking the team to consider the flipside, the likelihood the idea will fail, how quickly it will fail and if it does go wrong what will be the impact on our customer.

What we are looking for is one or more solutions that are low risk and high return. Simply put limit the downside and maximise the upside. You might string ideas together. So if we do idea 1 first, and it is successful then we reduce the downside risk of idea 2. You might run 2 or 3 ideas in parallel. They all are low risk but chances of success are limited. This helps keep your options open. Maybe you’re unsure about the problem. Pick very cheap ideas that help define it better.

So you can see my concern about time based estimates. The cost of writing the software is such a small part of the overall risk of doing the work, why do we spend 100% of our estimating effort on this small area. Take the advice of the #noestimates people and stop. Instead focus on understanding the problem, maximising the benefits you deliver and reduce the risks involved.

References

• Dave Snowden “parallel safe-to-fail experiments”
• Chris Matts and Olav Maassen “Commitment”
• Nassim Nicholas Taleb “Barbell Strategy”
• Woody Zuill “#NoEstimates”

I’m not talking about politics here. The ins and outs of voting in a modern democracy is well outside the remit of this blog. I’m talking about voting in a work context. Sticky dots on post-it notes, fist of five (raising your fingers to show how support or otherwise), secret ballets etc. etc.

I’m sure there are valid circumstances where voting makes sense. I can’t think of any right now but I’m sure there are.

However in the bulk of situations where you have a group of people trying to get to the bottom of some thorny issues, or even figure out what the thorny issues are, then voting tends to guarantee a few rather dull outcomes. So what is my problem with voting?

1. Voting kills diversity. Voting is a great tool for silencing the minority voice ensuring only majority issues get discussed.

2. Voting leads to premature consensus. The group thinks that some kind of agreement has been reached because everyone has had their chance to vote, but voting can’t replace discussion.

3. Voting creates artificial harmony. Voting is a great tool for avoiding conflict. People can hide behind their scores out of 10, but once people leave the room, you won’t have achieved commitment from everyone about the decisions reached.

4. Voting gets to the average. If you want to discuss the thing in the middle, the average, the mediocre then use voting. But for my money the interesting stuff lies at the edges, the outliers, the best and worst.

5. Voting gets gamed. Once people see how voting is working, they will game the process to get their issues discussed. And unless the voting is truly blind (it rarely is in a work situation) then you’ll get more consensus building as people follow others voting patterns.

So if you see me in a meeting and my eyes glaze over next time someone suggests we vote on something you’ll know why!