Signs of Trouble

At one point or another, you will find that a team is struggling to deliver. The most frequent signs of trouble in my experience are:

1. A rejection of every proposal as too complicated. The struggling team will reject every proposed enhancement or change as too complicated. Every small change will be associated with a disproportionate man month estimate. In general, one must trust the estimates returned by the team specialized in each layer and task. However, estimates that don’t make sense are an indication that the corresponding team have lost the handle on their product.
2. A reluctance to provide time estimates. Time estimates are always given with a grain of salt. Every engineer worth his salt will provide one. It may be optimistic, pessimistic or on the money but a confident engineer will give an estimate. A struggling team may refuse to give an estimate even if it is understood that the estimate is a loose one.
3. An overly protective lead. Bad habits, like good ones, require gentle handling to blossom. An overly protective lead may overly protect his team in bad times leading to a loss in accountability and openness.
4. A defensive attitude. An us against them mentality and a refusal to accept just criticism are hallmarks of struggling teams that are in denial. Defensiveness of this kind goes against the healthy ethos of information sharing and open discussion. It may be needed when interacting with other companies (although, even there, a more balanced approach works better), but it is poison to improvement when applied in-house.
5. Turnovers. When a team is struggling, the good and nimble players will scramble away first. Some good stubborn apples may remain but the core strength of the team will be weakened.
6. Finger pointing. This is the ugliest red flag. I recall working on a project where the team could not deliver a firmware update and constantly had bugs in their system. The team finally identified one of the junior engineers and blamed him for checking in code without properly notifying the team members. The guy may have done a mistake but he was most likely trying to compensate for the chronic failures around him. Ten years later, the scapegoat is leading a firmware team and his prior bosses have been laid off or have left the company.