The title alone should generate imagery ranging from destructive rumors to the macabre. Who are these dead, and who is speaking ill of them? "The dead" are former team members, the ill speakers are those who blame problems on them, and we are taking a critical look at this complaining with just a touch of irony. We are talking about the culture of blaming current problems and challenges on team members who are no long with the team for whatever reason. Almost anyone who has been involved in the software development life cycle has experienced this behavior, and very possibly taken part in it even with the best intentions in mind.
However, what I want to discuss here are the reasons and ramifications of the blame game. I have myself seen teams hampered by this kind of behavior, even in small quantities. By the close of the this discussion I would like to share some tactics I've seen that are effective in preventing and solving this problem behavior that work well for both leaders and individual members of any technical team.
Speaking Ill
First of all, what does this behavior look like and how can you identify it? How can we differentiate this kind of behavior from honest and constructive feedback and ideas that should be encouraged and embraced within any agile team? You may be surprised to find that identification is easier than you might have imagined!
It often starts with frequent complaints to peers and to managers about all of those difficult to follow and fuzzy little bits of code all over a project or system. These complaints quickly become common place jokes or derisive comments about the work of former team members. These complaints and jokes quickly begin to move into team settings such as scrums, team meetings, or working social situations. This progression is where the danger starts; this is where the mindset begins to seep into the culture of the team.
Many years ago I worked with a young developer; we will call him Rich here for our purposes. Rich had several years of experience under his belt, and was a very smart engineer. He had passion and an eagerness to improve things and leave a positive mark on the project. These were all positive traits that I encouraged.
However, I noticed him slipping into the behavior of blaming previous members of the team for issues we currently had with the project. It was clear that while he was very smart, his lack of long term project experience led him to make black and white judgments. I often explained to him that these fuzzy bits of code were often bug fixes or last minute changes to business logic. While they weren't optimal, making those changes had been a business decision at the time.
Often time people don't stop to think that a software project is done because it meets the needs of a business. This means these projects may have different drivers behind them from highly scalable enterprise systems to rapidly developed first to market products. These kinds of drivers will, by their nature, produce differing results depending on the requirements and the amount of resources available. At times folks such as Rich simply didn't realize that the drivers behind the project three years ago may have been different for the company than what was currently driving the project. This eventually led Rich to constantly want to re-factor portions of the code without being able to articulate the benefit.
While positive changes to the code base should be encouraged, when the benefit cannot be articulated this can also be an indicator that the perception of previous work has become negative in a general sense. In general it is always helpful to keep in mind that engineering projects can be very complex with a tremendous number of moving parts and integration points. We should always consider how difficult it is to put ourselves in the shoes of those making decisions or working in years past under differing sets of business priorities and resources.
The Ill Effects
My own experiences have led me to the obvious opinion in this article that the effects of this behavior are not only negative but far more destructive than you might guess. However, how do these manifest themselves within a technology team and what kind of impact does this have on projects and team culture? The overarching problem is that this kind of behavior tends to undermine focused and accountable team structures.
Firstly the general level of paranoia and mistrust in the team is increased. If the work of previous members of the team isn't respected, then very quickly the work of current team members isn't respected either. Team members know that when they leave their work is likely to be attacked and possibly viewed in a negative light, this damages motivation and personal work ethic.
As team members become less interested in the standards of their own work the work of previous members of the team becomes more and more of a crutch for current issues or defects. This then feeds back into the cycle and the willingness to accept this becomes greater and greater. Mistakes should be an accepted part of the culture and well understood, only then can mentoring and process be put in place to ensure they don't happen again.
As with Rich in the above example, the results in his behavior were very clear from his continued attitudes toward previous members of the team. This very quickly led to divisions within the team; personal relationships were quickly affected as the previous members of the team still had friends in the current team. Rich began to blame delays in his deliverables on having to deal with poor code previously written in the project. His requests to re-factor code continued to increase and the justifications for doing so become less and less well defined.
As the negative culture spread to several of his peers, Rich began to feel more justified in his attitudes. While his longer term goals suffered the spreading change in culture validated his desire to effect change. This led to unapproved re-factoring of code in several areas of the project to impress his peers and leave his mark on the project. The results of which were nearly disastrous to the project itself. The time he took in refactoring caused his other deliverables to slip badly.
In addition the areas of code he re-factored were areas for which he didn't understand the requirements well. This led to features and business logic being accidentally dropped from the product and new bugs introduced in areas we weren't planning on changing. This was even harder to detect as those areas hadn't been on the plan for deep testing, which led to overall project slip and impact to the QA portion. This seemingly simple change in Rich's behavior led to a material impact to the project and the business which the rest of the engineering team had to pick up and cover for. This only fed into a cycle that increased the lack of trust amongst the engineers.
Clearing the Air
The core of agile development is about being nimble and building teams which can produce effective results quickly. This requires solid teams built on mutual respect with the kind of work ethic that is created when members of teams trust each other and that must include respect for previous members of the team. Without this, teams can quickly become bogged down in finding fault in previous code with less personal accountability leading to the wide range of potential problems we've discussed above.
Does this mean that innovation and a desire to constantly improve the code base must suffer? That is absolutely not the case at all. It is a primary responsibility of the leadership of any engineering team to promote these ideals with a sense of respect for other peoples work. If there are valid reasons which can be demonstrated and add value to the team or the business then they should be greatly encouraged. But they should be encouraged for those reasons, and not with the idea that the previous work was sub-standard.
Again, the idea that different business drivers result in different projects and different results should be illustrated. If there is any engineer that can look back at the end of a project and not do something different based on what they've learned during the course of that project then they may not be looking hard enough.
However, it isn't just up to the leadership team to promote these values and discourage negative behaviors. It's up to each member of the group to realize how they contribute to the culture of their own team. If they would work in a top notch team and be respected by their peers then they must encourage respect for their coworkers, both past and present.
Rich, whom I've mentioned several times above, kept his behavior up for a little over a year. He cost the company time and money, and cost the team he worked with in numerous ways. In the end, he burned out; unable to keep up with the standard he had forced himself into with his behavior. As the leadership team pushed the group in a more productive direction, he found that he had painted himself into that corner.
The leadership team of any group cannot allow the blame game to get out of hand for even a moment. Every member of a technical team can corrode personal responsibility by speaking ill of the dead so if you hear blame from yourself or others, remember to keep the past in perspective: It's nothing personal.
About the Author
Jonathan Wiggs has been working in the software industry for over 15 years working with the latest technology. He has held roles from being an individual contributor on research and development projects to leading shipping products as a Vice President of Technology and Engineering. Jonathan brings his passionate approach and diverse experience to many companies both large and small. In recent years he has focused on launching technology endeavors at startup companies; and brining his expertise in security, .Net, and database technologies to his writing and his teaching. Currently Jonathan is the Principle Engineer and Architect at Jott Networks Inc. (jott.com). Jonathan can be reached at [email protected] for correspondence or comment.
