Team
Continuing on with Chris williams old old doc, this section is all about:
Team
The caliber of the team was often called out by the interviewees as a key success factor. While this is relatively obvious, the signs of a problem in this area are less so.
No shipping experience among the senior team leaders
Shipping software, especially here at Microsoft, is a complicated art. It requires a combination of skills and experience that are fundamentally impossible to attain elsewhere. The skills range from technical to political, and the experience can range from the smallest products to major releases. But there is no replacement for people who’ve lived through it.
If the team does not have people who have shipped software here at Microsoft in at least half of the key positions (development manager, test manager, group program manager, user education manager, and/or product or business unit manager), they are likely to have a very difficult time.
Lack of technical skills to produce the product
This is rarely a problem here, since we tend to be so technologically focused, but an obvious source of problems is a team that does not have, or has lost, the technologists to produce the product. Key warning signs include black box technologies (“we don’t want to change that code, no one knows how it works”) or overly sensitive technologies (“we’ll do anything to avoid touching that code, it’s very delicate”).
No owners
Each core technology should have an individual who can always be turned to in that area. They should “own” the technology or feature, and their ownership should be well known by the whole team, and all dependents.
They don’t have to be a lead or manager, they are often just a star member of the team who understands the details and communicates them well. They usually feel a strong vested interest in its success, and are often the cheerleader and staunchest supporter of at least the feature, often the product as a whole. They wear the label as “the person to go to” on any issue relating to that area.
Inadequate staffing
An obvious warning sign of the health of a team is open or inadequate headcount in key areas. A team with key positions (the business/product unit manager, development manager, test manager, group program manager, or UE manager) left unfilled for a long period of time will find it impossible to set and maintain direction. A team with more than one of these roles unfilled, even for a short period of time, is in jeopardy.
A team with no testers, or even one with substantially fewer testers than developers, is likely to have a difficult time producing a quality product. A team with developers writing specs as their key job, or with program managers writing code as theirs, is understaffed or misdirected in a serious way. Even a team with a high percentage of temporaries (greater than 20%) is putting a great deal of the intellectual horsepower in a volatile resource. All of these require reallocation of resources to succeed.
Hostages
Much like a team without key people, a team where the key contributors want to leave, but are being held against their will, is destined for disaster. It’s often better to just admit the problem and let them go, at least they won’t drag the rest of the team down into their bad morale pit.
