A Silicon Valley network storage company faced a brutal life or death challenge.
A competitor was coming out with a new server in six months that had performance and features which would surely obsolete their current product. They had been leapfrogged, and they knew that none of their customers would still be their customers six months down the road unless they had something better or comparable to offer. Although a new product was in the works, their typical product development rollout history was thirteen months from concept to product.
They put a stake in the ground to achieve a five-month development cycle: a mighty goal, but one without a clear plan to succeed. There was a pervasive sense of gloom that the company would surely go under, putting several thousand employees out of work. The company was functionally fragmented into many different departments. The next generation product needed an array of new features to meet the next competitive bar. The construction of these new features, however, could not easily be accomplished without dialog and tradeoffs across the functional boundaries.
They formed twenty-five cross-functional teams composed of hardware and software engineers, sprinkled with a dash of marketing, operations and finance. This approach is not revolutionary. Indeed, cross-functional teams are a common organizational method for getting the right people together to deal with interrelated issues. Each team was charged with building one of the features as part of the new product architecture. On paper, it looked as though they were positioned to take a run at the accelerated schedule—except for one small detail. None of the teams had a member with experience leading this type of team. In fact, the executives in charge admitted they were uncertain that more than a couple of individuals across the entire organization possessed the skills necessary to lead a team successfully.
To achieve engineering milestones in one feature team, there might be trade-offs or choices another team would have to adjust to—or perhaps block, in favor of their own objective. This process is typical of what you would expect to contend with across interdependent teams as they weigh choices and negotiate trade offs in the interests of building the best overall product.
Only two or three of the teams were lucky enough to have seasoned engineers that had run projects before and seemed comfortable with taking on this mantle for their team. The rest of the teams—which did, indeed, have smart young engineers—had that dazed look that suggested they didn’t believe their “leaderless” team would ever pull off their assignment.
To overcome the obvious leadership inadequacy, each team was provided with a ten-point assessment focused on the basic leadership requirements for projects (see figure below). The team members filled it in and took a poll on each item. The average ranges were very low – 1 to 2 points. The dazed look turned into one of gloom. Everyone hunkered down, hoping not to get picked as the team “leader,” the one who would take the blame for failure, the one whose career would receive the black mark. It was time for a re-frame: instead of considering the leadership function as something for which one person must take complete responsibility, each of the ten items was discussed based on who on the team felt they could successfully manage a single aspect of the team leader responsibility. Doors opened and gloom turned to possibility. Very quickly, volunteers emerged who felt they had the skills and interest to manage one, two, or even three items.
For most teams, several people combined their abilities to fill the requirements for the list of ten. The leader was not one, but three or four people. More importantly, there was a confidence that the leader work could get done sufficiently for the team to accomplish its objectives. The mood in the teams almost universally transformed from “down and doubt” to “yes, we-might-just-pull-this-off.” It would have been impossible to train individual leaders to do it all in the compressed time frame. Ironically, the very lack of capable leaders allowed for this unorthodox solution.
Team Assessment
How well do we: |
|
| 1. Define Key Issues | 1 2 3 4 5 |
| 2 Prioritize Key Issues | 1 2 3 4 5 |
| 3. Develop Solutions | 1 2 3 4 5 |
| 4. Decide on Critical Actions | 1 2 3 4 5 |
| 5. Determine Responsibility for Assignments & Action Plans | 1 2 3 4 5 |
| 6. Accept Accountability for Individual Assignments | 1 2 3 4 5 |
| 7. Stay on top of all Team project Variables | 1 2 3 4 5 |
| 8 Maintain Critical Interface Relationships. | 1 2 3 4 5 |
| 9. Build Confidence | 1 2 3 4 5 |
| 10. Build Energy & Momentum | 1 2 3 4 5 |
| OVERALL RATING: | 1 2 3 4 5 |
Despite the newly discovered ability to move forward and handle differences without the delays and hang-ups expected, there remained a pervasive disbelief that the new product could be developed anywhere close to this unrealistic, five-month deadline. While doubt remained, a new culture was emerging within this network. Things were getting done quickly, effectively. Benchmarks and timelines were being met. Engineers talked about how they were solving the technical problems with each other, how they were becoming energized to stay on task and move forward without the usual delays and second-guessing from managers above them. They started talking about how much more they liked being in this organization, how much more effective they were, and how positive they felt about their accomplishments.
Time passed quickly, as it often does when things are clicking. Three-and-a-half months had passed since these teams were formed, and they worked like magic. Not only had they beaten their “unrealistic” goal of five months, they also absolutely destroyed the previous best of thirteen. It was a stay of execution for the company, and a joyous one at that. They would beat the competitors to the marketplace, and more importantly, save all those jobs. It didn’t happen just by tossing people together into teams. Detailing and assigning specific project-coordination roles among the members built the minimum requirements to meet an unthinkable challenge without experienced leaders, without extensive training, and in a climate without much support.