Speaking of confirmation bias …
Confirmation bias is a tendency we all have. It’s what leads us to accept without question expositions we agree with no matter how flawed they might be, while nitpicking to death ones we dislike no matter how carefully constructed.
We typically unleash our confirmation biases on presentations consisting of evidence and logic. But I’ve noticed that clever quotes, wisecracks, and even cartoons can also trigger the effect.
Cartoons (not this week’s subject) are probably the most pernicious, because really, don’t you feel silly arguing with a sketch and a caption? But clever quotes are, I think, a close second, which brings us to the subject of this week’s diatribe – Admiral Grace Hopper’s frequently repeated, “I’d rather ask for forgiveness than permission.”
It’s a quote that, when you don’t stop to think about it, encourages us to stick it to the bureaucrats who force us to jump through a cube-farm-full of flaming hoops before we can do something that is, to our completely objective foveae, Common Sense.
When you do stop to think about it, your flaming hoop is someone else’s hard-won wisdom.
Maybe I’m just confirmation-biasing Admiral Hopper because of her role in creating COBOL – a hideously inelegant language whose approach to basic arithmetic: ADD L TO M GIVING N is harder than Roman numerals to quality-assure, in contrast to FORTRAN’s more enlightened N = L + M.
But my confirmation-bias aside, I wonder if, as a naval officer, she would have been as forgiving to a subordinate who neglected to ask her for permission before charging ahead with something risky as she hoped for forgiveness when she took her own advice.
We’re faced with a dual challenge. An organization’s policies, procedures, governance, and compliance requirements represent the accumulated knowledge, judgment, and wisdom it has acquired since it first launched itself into the marketplace.
Ignoring them because they’re inconvenient given what you’re dealing with right now might not be the best way to stay on the right side of the line that separates self-confidence from arrogance.
But on the other hand, all the accumulated knowledge, wisdom and so forth is about the past. The action you’re contemplating is about the future.
To the extent you expect the future to resemble the past, you should, at a minimum, take the time to make sure you can articulate why waiting for permission would be damaging.
And to the extent your expectations of how the future will come out make the organization’s stored memories irrelevant, the day you take your first step on the path toward needing to ask for forgiveness isn’t too soon to start preparing a compelling narrative that explains why and how today’s constraints aren’t relevant to what tomorrow will require.
Compare Admiral Hopper’s formulation to that of a different naval officer: D. Michael Abrashoff, former Captain of the Benfold and author of It’s Your Ship: “Whenever the consequences of a decision had the potential to kill or injure someone, waste tax-payers’ money, or damage the ship, I had to be consulted. Sailors and more junior officers were encouraged to make decisions and take action so long as they stayed on the right side of that line.”
Bob’s last word: There’s another dimension to all this: Sometimes opportunities and threats arise all by themselves. They’re both real and ephemeral – by the time you finally get approval they’ll have passed the organization by.
Admiral Hopper’s guidance was, I hope, directed at these situations, where tactics legitimately get ahead of strategy.
That is, what I hope she meant is that if you had jumped through all the flaming hoops you would have ended up receiving permission eventually.
Wise leaders, though, provide guidelines along the lines of those Captain Abrashoff gave his crew. Do this and you make asking for either permission or forgiveness irrelevant.
Bob’s sales pitch: I’m always interested in what you’re interested in … and what any non-subscribers you know would be interested in.
My most frequent topics are, in no particular order: leadership and personal effectiveness, business ethics, career management, metrics, office politics, organizational change and effectiveness, project management, and architecture.
To name a few, but I’m open to other suggestions, too.
Please take a few minutes to let me know.
And yes, I do accept emailed in ballots. And no, I don’t require a photo ID to accept your vote.
On CIO.com’s CIO Survival Guide: “Why every IT leader should avoid ‘best practices’,” explaining why CIOs would be wise to know there are no best practices, only practices that fit best.
DUH.
N = M + N shoud read N = M + L
Would you believe it was intentional, to show how easy it is to find bugs in FORTRAN code?
I didn’t think so. Don’t know how that crept in. Thanks for pointing it out.
Hey, Bob, I don’t know this but perhaps the Cobol expression order was in deference to Polish notation, which in the early day of compilers may have been easier to handle although as you point out, Fortran went the more human familiar direction of infix notation. (if I remembered my assembly language operators better from 40+ years ago I could make a better case). For those who may not have encountered this, Cobol uses Polish or prefix notation, which places the operator first (+A,B). Reverse Polish Notation means the arguments come first, and then the operator (A,B,+). Infix notation, which we learn in school, has one argument, then the operator, then the second aragument (A+B). I wrote very little Cobol but a good bit of RPN in other situations and found if you used it regularly it worked just fine. However since it was different from what everyone learned in school, it was one more barrier to using whatever system/hardware required it. Oh, and “Polish” referred to the nationality of the inventor, Jan ?ukasiewicz (credit Wikipedia).
Maybe I’m just being mean, but it seems to me that, all things being equal, connect the dots to what people know. As you point out, infix notation is closest to what we all learned in school. I can accept that HP’s programmable calculators used reverse Polish notation, on the grounds that users could get the job done with fewer keystrokes, but that’s not for a general-purpose computer.
Anyway, thanks for such an in-depth explanation. Very much appreciated.
You make a great case for policies and procedures to be reviewed on a periodic basis.
Most of us know a story of something that made sense at the time, but is no longer necessary.
The danger is less about time/effort wasted on an obsolete procedure, and all about developing a culture that ignores procedure.
Spot on, Gregory. My work life is so encumbered with processes built to ensure that This Can Never Happen Again! that the result is that so many things that should happen don’t happen.
A sunset date on every policy and procedure forces a look at whether the controls implemented are still relevant and in proportion to the risks they were intended to address.
Perhaps the worst Bob Lewis column of all time? Could be as I have read them all…
As a former FORTRANner and COBOLler I can say that you can’t compare apples to oranges. Both languages were great for their time but had different purposes. And COBOL paid the bills for lots of organizations for decades. Some of my COBOL programs written in the 1980’s are still in use today. Eventually they will all be replaced. I suppose elegance is a desirable attribute for a programming language but not very important compared to functionality.
And don’t get me started about one of my heroes, Grace Hopper. I doubt that she would take risks to the extremes posed in your column. I’m sure she would squish you like a computer bug if she was still horizontal…
1. I seem to remember reading somewhere that Grace Hopper’s team’s job was to create a user-friendly, cross-platform language that businesses would adopt at a time when the term “computer science” did not exist.
They decided to make it as close to English as possible. Their strategy seems to have worked well in gaining a firm foothold for information technology in American business until programmers, personal computers, and software sophisticated enough that users really could develop the group tools needed to better do their jobs in a timely manner, came along 6 or 7 decades later.
Developers left FORTRAN, MUMPS, C, R, C++, etc.for us geeks to figure out how to integrate these more elegant and powerful tools into the organizations we work for.
But I’d say Ms. Hopper did a pretty good job of achieving the task she was given 70 years ago.
2. When are you going to continue your 12 different ways of thinking columns? IT folks need all the tools we can get to understand our users, other managers, and each other we can get.
I found your first articles in that series quite useful.
My dislike of COBOL stems from its intrinsic wordiness, which I do think makes debugging more difficult. Also … not necessarily the language’s (or Admiral Hopper’s) fault is that its logic re-use usually depended (this is experience from decades ago when COBOL dominated) on copylibs rather than subroutine calls. That’s a bad practice regardless of its source.
Thanks for asking for more “ways of thinking.” I’ll see if I have any more. Do you have any you’d like to add to the pile?
COBOL when it was invented…transformative. COBOL for the modern organization to transition from legacy systems…not so much.
As a former substitute teacher specializing in math teaching, my framework on thinking mirrors the work of Kathy Kolbe. Some people just need an overview, what are the important relationships, and a concrete goal, and they are good to go (Newton). Others need to develop a rigid framework the covers all the bases and gets them attention for what they accomplish (Franklin and Trump), and they can creatively reach their goals. Still others can readily modify the basic assumptions of their framework to figure out which goal they should be reaching for, in their slow moving and low profile manner (Wittgenstein). Finally, there are those need an “excruciatingly detailed” map of the goal, with all terms firmly defined to created an unexpected perspective (Einstein and Hitler).
I suspect thinking styles are strongly related to learning styles, and helped me to effectively change gears to most effectively reach my various students for both arithmetic and algebra. You may have to reverse engineer the thinking styles you’ve seen to connect to the learning styles I mention here, as each learning style usually has more than one communication “signature”.
Thank you!
Hi Bob, w.r.t. your article in CIO about best practices, I think you’re being really unfair and have probably triggered off of a couple of bad experiences that you have had.
You concede that “Best Practice” (BP) is contextual – that’s very true. But then you go on to argue that nothing is best practice and that we should all avoid using the phrase to avoid stifling innovation [paraphrasing]. Further you submit that when a company offers best practice, it is fraud…
You are, in effect, ignoring your own advice, which is that CIOs need to be flexible.
When an organization offers you their “best practices”, what they are offering is their years of experience in working in their domain – something that you very likely don’t have. If you did, you wouldn’t be speaking to them in the first place.
Yes, granted, if all you get from a vendor is a pdf labeled “Best Practice” then you’re right – their BP is possibly not the BP for your context.
But I have never worked with a consulting org that worked that way. They always deploy professionals on projects, who are further supported by industry leading domain experts (with many years of real-world experience – again, something your org is probably missing) to analyze the context and use that experience to help define the best practices IN THAT CONTEXT.
They can do this effectively because they understand things that took them years – and several other projects costing millions [collectively] – to learn and develop.
And yes, business and IT processes will change as the organization changes transforms and matures – what is “best” now, may not be “best” in 5 years – and that’s okay. I have rarely worked with an organization that is able to adopt all of the “best practices” from the outset – they usually have neither the skillset nor the org structure to adopt them.
And that’s okay – as you have said, transformation is a journey, not a destination.
In all honesty, I think “Captain Literal” got too caught up in a phrase and lost the core message of flexibility and change. He saw “fraud” in a phrase instead of the opportunity to leverage your combined experience (the vendors in their market combined with yours in your own market) to develop the best practices – thereby jumpstarting your capability and improving the likelihood of success of achieving your goals.
I’m routinely asked about “best practices” in my own domain (by customers) and the first thing we do is sit down and figure out what they are trying to achieve and why – as you so rightly point out, is the starting point.
Well, maybe. Usually my alter ego is “Captain Yeahbut,” not “Captain Literal,” but either way I’m happy. In my experience, when a way of doing things is characterized as “best practice” it’s a form of argument by assertion – of cutting off discussion of alternatives. Your experience is different, and that’s a good thing.
I’ve seen variants of that quote but the one I recall, apparently from a “Chips Ahoy” article is “It’s easier to ask forgiveness than it is to get permission.” which is a very different than “I’d rather…” One is an observation, the other is a statement of principal and/or advice.
She is also quoted as saying ” If you’ve got a good idea, and it’s a contribution, I want you to go ahead and do it.” A good manager hires good people and then expects them to show initiative and trusts them to do good things without micromanagement.
I’ve never seen a quote of hers that implies that one should do wrong things or flout regulations.
I grew up at China Lake where my dad was an engineer during its heyday. If the people there had run every idea up the chain of command before pursuing it we wouldn’t have the Sidewinder missile, the most successful and copied air-to-air weapon in history. The task they were given was to make a fuse for a missile but the engineers wisely realized that a fuse was useless if you couldn’t hit the target so, unasked, they designed a guidance system and let the result speak for itself. That’s the thinking that Grace Hopper supported.
Thanks for the clarifications. And to be fair to Admiral Hopper, I was writing about my experience of people using her phrase as an excuse for ignoring policies and procedures that shouldn’t be ignored. Consider her exonerated – something I’m sure her heirs will be relieved to read.
I enjoyed your “Forgive me” post, and I think you made a lot of good points (as always). I’ve never really liked the “I’d rather ask for forgiveness than permission” attitude, in most cases, and I’m reminded of something that happened at a job I had back in the late 1990’s.
Our CTO, who was a former naval officer by chance, plunged ahead with an expensive contract for designing a new website without consulting our CEO using this line as his justification. I don’t know if he ever asked for forgiveness or not, but when the CEO found out about it, our CTO was fired.
So I guess if your plan is to bypass the permission step, just remember that forgiveness is not always given!
While I was familiar with the phrase about asking forgiveness (and I’ve invoked it several times), I hadn’t realized it was attributed to Grace (sounds like one of those lines that has been around in similar forms )
And I love what the captain said – that was exactly the spirit I always applied when considering going the forgiveness route. There were too many times I saw colleagues fretting about whether to ask permission for things that seemed to fall in the category of ‘why waste your manager’s time asking?’
[and outside work, there are many other times this applies – like a public bulletin board policy that says all postings have to be approved. What’s the worst that can happen if you post an unapproved item?]
To answer your last question, I get Comments that are tasteless, vulgar, and, at times, just unwelcome advertisements. Those posting don’t ask permission which is just as well.