Whether you’re making a change to a business or technical strategy, changing the terms of employment contracts, how promotions should work or any other decision that could impact an organisation, there’s a tension between being efficient and being inclusive. I’m going to use the worn out metaphor of an onion to explain the steps I go through to deal with this tension. Plus onions with a moustache are fun and easy to draw.
Being efficient in this context is to reduce the number of people consulted in order to keep focus and move fast. The upside is that you can move quickly due to limited risk of scope creep and indecision due to fewer conversations, fewer viewpoints and fewer iterations. However, fewer people included may result in increased likelihood of a negative or unexpected outcome. Furthermore, you run the risk of eroding trust by neglecting those who feel should have been consulted.
Being inclusive is to give lots of people, possibly a whole organisation, a voice on a decision. The more people you include, the greater the risk of loss of focus or control of scope, a large number of iterations and significant effort consulting people. Being inclusive doesn’t necessarily eliminate the risk of a bad outcome, especially if you treat people with low knowledge on a topic as equal to those with a high degree of knowledge. Furthermore, being inclusive only reduces the risk of upsetting people but does not eliminate it: the larger the organisation the larger the diversity of thought, desires, motives and interpersonal conflict.
To satisfy my desire to move fast and my need to be popular in order to validate myself as human being, I go through a series of steps which I’ll now outline.
An Onion Metaphor
The first, inner, layer. These are the 3–5 people I talk to first. I’ll draft what I want to propose and give these people the semi-organised mess of my thoughts. The people I select here usually have four qualities:
- They’ll give me honest but friendly feedback. If they don’t understand something or think something should be rewritten, they’ll tell me or make proposals. Or even rewrite what I’m suggesting.
- They’re adequately knowledgable in the domain and ensure what I’m proposing isn’t nonsense.
- They have the motivation and ability to give feedback. There’s no point on asking people who don’t care because they may not give feedback.
- They fairly represent the organisation. If this change effects 3 departments then I’ll try and find at least one person from each. I also try to ensure a reasonable demographic spread as well.
This layer is where I spend the most time and effort adjusting what I’ve written. By the end of this, my plans should be in presentable shape.
The second layer. These are the bosses, the highest level of management in the organisation affected, usually these are Vice Presidents and Directors, depending on the change this could also be folks from HR and C-level. Most companies aren’t democracies and not many big changes will be successful without the bosses being ok with what is about to happen to their teams. This layer has some natural benefits beyond just moving forward:
- This group may provide valuable feedback and have experience in similar situations themselves.
- They may be able to tell you who will be most affected and thus who you should include in the next layer.
- Their approval to proceed will make it easier to convince others, especially those who place high value on seniority.
The third layer. These are, by your best judgement and advice of others, the people that have been identified as most affected by a change. Try to limit group size to 10 or less, even if it requires multiple feedback rounds with different groups should there be a lot of highly affected people. Too many people and you’ll be trapped at this point until retirement. This layer has the important benefits of:
- Finding issues and edge cases before the wider organisation is impacted. This is like the QA engineer who presses all the buttons and tries to break something. The feedback here is incredibly important.
- Making people feel included. Making this group feel included not only has benefits in terms of quality feedback, this is the group who could react most emotionally to being surprised. This is your opportunity to, albeit briefly, not be an asshole.
- When presenting the change to the whole organisation, you gain credibility by having consulted this group.
The fourth, outer, layer*. This is “everybody” and probably they’ve already heard rumours which, accurate or otherwise, have the benefit of reducing surprise. You’ve got the ok from people who know what they’re doing, you have listened diligently to feedback, incorporated the feedback that’s useful and explained why you’ve not incorporated the rest. The most affected people understand what’s going to happen. The managers are happy and you’re happy (which, in the absence of proof that anything is real, is the most important thing). Next you need to tell the whole organisation that something has, or will, change.
I’ll not go deep into how to communicate changes to your org but one thing’s for sure: tell people and, of course, openly thank those who helped. How to tell people will vary based on what you’re changing but here’s my list of preferences of how to communicate changes to people from most effective to stupid:
- Roadshows of individuals, teams or departments. Create an environment where people feel comfortable, can ask questions or point out something obvious that you’ve failed to pick up on before.
- One big meeting whereby you tell everybody.
- A great big global email.
- Changing everybody’s screensavers and desktop backgrounds to “your contract just changed, deal with it” (even if it didn’t).
To ensure the pace of progress is good and the people impacted are less likely to freak out, it’s worth keeping in mind the following things:
- The feedback from each layer must be time boxed (e.g. 2–5 days). Give a clear date by when feedback should be given. Opting out of giving feedback is the same as saying “I agree”.
- Take feedback in whatever format the reviewers are comfortable with. If they want to sit and talk, super. If they want to leave comments, fine. If they want to send an email or message, sure why not. They’re doing me a favour.
- It’s really important to be able to rationalise why people have been excluded. Listen to the concerns of those people should they raise any and, if they have useful input, use it. To ease this feeling of rejection, I find it helpful to list the names of people who did give input during some form of announcement, so the whole organisation feels represented in some form.
- Unless you really have to for some legal or ethical reason: don’t hide what you’re doing. You want to reduce therefore the emotional reactions that come with surprise. Again, like good product development, try to avoid a “big bang” release.
- Know when to stop. If the people you trust the most in the first layer think you’re heading in the wrong direction, rethink. If the big bosses don’t believe in what you’re doing, it won’t succeed. At this point decide whether to iterate or to stop for a while so you can come back later and try again with fresh eyes. Or never again.
Using layers of increasing participation and data is no different to good product development: you have some idea to solve a problem, you work with a small group of people to ensure your idea is sensible and you expose it to ever increasing groups until your confidence is high enough to launch, iterate or abort. Easy(ish)…
Thanks for reading!
* While writing this I discovered that the skin of an onion is called a “tunic”. This fact is not only the perfect conversation starter for a date or at a party, it’s probably the most useful takeaway from this whole blog post. You’re welcome.