In Defense of Second Chances

Suppose a project fails to deliver as expected. I don’t disband the team that worked on it; I have the same team members work the project to fix the problems. No one else knows more about the project, has more motivation to fix the problems, or has more at stake regarding their reputations than the people on that team. — Chuck Kozak

Chuck Kozak was my boss from 1998 to 2002. His people were devoted — one colleague even suggested we were the “Cult of Chuck”. He was complicated, however — he had a temper, held onto first impressions, and wanted his “enemy” to be viewed as the enemy of everyone on his team. He gave us company shirts with the phrase “March or Die” — a not-so-subtle message that he expected us to overcome adversity and successfully complete our assignments. He was also smart, generous, gave praise freely, and let us know that he genuinely liked us.

So how could this demanding and complicated, but loveable, person come to the realization that second chances are a good idea? He observed the power of practice. Chuck worked in Information Technology all his career — from the mid-seventies to 2007 (when he died of pancreatic cancer). In that time, he oversaw, dozens of software implementations. He also noticed that teams who worked on tough implementations were often scapegoated for the difficulties and banished to lesser projects. A new team would take over only to have a steep learning curve, less interest in an already negatively viewed project, and limited experience with new teammates. Often the second team failed again — however, a second failure was not typically attributed to the team members in the same way as the first failure. Why? Company leadership believed they hired great people (and arguably they did). They also believed that their managers were competent (also largely true). So, if a project failed twice, the idea that the people were again the problem ran counter to core beliefs.

Chuck also believed in people — so much that he reasoned that the first team was probably not made up of incompetent people, but rather people who needed to learn. Further, he realized that members of the first team wanted to redeem themselves and had useful information that went untapped if the team was made a pariah. Hence, Chuck believed in second chances.

What evidence is there that he was right?

✔ First software implementations are notoriously complicated (Cockburn & Highsmith, 2001). People require feedback, as in a failed first attempt, to learn complex tasks — score one for Chuck.

✔ Second, by believing in his people, Chuck displayed key elements of transformational leadership (Bass, 1999), particularly intellectual stimulation and individual consideration, in which leaders assign teams difficult problems and act as a coach. Transformational leadership is associated with high performing work teams — score two for Chuck.

✔ Third, he expected that we would learn, or, in the words of Dr. Carol Dweck, we would maintain a growth mindset (Dweck, 2016). Avoiding or giving up on a difficult task was not an option; he believed we would get the job done and we did — score three for Chuck.

How can other leaders apply these lessons when faced with team failures? Consider the following questions when deciding how to respond:

· Is it likely that the people on the team are competent? If people are competent prior to a failure, consider how elements of the task and situation contributed to the failure.

· Is it likely that the task and/or situation was complicated? If it is complicated, the first attempt probably yielded important learning.

· Does the organization/unit need to develop people who learn from mistakes? If so, then allowing the same people to fix a project failure is likely to be a good idea.

Of course, teams may not be given a second chance when an external client refuses or when team interpersonal dysfunction is determined to be the cause of failure. However, in the cases where teams are competent, generally communicate well, and have learned while attempting a difficult task (Hackman, 2011), they should be given the opportunity to realize success for themselves and the organization.

References

Bass, B. M. (1999). Two decades of research and development in transformational leadership. European journal of work and organizational psychology, 8(1), 9–32.

Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11), 131–133.

Dweck, C. (2014). Talent: How companies can profit from a” growth mindset”. Harvard Business Review, 92(11), 7.

Hackman, J. R. (2011). Collaborative intelligence: Using teams to solve hard problems. Berrett-Koehler Publishers.

Michelle Brodke is a consultant and educator at Bowling Green State University.