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

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

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