Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Organizational Culture’ Category

The Jekyll and Hyde manager

with 4 comments

Marty was in the server room, working with the consultant from Guaranteed Uptime, when Rob burst in. “Marty, I want you to go over to Jan’s desk right away,” he said. “She’s having trouble with the CMS again.”

“OK Rob, just as soon as I finish here.”

“No!  You’ll need to go right away. If she doesn’t get looked after she’ll complain direct to Max. Then he’ll raise a stink about how inefficient IT is.” Rob’s tone was such that even the consultant looked up in askance.

Marty had been through this before. “Yeah Rob, give me five minutes. We’re almost done here.”

“You’d better get down there soon,” he said. Then , turning abruptly, he stomped off slamming the door on his way out.

The consultant looked at Marty, eyebrows raised.

“Don’t ask”, said Marty,  and continued with his work.

Less than five minutes later…

“Uh oh,” said Marty sotto voce, as he heard Rob crash in again.

“I thought I told you to go over to Jan. Drop what you’re doing and go…NOW!”

Marty shook his head, and turning to the consultant he said, “I’ll be back in five.” He brushed past Rob and walked out.

                                                                  —

The next day, word of Rob’s tantrum got around within the team. Regardless of the urgency of Jan’s problem, the consensus was that Rob’s behaviour was not acceptable. Yet, everyone knew that nothing would change. Rob had joined the company just under a year ago, and had been anxious to make a mark from day one.  Obviously he’d succeeded, because although his team didn’t think much of him, senior management seemed to have a different view…

                                                                  —

“Hi Max. Everything OK? Anything we can do for you?” asked Rob in a tone of faux sincerity. He’d spied Max entering the IT area and had rushed out to greet him.

“No. It’s all good. You’ve been looking after us very well. Jan mentioned that you sorted out some problems for her double quick yesterday.”  He took Rob aside. “Look,” he said, “you’ve been doing a fine job since you took over. It’s been noticed, and even talked about at the recent board meeting. Well done, and keep it going.”

Max’s words sounded like an endorsement to Rob.  “After all,” he thought, “if management likes what I’m doing, I must be doing a good job.”

                                                                       —

Jekyll and Hyde and managers such as Rob are a fact of corporate life. They are easily recognised by the two faces they present at work – Jekyll to those who they report to and Hyde to those who report to them. Such behaviour enables them to get ahead in the short run but, because they ruin their work relationships in the process, they often lose out in the longer term. 

There is another way, of course. That is to get ahead by doing things right.  The two are not mutually exclusive, regardless of what Jekyll and Hyde managers may think. It is possible to advance and treat everyone, regardless of their position,  with respect and consideration. If done this way, one will advance and also retain the loyalty of those who one may depend on in the future.

Written by K

August 5, 2008 at 6:54 am

Running successful projects – some lessons from strategy execution

with one comment

