This is a multipart series.
- Part 1: an overview of a workshop
- Part 2: the kinds of disappointment I mean
- This post: some tools I’ve found useful.
This series of posts describes a workshop I’ve run a few times, both inside my workplaces and at external events. I’ve found it a useful way to share some things I’ve learned and things I’m still struggling with, and to get participants to share ideas from their own experience.
This post describes some tools I’ve found useful for disappointing people constructively — it can be used as described in part 1, as a starter for discussion in a workshop, or it might be useful to just read through on its own and see if you can relate.
A toolkit for disappointment
Here’s a look at some of the ideas i’ve found really helpful — we’ll spend some time going through those, and see if they chime with what you know or give you ideas of things to try out.
“Waltzing with Bears” is a great book in general for dealing with risks and uncertainty in software development — DeMarco and Lister describe risk management and being able to talk about it sensibly as “project management for grown-ups”.
They talk about the disincentives built into corporate culture that steer us away from facing into all the things that could go wrong. They sum them up in this wonderful, run-on sentence: “These include can-do thinking, an unwillingness to disappoint, the imperative to preserve the rosiness of the rosy scenario, the fear of expressing uncertainty, the need to appear in control (even when real control is illusive), the temptation to use political power to trump reality, and the kind of short term thinking that plagues all human endeavours.”
That about sums it up for me — it’s worth reading through these, thinking about how they might be at play in your organisation, and what aspects of them might be holding you back from speaking up or admitting to yourself the flaws in your planning. Admitting these to yourself, and talking about them with others, are important steps.
Too often, people approach discussion about estimates and possibilities like a negotiation — this is seriously missing the point.
When you negotiate on something like a used car, you might be able to persuade the seller into agreeing to a price much lower than they’d hoped for. They might be frustrated, but you don’t have to care — you’ve won! You got a bargain price, own the car, and can head off happily.
When you negotiate on estimates, you may be able to persuade people to change what they’re saying and agree to things they hadn’t intended to — indeed, many senior stakeholders have years of negotiation experience. But in this case, unlike the car, you’ve changed nothing about the underlying reality. You’ve all agreed to say things are possible, but all you’ve won is disappointment.
Estimating, and other forms of predicting the future, are delicate and uncertain at the best of times — adding pressure and pushing for the answers you want is a dangerous activity. Steve McConnell author of the wonderful “Software Estimation: Demistifying the Black Art” wisely says that “With estimation, it’s hazardous to want the estimate to come to any particular answer”.
More advice from Steve McConnell:
“Because people use the word sloppily, one common mistake software professionals make is trying to create a predictive, approximate estimate when the business is really asking for a commitment, or asking for a plan to meet a target, but using the word “estimate” to ask for that. It’s common for businesses to think they have a problem with estimation when the bigger problem is with their commitment process.”
Separating these out — our best attempt at an unbiased estimate, the target we chose to aim for, and the commitments we make based around those — is a really useful way to be clear on how much risk you’re choosing to take on. You don’t negotiate on estimates.
Your estimate gives you a likely range of possibilities, and you can choose to put targets or commitments near the start of that range (making success unlikely, but choosing that with your eyes open), or further into the range if you want to make it more likely your plans will reflect what actually happens.
The book’s from 2006, but has timeless advice — both on practices to come up with estimates, and on the crucial art of talking about them sensibly. There’s no point being right if you can’t get anyone to listen to you.
What’s the definition of “MVP” in your organisation? And can you change that? In too many places, people have learned from experience that the least you will accept in “the MVP release” is the most you’re going to end up with, as the team focus and organisational priorities jump onto the next shiny object. With that history, the natural reaction is to insist on getting as much as possible into the first release, fight against any arguments for trimming, and need to know exactly how much can be done by whatever deadlines are important.
Changing the definition can really help. With a genuine commitment to iterate — a reassurance that something will be live soon, and there’ll be lots of time to explore how much better it can be made — insistence on specific features and an urge to know everything at the start can fade away.
There are lots of great stories and approaches to showing the value of starting with less — one of my favourites is “If your product is Great, it doesn’t need to be Good” by Paul Buchheit. He worked on the original version of GMail, which was so stripped-down it was almost embarrassing — but it had some key features that made it really stand out and made users happy to wait for the list of “standard” features to come later. “If the basic product isn’t compelling, adding more features won’t save it.”
However, discussion about ideas like this needs to start early — far away from any desperate deadlines or specific projects. Bring it up and repeat it often. With enough seeding, these can become ideas that get considered, then tried, then standard practice.
Get better at telling stories. Most people don’t understand the nature of software development — the real uncertainties that can only be made clear by starting on the work. It’s tempting to give answers that are either misleadingly precise or maddeningly vague, and leave people feeling they don’t know what’s going on.
Bring people along on the story; explain to them what areas you’re sure about and what you don’t know yet. And importantly, give them clear signposts on when things will be clearer. Answers like “between a month and 6 months” are much easier to deal with if you can explain “after these things are done”, or “after this date, we’ll expect to give definite answers on whether it’s in for the deadline / whether it’s at the top or bottom end of that range / start using days instead of months”.
The cone of uncertainty is a classic tool for illustrating how difficult predictions are early in an endeavour, and how much clearer they can become over time. Steve McConnell has data that shows early in a project, when scope is still high-level and unclear, time to complete can vary from 4x to 0.25x your most likely estimate. That’s the absolute best range anyone in the industry can hope for, experience has shown that it is not possible to predict with more certainty than that. It is, however, very possible to do worse.
At this early stage, if you’d like the cone to narrow towards the shorter end of the possible timescales, there are big, clear scope decisions you can make that pull it one way or another. Does it need to have an app version as well as the website? Do things need to update instantly, or can there be a lag? Decisions like these can have a big impact.
Later in the code, hundreds of smaller decisions come up that have a big cumulative impact. It’s important to give the team doing the work flexibility to make the decisions that steer towards the big-picture scope and schedule stakeholders want — trying to plan it all up front, or have every decision reviewed and approved, just isn’t feasible.
Another topic to consider is how you cope, personally, with people’s reactions when you disappoint them. Giving someone bad news about a cherished idea and plan can provoke strong reactions. It’s hard not to take these personally and feel attacked, or to worry about them so much that you avoid giving the bad news at all.
An idea that’s helped me is to think about the stages of grief (the “Kübler-Ross model”). I believe that people are going through some version of this as they realise their plans aren’t possible. The reactions — denial, anger and others — are a part of them coming to terms with this, and aren’t really aimed at you, the messenger. If people getting serious illness diagnoses go through these stages, and express anger and bargaining with their doctors even when it’s clearly nothing the doctors have done or can help with, then I feel a little less attacked and more sympathetic when stakeholders are expressing these. Sometimes offering empathy, rather than the instinctual responding in kind, can help get to acceptance sooner.
When getting my notes together for this post, I looked into the history of this Kübler-Ross cycle, and was very surprised to find that the existence of these stages has not been demonstrated; there’s no evidence that people actually move through from stage 1 to stage 5. My first reaction was “that can’t be true! I’ve heard this cited loads of times!”, quickly followed by “well if it’s not true, why didn’t anyone tell me? How have websites just parroted this without telling me it’s all made up?!?”. Later, I found a quote from George Box:
“All models are wrong, but some are useful”
That view’s helped me feel OK about this model again — it may not be empirically true, but we can still use it to help work with people.
Despite my earlier assertion that talking about estimates cannot be a negotiation, my absolute favourite, must-read book for this toolkit is “Getting to Yes” by Roger Fisher and WIlliam Ury, the classic negotiation handbook. It’s full of advice that was new to me, plus plenty of things that I’d found worked but hadn’t realised why.
The skills this book helps work on are about helping people to listen to each other, to recognise that you’re all on the same side battling a problem situation, and to consider objective reality and options rather than digging into positions.
One example of a great concept from Getting to Yes is showing you understand the other person’s views and position.
“Many consider it a good tactic not to give the other side’s case too much attention, and not to admit any legitimacy in their point of view. A good negotiator does just the reverse. Unless you acknowledge what they are saying and demonstrate that you understand them, they may believe you have not heard them.”
If you can state someone’s case more strongly than they can state it themselves, they can relax — and perhaps that’s the only way you’ll get them to listen to your objections. “Neil gets how important this is and what needs to happen, I know he does — and now he’s saying there’s a problem? I’d better listen”.
Another good bit of advice: I’d tried formulating various rules over the years about when communication might be unclear: “after meetings, people may not have heard…”, or “when x is involved, it’s important to state y in writing…”. The authors have summed things up much more comprehensively than these specific cases did:
“Whatever you say, expect the other side to hear something different.”
That’s a brilliant general policy. I’d recommend assuming all this to be true:
No-one listens to what you say. No-one reads your emails. No-one opens your reports. No-one looks at your presentations.
The reality isn’t quite that bad, but it may be close. If you think about working in that kind of environment: what are you going to do to make sure you get your points across?
We’ve talked about different kinds of disappointment already: the ghost of disappointments past (all the words and actions that have led people to behave the way they do), and the ghost of disappointments present (the harsh but necessary truths you’re laying out about the current state of the plans and projects. But we still need to talk about one more: the ghost of disappointments yet to come.
It’s easy to stop once you’ve laid out what you know about sensible plans and possibilities, but there’s usually more you can do to dig into what else might still jump out and derail these intentions. It’s not responsible to let people think you’ve mapped out the future, and if they can deal with the disappointment you’ve given them now then there are no more unpleasant surprises to come.
Waltzing with Bears is the best source of advice for thinking about the big, scary risks that might be waiting for you. It points out that lots of risk management is really risk theatre — writing down a list of some fairly inconsequential things that could go wrong, while ignoring the real showstoppers. For example: how many of the projects that start in your company just get binned before they actually launch? How often do people resign from your teams, and what key people’s departure would sink this? You need to talk about these, what you can do to mitigate them, or all agree to accept them.
The book uses a good metaphor to describe this unwillingness: Risk theatre is like someone walking down railway tracks, looking in detail at the rough ground and carefully planning how to not trip over the railway ties, and never looking up to see the oncoming train.
“Attack your nightmares, not your petty worries”
That’s the tour of my toolkit. Sound useful? You can go back to part 1 to see how this tour fits into the workshop, or to part 2 to see some scenarios where I’ve handled disappointing people poorly and consider whether any of these tools might have helped conversations go better.