My problem is with the absurdist version of the story: the mythical team that is filled with execution issues, poor teamwork, low degree of individual skill, and an enemy with both superior skill and a history of success. In this story, it is one stirring talk from the tough-but-beloved coach that turns the team around. They charge the field and play like a commando team, each overcoming all personal skill issues and all of them meshing into a perfect winning machine.
In the real world, it is unlikely that the problems a technical team faces are motivational in nature. Maybe a team is struggling with technical problems. Maybe they haven't learned to support each other with their efforts and need some training. Maybe they lack the individual skills necessary for them to do a good job. Maybe they are skilled, but bound up in organizational boundaries, official roles, rules, and red tape. Maybe there is a very poor system of rewards and compensation, so that they are punished for doing what is best for the company. Commonly (for programming teams) the years of heroic last-ditch efforts have left the code base a non-performant, convoluted, fragile mess of hacks and band-aids. Maybe they aren't getting access to the Customer that will help them make good decisions.
It is ever-so-possible that most people on most teams in most companies are really dealing with actual problems. It could be that they're not just slacking or slumping, but that they've hit some walls. I have never yet seen a slow build, a performance bug, an intermittent failure, or a sloppy code base that yielded to emotional pressure instead of a breakthrough discovery. I've never seen a team burst through organizational barriers by happy think instead of hammering out working relationships and building a good history of collaboration together one feature at a time.
The problems our teams face are not all in their heads. The least sympathetic, least effective, least meaningful thing we can do when people are facing real technical or organizational problems is to try to prop them up with positive motivational speeches or "motivate" them with threats and insults.
If we want to be effective we must try giving our people the resources, aid, and freedom to solve problems. We have to free up some space for the work they have to do, and understand that there is no meaningful way to estimate the time to discovering a problem you do not yet understand. We have to allow them to experiment, make mistakes, learn, discover. I will not be helpful to a struggling team until I drop the motivation and apply some problem-solving or bring in some useful talent to help with the problems.
If we give in to the desire to give a locker room speech and our team succeeds, we have to resist the urge to claim credit. It is their hard work and skills that made it happen. I've been in the technical side of the software business for 30 years, and offer assurance that technical teams succeed despite these speeches, not because of them.
Contrary stories are welcome.
Contrary stories are welcome.