Friday, February 15, 2013

You probably think it's simple. Your boss wants "good news." The way it will work is three steps:

You will do "a good job" at your job

You will tell your boss

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:

You will do a good job

Something bad will happen

You will figure out how to fix the problem

You give your boss information about the problem, AND the solution

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:

You will do the best job you can every single day

Something bad will happen anyway, possibly through your mistakes

You will ask yourself "could this situation embarrass my boss in any way?"

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.

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.

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.

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.

Friday, February 8, 2013

In 2004, Thomas Friedman famously argued that in the age of "Globalization 3.0," The World is Flat, by which he seems to have meant that with current technology, big companies can shop all over the world for the cheapest and best laborers, rather than building local teams. The book brought the issue to the attention of the general public, particularly in the US, and spawned a big discussion, including this entertainingly polemical review from Matt Taibbi.

Instructions for making your own flat globe are available here: http://makingmaps.net/2007/09/19/making-flat-earth-globes/

Whatever you think of Friedman or Tiabbi, software development people can tell you that indeed, the modern "enterprise" team will most certainly include participants from some assortment of Western countries as well as some subset of the BRIC group (Brazil, Russia, India, and China), or maybe new players like Vietnam or the Philippines. Distributed software development is the norm rather than the exception in the world's biggest companies.

Bulletin from pragmatic people working every day with distributed teams: the world is most certainly spherical. And this means that there are some things you need to consider, in order to allow your team to work together smoothly, once you have pieced it together across multiple national lines. I have been coaching really big teams for most of my life, and I can tell you, in the spherical world there are real logistical considerations that you don't see when the world is flat. To wit:

Time zones: Technology may allow you to have an instant message or a telephone call with anyone on your team at any time, but you should still consider questions like "is the person awake" in their time zone, before you press the green icon on your iPhone, or the "schedule a meeting" button in your shared calendar.

Local network speeds: Technology may theoretically allow you to have a shared online project dashboard, hosted on a server in Hong Kong, so that everyone in the world can see the real-time "traffic light productivity rating" of all your project work streams, but someone needs to make sure you have sufficient network bandwidth to load the dashboard on the CFO's console in Paris in less than ten minutes.

Working tools: Technology may allow you to set up video conferencing from everybody's laptop, theoretically, but somebody needs to figure out how to keep those connections from dropping whenever there is a lag in the action (yes, I'm talking about you, Microsoft Communicator and Adobe Connect).

Uniform logistical implementations: If you want teleconferencing, you need to set up a room big enough to hold more than three people. On both ends of the line.

Most daunting of all: Communications Styles. The modern software project team comes equipped not only with geographic and national diversity, but another significant divider: the age/communication divide. This has two parts: 1) are you attempting to communicate transparently to everyone who needs to know everything? and 2) are your attempts working?

Sending the message (are you sending the message?): as a seasoned executive or manager, you will have learned through the school of hard knocks (your career) that you need to be careful about "who is in the room" for certain discussions. This is just a fact. However, after "the room" has made a decision, who needs to know what happened? In a global team, the answer is going to be "a lot more people than you could afford to keep in the dark if you were all under one roof." People who don't know what's going on are going to make mistakes. Overcommunication is needed, not tact, when it comes to keeping a global team aligned. This said,

Receiving the message (did they hear you?) Honestly, this is the one I am more concerned about. As an old person, I can tell you that in general:

Some people read email. Older people. (Like me).

Some people do not read email. Younger people. (Anyone younger than me).

There are exceptions, of course. But do you find yourself on some days to be the Grumpy Old Woman surrounded by people who don't read email? Young people? Do they want you to text them, or record a little video and send it to them? Do you expect about a 10% return on your communications investment when you send an email with more than 140 characters in it? Hyperbole, yes, but I think there is a genuine issue here, and it hugely impacts how well a distributed team can communicate. I could certainly be wrong about the age component to the problem, but on a big, multinational, multi-cultural team, communications styles are going to be even more challenging than they were back in the day.

If you have a global team and it cannot be relied upon to read and internalize the impact of email within some agreed-upon time frame, you have a severe problem. Because if they are not reading email, which, after all, gets sent directly to their own personal email box, and triggers some kind of beep on their smart phone, then you know they are not going to make a regular practice of logging into your sharepoint site to see what the new Program Policies are today. The person who drops a gilded and engraved invitation is unlikely to negotiate three separate "single sign-on" logins and then navigate to some obscure page with a name that has lots of letters and digits in it, with the goal of "reading and understanding" in mind.

What's the solution? Experienced global team wranglers will tell you that the old standby, the "Program Communications Strategy," needs to be dusted off and taken seriously in the spherical world, especially the agile sphere. Who are the players on your program, and what are their communications styles? Name names. Make a spreadsheet, and make sure you understand it. What interconnected web of live meetings during reasonable time zones do you need? What must be expressed in writing? What must be tweeted, perhaps with an embedded link? What must be expressed personally through in-person conversations initiated by an email or tweet to a trusted web of people who are known to be more or less on the same page? Does something have to be expressed in video? How will that video be produced? And so on.

Maybe there's some cost/benefit analysis that needs to be done about the overhead we take on in the "flat" world, and the hidden costs that come from the "savings" of distributed workers. Many agilists have strong views on this point. But if you are a person who can't just wave a wand and collocate everyone in a big barn somewhere, I suggest you just have, say, a meeting to discuss the communications strategy, supported by telepresence, and with someone taking minutes.

About Me

Elena is a Principal Business Architect for ThoughtWorks, London. In this capacity, she focuses on transforming business architecture to better support digitally enabled retail clients. Prior to ThoughtWorks, Elena was a Program Manager and Chief Agilist for the Treasury Services vertical at JPMorgan Chase, followed by projects which measurably improved scalability and productivity in IT processes for the Corporate and Investment Bank (CIB) and the Consumer and Community Bank (CCB). In addition to business architecture, Elena’s areas of professional interest are value chain mapping, change management, and non-annoying IT productivity strategy and measurement tactics.