Home » Change Management » Want Project Quality? Use the “B” Team

We have a big project. Critical to the company. So we put our best people and project management tools on it: The “A” team. Funny, we always seem to get the same results. If our company is not doing well, our “A” team still results in us not doing well. Often, I attribute this kind of consistent pattern to a cultural or major organizational issue that needs to be resolved.

This organization or cultural issue is usually centered on a specific set of people. This set of people will often be our “A” team. If over a period of time our “A” team has been infected with folks that look and sound good, but can’t seem to cause the company to perform, it might be time to let the “B” team have a shot at it.

Let me provide a few examples.

The Client Has No Server

The "B" Team?  Might already be outperforming your "A" team.

We had two teams. The primary team, the “A” team, was to take a purchased software client and embed it in the product. This was to be the premier product and was already committed to by a customer. The second team, the “B” team, was a bunch of contractors, who we had worked with before, and who had provided a super low bid on working on a second client software package. This one was in fact our own client software developed by another part of the organization.

The “A” team worked through the process as we always had. High visibility. Lots of explanations for why things were hard and not always working well. The development process was a review each day of the “panics” in the software. It was development by solving successive failures in the code. Long, painful, late and typical of the organization as a whole. The customer, probably due to contractual reasons, “accepted” the late product and then only bought the minimum amount.

The “B” team was in a lurch. They didn’t have access to the server that the client on the product was going to access. This was their fault in bidding for something they didn’t have nailed down. It was our fault for accepting the bid when they didn’t have all the pieces in place. It was, however, a typical risk one takes on accepting that the contractor can put all the pieces in place. But boy, were they cheap.

The “B” team project went for a long time without the ability to test the client software in a live environment. The “B” team poured over the specs for the client/server protocol and wrote many “simulators” and otherwise inserted “messages” into the client to test it.

Finally, we could do no more. We needed to test with a real server. We relocated the team literally around the world and co-located them with our server team (why we didn’t just do this from the beginning is a good question — but it was one of those problems that would be fixed “next week — we promise.”). It took us about 24 hours to set up everything and get everyone connected. We then finally flipped the switch to see what happened. First try — nothing seemed to work. OK, double check configuration and settings, make some changes. This went on for a few hours. Suddenly, messages started to flow. It was working. It worked. The “B” team development manager sighed out-loud (in a heavy Russian accent) “There was no magic. It worked as we expected it to work!”

The “B” team took a lot of heat for not doing it the way the “A” team did it. The most humorous event was when the product team was livid that the “B” team didn’t know how to use our specialized tools to debug panics in the product. How could they not know something that was so important and so essential to the development process? It was humorous because the “B” team didn’t have all the panics that the “A” team did. They spent their time looking at the specs and the code to see that things were going right. They ended up not needing to run these specialized debuggers on the product because their software wasn’t constantly panicking.

The company eventually shipped millions of products with the “B” team’s solution in it. The “A” team’s software just faded away from non-inclusion in any further product.

The Low End Product

The "B" Team?  They may be the silver bullet you've been looking for.

We were to take two existing products and add the same new key feature to each of them. It was a feature that allowed the products to access the Internet about 10 times faster. The “A” product team took the high end product and the “B” product team took the low end version of the product.

I got pulled in to help the “B” product team when they lost their project manager. I spent about three days talking to everyone on the team. It was a well managed product but with one outstanding issue. The software defects reported in the product were being fixed about three times slower than a typical product (21 days on average versus seven days for a prime product). The defects were getting consistently fixed, just not quickly. The “B” team said it was a challenge to keep the development teams actively working on their product. However, in one meeting that included the test, account and product teams, I heard an amazing comment: “If these are all the problems this product has, we are in great shape.” I never heard that before or since in this company.

What happened? The “A” team’s product was never very successful. It was just another low volume product we had in our line-up. The “B” team’s product? First off, we already had a world class killer product on the market that changed how the world looked at these kind of products. It sold like crazy. We then had all of our other products. They looked like little blips next to the world class product. Well, the “B” team’s product never took the world by storm, but it was the 2nd best selling product after our world class product. It stayed that way for a long time.

