Skip to main content

6 Steps To Success With The Executives Above You

You probably think it's simple.  Your boss wants "good news."  The way it will work is three steps:
  1. You will do "a good job" at your job
  2. You will tell your boss
  3. They will reward you
"Brotherhood of Man" from "How to Succeed in Business Without Really Trying," http://armchairactorvist.blogspot.com/2011/06/friday-dance-party-attention-every.html
And yet one day, something goes wrong.  "Something bad" happens, or, worse, you "make a mistake."  Or maybe over a few weeks or months, you do some stuff and then one day you realize you have "been a major idiot," and "something bad" is going to happen.  The world is full of unpleasant cocktails of "something bad" and "making a mistake."  And let me also note that "you just got dealt a losing hand" can happen to you, and maybe it takes you a while to figure it out.  Maybe your choices are among alternatives which are all bad.

As a human, you are likely to react to this problem by continuing to report good news to your boss to buy time while you try to fix your situation in some way.  You are following time-worn personal guidelines like "you made the mess, so you clean it up."  Or "you're an adult, deal with it."  Or "you're a professional agile coach, you tell ME the answer."  You feel you have a responsibility and you will pay any price to do that job.  Honor requires it.

You are Colonel Nathan R. Jessep, a character played by Jack Nicholson in the movie A Few Good Men.  You have fallen so much in love with your own honor that you have put your whole organization at risk.  You don't know it, but you are on a slippery slope towards becoming the person who literally thinks you should get away with murder because "you know best," and it's "on you to make the right thing happen."  It's you against Cuba.  You are the cure that is worse than the disease.

From http://www.tumblr.com/tagged/a%20few%20good%20men?before=108 although I doubt "elena lizard" (no relation) owns this copyright....
See, it turns out that although your boss wants "good news," there is something they want even more than that.  They want "never to be surprised."  Never.  Being surprised makes them look like they don't know what's going on in their own organization.  You need to constantly ask yourself "if I were my boss, would I want to know about this?"  And if the answer is "yes," then you need to tell them.

This is where we get into a more sophisticated list of "how to succeed," but one that is still subtly wrong:
  1. You will do a good job
  2. Something bad will happen
  3. You will figure out how to fix the problem
  4. You give your boss information about the problem, AND the solution
  5. They will reward you.
Okay, no boss likes a "whiner."  And it is certainly the case that if you can fix a problem, you should.  But you risk being the world's most tiresome employee if you show up at your weekly "one on one" meeting every week with a list of problems identified and solved.  Identifying and solving problems is your job!  It's not news. (except in exceptional cases!)  Meanwhile, from your boss's perspective, "not being surprised" doesn't mean "finding out about stuff only after you have figured out a way to fix it."

You may not realize this, but if you are puzzled about something, you are creating a window of opportunity for somebody else in your company to casually mention to your boss that their entire organization is on fire.  They typically don't like that.  The longer the delay, the less chance you have to control the message, and the less chance they have to deal with both fixing the problem and messaging the situation.

So here's my suggestion:
  1. You will do the best job you can every single day
  2. Something bad will happen anyway, possibly through your mistakes
  3. You will ask yourself "could this situation embarrass my boss in any way?"
  4. If the answer is yes, you will alert them immediately.  Immediately.  That means right away.  You will text them if you have their cell number. 
  5. You will take full responsibility for your own part in the problem, "falling on your sword" as appropriate, and letting them know of any steps you are already taking towards making things right.
  6. Your boss will be angry about the bad situation.  Your boss may be angry at you.  But you have done the right thing.
But wait, you say, where's the "success" promised at the end of the six steps?  How do I make myself look good in the situation?  What's in this for me?  This story does not seem to have a happy ending!

You know what?  No, the story is not a happy one for you in the short term, or even for your boss.  Corporate life, and even your personal life, isn't an unending series of successes.  Things get better and things get worse.  You make mistakes, and your mistakes have ripple effects which hurt and upset people, and they get angry about them.  But you can still choose to handle this the right way.  And the right way is to create a pattern of being your boss's trusted partner on the ground.  Join your boss in doing the right thing for the company, even at the cost of temporary personal exposure as an imperfect human being.

http://www.smithsonianmag.com/people-places/The-Timeless-Wisdom-of-Kenko.html#
Also, to be a little less Zen and a little more pragmatic, if you allow bad things to happen behind your boss's back, they will get rid of you, especially if you are an expensive person to have on the payroll.

You may think that you can win the game of "always making yourself look good" in a corporate environment, and indeed you can win for quite a long time, but it's going to be in the form of one executive passing you to the next as an attractively packaged bomb.  Don't do that.  Please.  Do something real, and do your best to empower your boss with the truth.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…