More Advice
HBR articles are a bit like comic books for execs in that they always seem to be exactly what you want to read. That’s the style. If you read enough issues of HBR you can pretty much prove or disprove any management technique you can imagine. That’s because business is about people and people are pretty hard to predict and model when it comes to thought and associated behavior! That’s what makes all this so interesting.
From One Strategy, by Stephen Sinofsky (page 86) — emphasis added.
This was a quote I was reminded of when a new manager in my team asked if he could get a subscription to Harvard Business Review reimbursed by the company. We operate in a power-hierarchical organization, so he needs my approval for such things.
Somehow, the topic of advice came up during our conversation. I mentioned I was about to publish No More Advice, and we spoke about it a bit. We joked that I should really attempt to also try to make the complete opposite argument. An argument to promote advice giving. Maybe then, finally, I could get published in HBR myself.
Wouldn’t that be something.
🤔
Joke and I shall deliver.
Let me mess with your mind a bit. Indeed, after “No More Advice” I shall now argue the polar opposite.
Strap in.
A monolith consisting of one million lines of PHP code.
That’s what I faced when I joined my previous company. The code was officially declared “legacy” and new functionality had to be added by creating new microservices.
So, teams got to work. Some of these teams had no experience developing microservices whatsoever. Other teams had joined from other places and had considerable experience working in this new architecture.
As I watched the unexperienced teams struggle to build their software in the new way, I felt uneasy.
Somewhere I knew I would one day write an epic essay arguing against giving advice, but... watching this was tough.
On one side of the room I had people with collectively multiple decades of valuable experience. On the other side, I had struggling people with none. Of course, in time — over the years I suppose — the unexperienced teams would have made all the mistakes in the book and learned a lot along the way. And perhaps, they’d have built a better alternative to kubernetes — so that would have been a win. But... was that the best use of everybody’s time, and all that knowledge we had gathered in house?
Sorry, future Zef. But no more of that.
Unleash the advice, full stop!
I encouraged teams to run “architecture review” meetings. The concept was simple: the team would draw up a few quick diagrams of what they intended to build. Then, they’d set up a meeting, and invite some people with potentially valuable feedback. During the meeting, they’d lay out the plan and gather feedback. Based on this feedback, they could adjust their plans, or not. Up to them. This was not about getting approval, it was about getting as much valuable, relevant knowledge from within the company as possible to improve their design.
It was about getting valuable advice.
In “No More Advice” I argued against giving advice because it kills learning and creative solutions. And rumor has it that it kills puppies as well, but just the nasty ones.
However, there is another issue with advice. Advice usually consists of two parts: information and a recommendation. The part with the new information is great, no issues there. But what to do with that recommendation? If we don’t like it, can we dismiss it? That may really depend on the source.
Let’s say I am your boss. And you make the silly mistake of asking me for advice. Or, I’m having a moment of weakness where I try to fix my low level of self-esteem by forcing my endless wisdom onto you in the shape of advice.
Will you be able to dismiss it?
There’s power hierarchy at play here. I may have put a disclaimer on my advice with “you don’t have to do this, but...” However, do I really mean it? If you ignore my advice, and the shit hits the proverbial fan, will I tell you “told ya?”
Of course I wouldn’t. I’m nice. Or will I surprise you with it at your performance review? Nah. Or...?
What we need is a more neutral type of advice. Advice without recommendation. Often, what we’re really after is context augmentation:
“This is what I already know and how I look at it. What knowledge or experience do you have that adds to that?”
In other words, “could I bother you for some context augmentation, m’lady?”
Yes, that’s definitely terminology that’s going to take off.
For simplicity, let’s just assume that when we ask for advice, what we’re usually primarily asking for is context augmentation. And if there’s a recommendation, we’re truly free to dismiss it if we don’t feel it fits, without repercussions.
As I recently discovered, the design review meeting format I implemented is a domain-specific version of what in self-management circles is referred to as “the advice process.”
From the Reinventing Organizations wiki:
It comes in many forms, but the essence is consistent: any person can make any decision after seeking advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter.
Advice received must be taken into consideration. The point is not to create a watered-down compromise that accommodates everybody’s wishes. It is about accessing collective wisdom in pursuit of a sound decision. With all the advice and perspectives the decision maker has received, they choose what they believe to be the best course of action.
Advice is simply advice. No colleague, whatever their importance, can tell a decision-maker what to decide. Usually, the decision-maker is the person who first noticed the issue, or the person most affected by it.
In other words, the expectation is that before making a decision, people collect an appropriate amount of context: “I’m thinking of doing this, thoughts or alternative solutions?”
That’s right. Context augmentation, bitchez!
Who to query?
- The people who will be affected (the victims)
- The people who know a lot about the topic (the experts)
Then, the decision maker has to make sense of all of that, and come to a reasonable decision.
Beside the fact that this process should obviously have been called the “context augmentation process,” I really love this concept.
Naturally, we have to apply some judgment here. If you’re trying to decide whether or not to go to the toilet, you wouldn’t reasonably be expected to think of all the stake holders (e.g. the people you’re in a meeting with at that moment, the cleaning lady who will later clean after you) and ask their advice — you’d just go. Go. Just go already!
However, when you’d — hypothetically — would be interested in a subscription to HBR, wouldn’t following this process make sense?
When that manager asked me for permission to buy a HBR subscription, my decision process was basically “sure, why not.” That’s some YOLO decision making right there.
Following the advice process, the manager would likely have asked me and colleague managers (the experts) to see if HBR is worth it in terms of content. In addition, he’d check with finance (the victims) to see this was reasonable budget-wise, and if they already had some sort of other group subscription.
Likely, following the advice process would have lead to a better decision on spending company money than my “yeah sure, why not” approval.
More of that.
More advice.
Better decisions.