Image: https://commons.wikimedia.org/wiki/File:Sparkler.jpg
When I joined that company and I looked at the caliber of the people around me, I was sure that I had hit the jackpot and that we would deliver stellar results in record time. I knew that the difference between a top performer and the others was huge. Conservative estimates have stated that a star could be three times as productive as others. In the highly specialized and creative work of software, the differential could be even higher, with a factor of six to ten. When I multiplied these factors by the number of superstars around me, the cumulative mathematical results seemed unbeatable. I was not expecting that in less than two years the company would fail on all fronts and cease to exist.At the time I joined the company, many good things were fueling its explosive growth.
• The company already had a growing customer base. For several years, this company had contracted with several pharmaceutical giants to conduct clinical trials. These trials required tracking a lot of data, across many patients, for many years, so it seemed that the existing contracts alone would generate a healthy and steady income.
• The leadership had a good business vision. The nation's baby boomers were getting older and the need for new medications and cost-effective healthcare was on the rise. There was high demand for good software products to automate and support these needs. The company was ready to tap into this potential market by extending its existing relationship with the hospitals, doctors, patients and pharmaceutical companies. The range of potential new products was staggering, from software for holding digital patient files across all care providers to products aimed at automating billing and patient scheduling.
• There was money to spend on the best of everything. Given the potential for growth, the company attracted sizable investment. With this money, it had the means to hire multiple star developers and managers and it tripled in size.
The start
At the beginning, the new team took a look at the existing products and decided that they needed to be rewritten from scratch. These products were old: they exhibited obsolete DOS screens and they were impossible to adapt to new requirements. We had to move to the slicker look of the Windows user interface and we needed to redesign the back-end to scale up to millions of patients and all their data. We wanted to do it in a way that made everything customizable and extensible. In a way, starting fresh made things a lot simpler, because we didn’t need to spend time maintaining the old products or finding ways to integrate with them. We were free to design and implement a brand new system. It was reasonable to expect that in a year we would deliver at least the first scaled-down versions of a couple of products.
The company organized us in several "pizza-size" development teams. Each team had a clear mandate of the software to develop. Everything seemed poised for a success. But this was when things started to go wrong. As time passed, instead of solving the issues and marching towards success, things were deteriorating by the day.
The main issues I observed
Image: https://commons.wikimedia.org/wiki/File:Sokol1924.jpg
1. The stars wasted their energy fighting with the other stars. The fighting was always for the best idea and it didn’t seem to happen for the wrong reasons. People didn’t want to grab more power and they didn't dislike one another. They just wanted to make sure that the best alternative won. It started at the top. The VP of engineering was fighting with the VP of marketing, but I was not too clear what were their issues because I was busy with the technical arguments that were happening at my level. My days were spent going from one design meeting to another, trying to contribute and take sides on the technical choices ahead of us. Should we stay with a relational database or try for an object-oriented database? Should we use CORBA or DCOM to call mini-services remotely? (Mind you, 20 years ago there was no REST protocol invented yet.) The architects were fighting the engineers, the highly paid consultants were fighting the full-time employees, and in general the engineers were fighting each other. It was not unusual to hear a convincing presentation that made a lot of sense, followed by someone else bringing an even better argument for the exact opposite approach. 2. The teams developed unclear boundaries. As the design and development started to progress, many teams took the commendable path of developing their code as shareable components for the other teams to leverage. The problem was, teams started to compete in developing the same shareable components. That made it unclear whose components the other groups should use. One criterion was to adopt the component that was further along the development cycle, but that was changing all the time. After a few attempts to integrate with components that were not mature enough and had bugs, the groups began to take their destiny into their own hands. They decided to create everything internally and ignore the duplication from the other groups. The architects voiced concerns with this approach, which could lead to a serious lack of interoperability later, but the teams continued on their own individual paths. It seemed safer to be self-contained than it was to link your deliverables to another team that would bring you down as well if they failed.
3. We were experiencing slow decision-making. Even though everyone was looking at the same data, different people were arriving at different conclusions. That was making it hard to arrive at decisions that stuck for very long. As a result, either we had to talk and re-talk about the same thing multiple times or we had to escalate to upper management, which was put in the uncomfortable position of having to decide in favor of some stars and against others. Given the fact that it was sometimes hard to judge who was wrong, the decisions were taking awhile. We were a small company but moving no faster than a giant one.
4. The old-timers had a passive-aggressive attitude. Many of the previous employees were unhappy with the influx of new people who were stealing the spotlight. In their opinion, the newcomers exhibited lots of confidence, were treated as celebrities, dismissed the existing products as a shabby legacy, but were not showing yet any real success in return. The old-timers were not entirely hostile, but rather passive and a bit discouraged. At times, their frustrations flared visibly, but they always retreated back to their reserved attitude. They seemed to indicate that if the newcomers were to fail, it would be their own fault.
5. The stars were over-complicating things. The stars were really smart and fast, and they were very much inclined to select the latest glamorous technology. It was not unusual for them to start proposing solutions from software articles that had been published only weeks before. Were these latest frameworks and software tricks really necessary for the nascent first version of our applications? Probably not. But it was difficult to question or discourage the attitude that we wanted to use the best of the bleeding edge. For example, when the superstar of my team decided to go with developing everything as an ActiveX, we expressed some concerns about its inherent complexity and productivity, but we eventually went along with the idea. As a result, we almost ground to a halt before building our first simple screen, because creating a solid ActiveX library proved a lot harder than we anticipated. Demonstrating that simplicity is often best, the only team in the company that was able to deliver something was the one that declared their project as a “lackluster, no-glamour, quick implementation.” This group went ahead with what they knew, put their heads down, stayed away from the noise, and delivered something. Meanwhile, our fancy ActiveX project went nowhere.
6. We started to point fingers at each other. After butting heads so often, some people started to openly attack their perceived enemies. Many, including me, decided to stay in the middle and not take any sides. That is, until one day, in a meeting, I got so influenced by the negative attacks around me that without thinking I joined the mob and did the finger-pointing myself. At the moment, I felt relieved that I was expressing my frustrations more publicly. It was only after the meeting when I realized what I had done. Without thinking much, I had attacked the architects, saying that they should guide us more, despite the fact that I knew that they were working hard to put us on the right track and mediate the conflicts. Some of the ones I attacked were even close friends. How could I have done something like this? I can only explain it as a momentary, irrational, emotional outburst—for a moment it felt good to join the attacks.
7. We were not operating as a cohesive team. While many issues were between teams, our group never gelled internally either. People were not trusting each other or feeling enthusiastic about sticking together. The company made efforts to sponsor team-building events. For example, the entire company went golfing and we had happy hour every Friday at 4:30. But it seemed that we always sought and bonded with the same people, the ones we were already friends with, and we never seemed to engage much with the ones we viewed as rivals. In a way, the team-building efforts polarized us rather than uniting us.
Conclusion
Back to the question of why the company failed: I felt that the main issue was the fact that we didn’t collaborate well, either within or between teams. Having a high density of stars didn’t help. In fact, it might have made things even worse.
There is recent research to support this assessment. Professor Thomas Malone, founding director of MIT Center for Collective Intelligence published a series of interviews about studies he has conducted or participated in. The studies found that cohesive groups have a collective intelligence that has relatively little to do with individual intelligence. What matters most is how well people collaborate. When a few members dominate the group, don’t listen well, and don’t share criticism constructively, then the team IQ tanks. Professor Malone indicated that one solution is to increase the proportion of women in the team.
This is not to say that having stars is a bad thing. After all, eliminating stars would deny a company the extraordinary multiplicative power of a super-performer. But it’s clear that focusing on the number of stars alone is not going to bring the results one might hope.
Various solutions have been proposed. Some think that it is better to grow a star by grooming internal talent rather than snatching outside stars. Others suggest there are three keys to team success:
- Treat your best people like a shared asset rather than the property of a particular unit.
- Create incentives that discourage infighting while rewarding team success.
- Have the people who are responsible for the execution own the recruiting and be constantly on the lookout for talent that fits the anticipated needs.
Maybe you have an answer to this question. What would you do if you had to power to decide?