In a recent Harvard Business Review article entitled The Secrets to Successful Strategy Execution, Gary Neilson, Karla Martin and Elizabeth Powers identify reasons why many companies fail in translating strategy to reality. Their research is based on surveys from over 100,000 employees in more than 1000 organisations worldwide. The article also lists the top five traits of organisations that are effective in executing strategy. When reading these, it occurred to me that the same characteristics are also crucial for successful project execution. Judge for yourself: the attributes, rephrased in project management terms,  are listed and discussed below.

  1. Everyone has a good idea of the decisions and actions for which he or she is responsible: The project manager shouldn’t be the sole decision maker on the team. Many decisions (and follow-on actions) are best made by individual team members, especially when these pertain to their expertise. A smart project manager realises this and delegates specific decision rights and action responsibilities to appropriate persons on the team. Empowering the team in this way removes decision bottlenecks and keeps the project running smoothly. Moreover, delegating real responsibility  demonstrates trust and improves team morale. 
  2. Important information about the project and its environment gets to the project manager quickly:  A project and its environment are dynamic – things change, sometimes from day to day. When changes that affect the project occur, it is important that the project manager is made aware of these as soon as possible.  As an example, a developer realises that an approach he intended to use isn’t going to work. Rather than taking unilateral action  – say, by shoe-horning his efforts into the time allotted – it’s better to let the project manager know  so that both the developer and project manager can come up with a mutually agreed approach.  This is critical because the project manager may be aware of certain things  (like reserve time or resources, for example) that the developer isn’t. If project-related information doesn’t get to the manager quickly, it is inevitable that sub-optimal decisions will be made –  either by the project manager or the team.
  3. Once made, decisions are rarely second guessed: If the project manager has delegated decision rights (as per the first point above), it is imperative that decisions made by team members aren’t second guessed.  Too many project teams spend time reviewing decisions ad nauseum. Don’t do it – once a decision is made, get on with it. Decisions should be revisited only in exceptional circumstances, and only with very good reasons.
  4. Information flows freely across all project interfaces: This is all about communication. Many projects suffer from a lack of open communication between various stakeholders (see my post on obstacles to project communication for more on this).  One of the important functions of a project manager is to ensure smooth communication, both within a team (internal interfaces) and between a team and other stakeholders (external interfaces). Most project managers are conditioned to ensure good communication across external interfaces, especially when the external party is a sponsor! But they often neglect to facilitate  communication between team members. Dysfunctional communication within a team can kill a project, so project managers should continually  watch for signs of intra-team communication problems. Communication, or information flow, is a good segue into the next point which is…
  5. Team members usually have the information they need to understand the impact of their day-to-day choices: Team members are at the coalface of the project. They’re the ones who,  through their day-to-day work,  are making it happen. Seemingly inconsequential decisions made by them can have a large knock on effect on the project. Given this, they should be fully aware of the impact that their choices (and actions thereof) can have on a project. This can happen only if they have all relevant information regarding the project. What’s relevant? That’s up to the project manager to figure out, and communicate to every team member.

Perhaps you’re asking, “Why should traits relevant to effective strategy implementation have anything to do with running projects?” Well, a strategy can be regarded as a set of time-bound objectives together with a plan for implementing them. This makes it a project. So it’s no surprise that traits which improve an organisation’s effectiveness in implementing strategy also make project teams better at executing projects.

Written by K

July 28, 2008 at 7:12 pm

Empowered or not – A litmus test of organisational culture

with 7 comments

In a recent lecture on leadership in software development, Mary Poppendieck relates the well-known parable of the three stone cutters. The story, in short, is as follows. Three stone cutters are asked what they’re doing by a passer-by. The first one answers, “I’m cutting stones”; the second, “I’m earning a living”; and the third, “I’m building a cathedral.” A variant of this tale is related in Ricardo Semler’s best-selling book, Maverick, in which he details how he turned his company, Semco, from a traditional, hierarchical organisation to one in which workers were empowered to make decisions that affected them. In effect, he turned an organisation of stone cutters into one of cathedral builders.

When asked, most senior managers claim that their organisations, like Semler’s, have more cathedral constructors than stone slicers. However, this is their subjective impression which, quite obviously, should be taken with a sprinkle of sodium chloride. What’s needed is an objective test of employee empowerment in organisations. In her lecture, Mary Poppendieck proposes such a test. Here it is:

Question:
What do people in your organisation do when they are annoyed by some aspect of their job?

Possible Answers:
a) They complain about it.
b) They ignore it.
c) They fix it.

(a) corresponds to the stone cutter, (b) the wage earner and (c) the cathedral builder. Poppendieck’s point is that when people are empowered to change aspects of their job that they feel need to be fixed, then it is clear the organisation has pushed decision making down to lowest possible level. This situation is desirable for two reasons:

  1. Decisions get made at the level at which work gets done.
  2. Everyone in the organisation is able to fulfil their full potential

So, now that you’ve taken the test, do people in your organisation (or team) cut stones, earn a living or build cathedrals?

Written by K

July 23, 2008 at 10:38 pm