One year ago I saw a fantastic article in MIT Sloan Management Review called Effective Leaders Decide About Deciding where the author, Nancy Duarte, CEO of Duarte Inc. describes how her firm overcame the ineffectivness that sets in when team members are unclear about what the leader wants to be involved in, and what they want handled without them.
The Interference Problem:
Before diving into the solution they came up, it's worth dwelling on the problem for a second. I think the author nailed it with this passage
"Because I’m passionate about multiple facets of my company, my executives were getting confused at times about why I was inserting myself into a conversation. Sometimes, it was simply my excitement, and other times, it was from a place of concern. Sometimes, I didn’t see how their execution of a strategy lined up with what I saw in my mind’s eye. This made my executives blurry about what they had the power to act on and when they needed to loop me in — in part because I wasn’t clear on those things myself. Decisions would stall. Frustrations would run high."
And if we flip this around to look at it from the junior's perspective, it's clearly a drag on doing business. I mean, who hasn't experienced the pain of this problem at some point?
Sometimes you'll lose a lot of time unnecessarily when you over-produce work that isn't important to the boss, but at other times you'll lose time if by under-producing things that are important to them (when you need to get feedback and start over). Similarly, you can waste too much time over-consulting the boss or other staff about a change to policy or procedure, but you'll lose more time if you under-consult and implement something they hate. Choosing the right level of effort to 'invest' is tantamount to guessing what's going on in someone else's head, and when you are forced to guess, it's usually wrong.
A Solution to the Interference Problem:
So what did they come up with? The leadership team came up with the following matrix that created four different decision types, each demanding a different level of involvement from the leader:
By being explicit about how different decisions were to be handled, it gave everyone more clarity about how to involve their leader (and gave the leader a more positive way to insert themselves into conversations).
I thought this sounded brilliant! So I decided to try it out with my own department. But in practise we ended up with something different, which I explore below.
A Delegation Matrix
As usual for me, it didn't long for me to try to make the tool into something it was never intended to be.
In my opinion, the bigger opportunity with a matrix like this was to improve the way a manager delegates tasks or projects to their reports. I find that, because of a few cultural quirks in the modern workplace, there's a huge amount of noise affecting the way tasks are delegated which sets the receiver up for failure.
Why delegation?
To consider this properly, let's look at each side of the delegation 'transaction' in turn:
To the junior, the report, the approach is rather simple. When your boss gives you a task to do, you should do it well. If a higher level boss (like your two-up, three-up or the CEO) gives you a task, then you should do it really, really well!
But to the more senior staff member, they may not always be looking for that level of investment. To the delegator, the manager, they are often delegating a task because it's one of the least important matters on their desk. But sometimes not. Occaisionally when something really important comes along the manager may want their best person to make a start on it straight away and do their best possible work. And perhaps there are some tasks that fall in the middle. The point is, it varies.
And it's the instability of the brief from above which is the problem. Moreover, I think this problem is made worse by the typical leader's hesitation to label anything as 'not important'. There are too many unintended consequences.
Imagine that I'm the leader of a department of roughly 100 staff. If my peer, who is the head of similar sized department asks me for an org chart of my area. She only wants it to be able to reference later, and she only asked me because we are in regular communication anyway. This is not a priority task. But if I tell my team that it's "not important" while delegating it, they may miss some of my meaning or read too much into it. They may think I don't think my peer is important. They may think requests from the other department are not important. They may think that org charts are not important. Honestly, it's too difficult to tell what reading between the lines people will do, which is what makes it risky.
This is dangerous because on another day the task could be extremely important. If the org chart was needed to investigate a potential cyber attack, then it's likely to be a high priority task and the quality of the work needs to be superb.
The Delegation Problem:
The top problem with delegation, as far as I'm concerned, is that it's too time consuming and risky to establish how you want be involved through pattern recognition. That is, through many iterations over time, where you rely on the other person to 'get' you (this would happen by delegating a task without clearly specifying how you want to be involved, letting the employee use their judgement, and then giving them feedback when they get it right or wrong). Even for two really good communicators, it would take them about 6 months for them to sync.
Once they finally do sync, they can be very efficient. From that point onwards, very few words need to be exchanged during the delegation and very little nuance is lost. But when you consider that the employee may only work for that manager for 2 years, a training period of 6 months feels like way too long.
A Solution to the Delegation Problem:
What if, instead of spending months syncing through trial and error, they had a framework that sped up each individual delegation conversation? One that allowed very few words to be engaged from the start, but where nobody got offended, and there was very little risk of the over-interpretation I described above?
Well that's what I morphed the Duarte matrix into — a tool that helped me to delegate a task and make it perfectly clear to the receiver how I expected them to involve me by only using four extra words ('this is a [rating]').
My matrix looked like this:
How to use the GSB Matrix
The two axes are speed and quality. These refer to the speed and quality you'd like the work product to be.
The Quality dimension uses the categories "Gold", "Silver" and "Brown". The precious metals analogy seems to fit well here and this makes it easy to remember. But what is a 'Gold' standard of quality anyway? Isn't it super subjective? Yes it is, but you can still peg these standards to something that's unambiguous for everyone involved. Mine were:
Gold = do your absolute best possible work. That means taking care of every possible detail you can such as formatting, referencing, limitations, as well as doing everything possible to strengthen the substantive output (e.g. maximum possible background research, stress-testing the ideas, etc.). It means leaving nothing that you were capable of doing unfinished.
Silver = do quality work, somewhere between 75-85% of your best. People can't deliver their absolute best on every single task, and oftentimes it's not actually necessary. It's far more common that something needs to be done well — to a standard that's approaching their best work, but it gets tied up before you hit the major diminishing returns of trying to extract that final 15% of performance.
Brown = adequate quality is fine — just get it done and take it off our list. Most people ask why the B isn't for 'Bronze', well this is why. Bronze is still a precious metal and that would imply yet another level of quality which demands lots of careful effort and attention from the employee. No, the sub- or micro-analogy here is that the brown substance is just sludge that needs to move through the pipes. It's not inherently valuable, it just needs to keep moving or it will create negative value through a blockage.
Speed is quite straightforward. It is divided into two speeds of "HIGH gear" and "LOW gear". I knew it was possible to get a more finely grained list of speeds going, but I didn't want to have more than six squares in the matrix, because I didn't want the act of using it to classify tasks to become too slow or mentally taxing, otherwise it wouldn't get used at all. The speeds I came up with were:
HIGH gear = tasks to be completed to a known deadline in the near future or genuinely ASAP. Or in other words, the boss is certain this needs to be finalised in the short-term. I added the word "genuinely" in front of ASAP because I know there's a lot of fake ASAPs out there and wanted to make the delegator pause to consider the genuine-ness of labelling something as 'ASAP'. If it doesn't need to be finalised ASAP, they should set an internal deadline that's more reasonable to keep it as HIGH gear, or otherwise accept that it's LOW gear. This also gives the employee to question whether an ASAP is legitimate without offending the boss. By communicating through this GSB tool, the employee doesn't have to question a deadline directly if they don't want to (they are just clarifying which square it is on the matrix).
LOW gear = these are tasks to do between or after HIGH gear tasks. Which kind of says it all. Just put it in a queue and do it when you can. If it became urgent or the stakes changed, it would become a HIGH gear task anyway, which leads me to my final instruction.
It's perfectly okay for tasks to be re-classified. If something got a "B1" grading because it didn't seem urgent or valuable at the time of handing it off (for example, reviewing a certain process), but subsequently turned out to be really important (continuing the example, a compliance issue being investigated by the regulator), then it makes sense to re-grade it to a "G2". The most important thing is that the new grading is communicated and the employee knows why it was changed.
How did users react to it?
At first people throught I was crazy. And I must admit, I don't blame them. If matrix is not introduced to someone via a warm and friendly training session, it initially looks like the worst of managerialist fads.
But for most people, after some time (and after the GSB Matrix had saved us both of us a lot of time and suffering), they warmed up to it. It became quite empowering for some people — especially the non-confrontational ones — to give them a way to get more structured information about the task, the criteria defining success, and even to question and challenge the boss' perception of these things.
Next steps
I've only implemented the GSB Matrix in one workplace so far. While it's had promising results, I obviously can't be completely confident it works in other settings yet. It could be be dependent on a certain type of team culture, or the dynamics of a certain industry.
I'm eager to continue applying it in new settings, and I'm very eager to hear from anyone who tries it out, so I can tweak it for broader applicability.
Cover image from Wallpaper Safari
Comments