The “A” team did all the normal things. It was a highly assertive team that generated lots of noise and got lots of attention. Everything that was “wrong” with the product was always because of something the development teams did not do right. The same development teams worked on the “B” team’s product (as best they could). They were not challenged and driven constantly by the “B” team. They did not spent all their meeting times with dueling power point slides showing what they did and defending against product team claims.

Lessons Learned

In both the above cases, several things stand out:

  1. The “B” product teams were populated by folks that the organization did not see as their best people. They were good people but not folks we put on your most visible products.
  2. The “B” teams did not follow the typical processes. They usually had to beg, borrow and steal the time and resources they needed to move their products forward. They were happy when someone worked on their product or gave them resources. They also didn’t have much “pull” at forcing folks to work more or harder on their products.
  3. The “B” team products were distinguished by high quality when compared directly with the “A” team products. Their schedule performance was as good or better than the “A” team products.
  4. The “B” team products sold better and lasted longer than the “A” team products.

We could look at these examples as just luck or otherwise not typical. However, if we think of the “B” teams as similar to a skunk-works or other low visibility efforts, then we might get a hint at why they are often successful. As long as the folks doing the work are motivated and good at what they do, then I think we will find similar results. In this case it was a Fortune 50 company who had attracted a lot of good people. The “A” versus “B” team was often a personality or perception based division where certain folks had succeeded in convincing the organization that they were the ones to rely upon for success. The major ability of the “A” teams, it would seem, was to grab key products and to make lots of noise. It was not the case that they performed better when objectively compared to the “B” teams.

For more see Problems? Your Best People Are The Root Cause

Take a second look at your “B” teams. They might be the silver bullets you need now.

See related: Seven Ways to Make That Silver Bullet Work

Thank you for sharing!

10 thoughts on “Want Project Quality? Use the “B” Team

  1. Alex Keenan says:

    I have worked in IT for decades. You will find that many in IT do not have great people skills. What I have found is that perception is key with how people view the abilities of a person in IT. Those who can sell themselves and have confidence tend to generate greater confidence about their abilities in others. There are a number of studies that prove this. Also, key projects get the attention, so people who work on key projects also get the attention. This all has been known for decades, but few appreciate its impact. A great example it a good programmer who does not generate problems may never be recognized because things work well so they go unnoticed. Another group has top firefighters that constantly put out fires. The firefighters get the rewards and attention.

  2. Bruce Benson says:

    Wall Street Journal, Feb 27-28, 2009
    “Ford’s Renaissance Man” Alan Mulally

    “Mr. Mulally has overhauled the often-contentious culture in Ford’s executive suite. Most of his appointees are company veterans, but they’re the sort of people who typically got overlooked when style seemed to count more than substance ….”

    Mr. Mulally appears to be making use of his “B” team to make a difference.

    Every team needs to be balanced and not too much of any one style of personality.

    I once decided I could make better “black powder” by putting in more potassium nitrate than was normally called for. I figured it was the real reason black powder was explosive – not the charcoal or sulfur. I tested the new mixture out (with a match) and nothing happened – not even a small poof. That experience drove home the notion that the right combination makes a big difference. I came to learn that this applied to teams as well.

  3. Akshat says:

    Thanks for the wonderful article.

    I would appreciate the likeliness of the B model working successfully. But, it takes a lot of courage for a manager to rely on team B and to avoid any issues. On the other hand, Team A might not be doing anything wonderful until “D-day – 1” , BUT you know, you can sleep peacefully, as they would turn it around and make you look good in front of your customer on the ultimate day.

    But, I still like the concept of team B, for the simple reason, this seems to be the easiest way to accumulate more Team As.


    1. Bruce Benson says:


      The context of the article is when a company is not doing well – which means their “A” teams are not doing well – to then take a good look at their “B” teams.

      If you are doing OK, and the “A” team is pulling things together as they should, then you may still find gems in your “B” teams, but certainly keep your “A” team on your critical efforts.

      Thanks for the comment.


  4. Pingback: pliggvote.com

Comments are closed.