It was a sunny Wednesday afternoon. The day was June 2nd, 2010. To some, just another sunny afternoon in Detroit. To others, a day of infamy, the historic day that never was. But to all, an incredible display of leadership, grace, and accountability.
Armando Galarraga, of the Detroit Tigers, was facing the Cleveland Indians in a Major League baseball matchup of Central Division rivals. The first twenty six Cleveland batters had failed to reach first base. Armando Galarraga was one out away from making history. Twenty pitchers had thrown perfect games in the history of the baseball. He could become the twenty first. All he needed to do was retire Cleveland batter Jason Donald. However, his perfect game came up short when first base umpire Jim Joyce incorrectly ruled Jason Donald safe at first base. Yet another bid for history foiled by human error.
While the pitching performance was stellar, it was the post-game performance that was the most noteworthy. Jim Joyce immediately sought out Armando Galarraga after the game and apologized for the mistake. He took full responsibility for the error. His immediate display of accountability quickly diffused a tense situation, and was a classy move made by a person who had just foiled another's shot at the history books. Armando Galarraga's display of sportsmanship and maturity was equally impressive. He acknowledged that nobody is perfect and that mistakes happen, but didn't attempt to cast blame for his failed attempt at history.
While history wasn't made on that warm day in June, a leadership lesson was learned thru example. Though a mistake was made, both the umpire and the pitcher took full accountability for their actions. As a result, they both established a greater level of respect and trust for each other, and also garnered significantly increased levels of respect from those who witnessed the event.
As a software engineering leader, the success of your team will also be the measure of your success. Your ability to get your team to perform is reflection on your ability to lead. There are a couple of accountability rules to keep in mind as you chart you team's direction.
Alvin was the manager that every developer wants. He was knowledgeable about technology, he was pragmatic, and he always held himself accountable for his team's performance.
Once his team was working on a high profile project with a tight schedule. A few weeks from the scheduled release date, his team realized that they’d forgotten to account for a critical use case. Implementation of this use case was required for the release. When the team brought this issue to Alvin, he remained calm. While this was a significant setback to the release, he never sought to pass blame. Instead, he took ownership of the issue and rallied his team around a solution. Those responsible for the oversight felt really bad about it, but Alvin shifted the focus from blame to a solution. In the end, the team was able to rally around a solution, and while it did delay the release by a week, Alvin gained a significant amount of respect from his team.
By showing that he 'had their back', his team went to great lengths to make sure they were successful. Had Alvin been inclined to start passing around blame, he would have lost the respect of his team, and ruined their morale. By keeping everyone focused on a solution, and holding himself personally accountable for the oversight (even though it wasn’t his fault at all), he kept the entire team feeling good about what they’d accomplished to this point. This allowed them to focus and deliver a solution quickly and minimize the impact to the release schedule.