The Imperative of Removing Rotten Fruits and Vegetables

October 28, 2009 – 7:18 am

Ever bought a bag of potatoes at the store, brought them home, then in a few days find one bad potato in it?  Experience teaches you that you have to get it out of there quickly- not only because of the smell and the mess, but because it seems that the rot always spreads- soon the whole bag of potatoes are ruined if you don’t get the rotten one out quickly.

Project and Operational teams work like this.  I think we’ve all experienced a “bad apple” on a team.  Dealing with the one person who, for whatever reason, is doing a bad job, invariably seems to drag everyone down.  Your best performers will vary as to why they get worse at what they do- resentment over everyone not pulling their own weight, frustration at obvious incompetence, impatience with poor communication skills… the list goes on and on, but it always happens.  Not only does the poor performer not do well, but they drag down the team.

This is not just random observation, although it’s likely many of us have seen it, but it’s shown up in research.  Here’s an interview from This American Life Of Will Felps.  Felps is a researcher and professor at the Rotterdam School of Management.  His experiments with inserting bad apples into work teams showed that not only did bad apples damage work teams, within 45 minutes other team members would begin to take on the characteristics of the bad apple.  Everyone on the team’s work would degrade.

Another effect of a bad apple is that their presence is often seen as a challenge to your leadership.  Your failure to do something about bad performers reduces both the trust and respect of the rest of your team in you.  I’ve heard this said to me and of my colleagues more than once in my career: “If you/mangement/whoever can’t see that (insert bad apple here) is wrecking this project, you/they are an idiot.  If everyone else can see it, why can’t you/them?  If you can, why don’t you fix it?”  Or, here’s the worst one of all:  ”If you/they don’t care that (bad apple) is wrecking the project, then obviously you don’t care.  Why should I?”

I’m not saying can everyone who does a bad job on something, but the one thing you must do is take action quickly. Correct the behavior if you can; if you can’t, get that person off the team they’re screwing up and get them on to something else- either in your company or not, but get them out of there.  Too many times companies sit on their poor performers.  I myself have been guilty of this before.  The instinct is to give people a fair chance, but ‘fair chance’ does not get the job done.  Action does.  Take action to rehabilitate or remove your bad apples.  Don’t drop the performance of your entire team.

Like this post? Buy me a cup of coffee.

Popularity: 2% [?]

  • del.icio.us
  • Digg
  • Add to favorites
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • PDF
  • Twitter

Seeing Through Transparency

October 26, 2009 – 7:30 am

Transparency is one of the great industry buzzes to build out of the collaboration movement.  People talk and talk about becoming transparent to their partners, their clients, their cousin Phil… you get the idea.  It’s a good movement; transparency promotes information sharing, and information sharing leads to better decisions… or does it?

Transparency can be a double-edged sword.  There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos.  Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean.  The team that looks under control sometimes is not, and vice versa.

This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software.  A good friend of mine refers to this process as “making the sausage”.  Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.

So if transparency is so dangerous, why is everyone doing it?  Why shouldn’t we run from it?  Why aren’t projects falling apart all over the business world globally because of it?  The truth is that some are.  Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it.  if you use it incorrectly, it will hinder rather than help.

Transparency lends value in two important ways:  it spreads useful information, and it builds trust between groups.  There are two key words there:  useful information, and trust.  These are actually very easy to apply here if you think about it:  information people do not understand is not useful.  People do not trust things that they do not understand.  Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.

Drawing from this, we can apply a set of simple do’s and don’t’s to Transparency to make it work better:

  • Do share anything that is a roadblock.  Never let people get surprised when your team runs into trouble.
  • Do summarize wherever possible.  Keep things in terms that all teams understand.  Ditch jargon.
  • Do be prepared to explain details, especially related to roadblocks.
  • Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
  • Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session.  Respect people’s limits in how much data that they can take on a time.  If you bury people in information, they’ll miss the important parts you share.  Make sure the most important details are always at the top.
  • Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it.  A lot of people are problem-solvers in the business world.  That’s what we all do.  If you get too much detail in front of them related to a problem, they will want to dig into it.  This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration.  On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them.  This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
  • Do not make shared decisions in a vacuum unless you have no choice.  Once you open things up, you hurt trust when you start leaving people out.

There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust.  Follow your instincts around building Trust and respecting people’s time.

Like this post? Buy me a cup of coffee.

Popularity: 2% [?]

  • del.icio.us
  • Digg
  • Add to favorites
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • PDF
  • Twitter

How much sausage making do you want to see?

May 4, 2009 – 7:12 am

My company’s CTO has a saying about building software.  He says that it’s a lot like making sausage.  There’s a level of detail you want to know in order to be happy with it- are you using quality ingredients, when will I get the finished product,  is the facility clean… and then there’s a level you definitely do not want to know if you don’t want to feel ill or ever intend to eat sausage again.  My grandfather owned a slaughter house; trust me, he’s right.

Something my company has been struggling with for years has been how much detail is enough for project reporting.  This has been even more complicated by the founding of our PMO.  Here’s a few of the issues you run into when the business folks look too deep into the project details:

  • Reporting overhead:  the deeper you look, the more effort is put into telling others what’s going on by the managers who are supposed to be spending time getting things done.  If you pull away too much of their time, the project actually starts to fall behind- because you so busy looking at it that you monitor it to death.  At some point, you have to trust the project workers to handle the details that they gloss over in meetings.
  • Knowledge transfer overhead:  this goes in part with reporting overhead.  The deeper a detail you look at, the more explanation goes along with it.  This is especially true in the IT world.  Some tasks and problems require a very in-depth technical knowledge to understand.  The deeper you look into them, the more background information and technical detail that has to go along with it.  All of that communication overhead pulls people away from the real work.  They are talking about doing rather than doing.
  • Executive attention syndrome:  if the reporting goes deep enough down the rabbit hole on every project, your company’s leaders soon find themselves spending all their time drinking from the information firehose and not enough time actually leading.
Of course, I’m not advocating lack of communication as an answer.  Projects need to be monitored.  Executives need to be informed to make decisions.  Sharing of knowledge is good for people and helps develop both your employees and, more importantly, trust among your employees in each others’ skills.  The rub is in finding the right balance.
Here are a few things you can do as reality checks for your projects:
  • If one of your projects seems to be having more status meetings, reports, or level of detail than the other successful projects, be suspicious.  Do you need the level of monitoring you have in place?
  • If you are regularly breaking off into explanations of technology in your status meetings, you may be looking too hard.  Status meetings should be making sure you are in the right track.  Knowledge transfers are part of the natural workflow of requirements gathering and design.
  • If your managers driving your projects are, consistently among the team, struggling with getting assignments to their teams, updates back from their teams, etc, you might have a problem.  The process of delegating and receiving feedback is a small part of the overall job- if they don’t have time for that, something is amiss- and it could be your project.
What other problems do people see as a result of this?  How are folks dealing with it?  What warning signs do you see?

Like this post? Buy me a cup of coffee.

Popularity: unranked [?]

  • del.icio.us
  • Digg
  • Add to favorites
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • PDF
  • Twitter
FAQ | Membership Guidelines | Privacy Policy | Copyright | Stacey Neal Douglas (author/owner)