Nearly every developer who has been plying their trade for more than a year or two has a version of the same story. They are tasked to refactor, repurpose, or extend, some piece of code and discover it is a horrific mess. It’s poorly factored, the names are indecipherable, it’s entirely undocumented. This code was written by a fool – it’s likely that the author struggles to feed themselves. It’s a shock that they made it through five hours of coding interviews without injuring themselves in confusion, let alone demonstrating sufficient prowess at their craft to secure gainful employment. The clear first step in this project, before even attempting to dig in, is to figure out what fiend is responsible for this travesty. If not so that they can explain themselves, then so that they can be locked in the pillory and be made an example of. Yes, the first step of this journey is to git blame to discover that the criminal responsible for this affront against code and nature was… me?
This is typically the moment that engineers begin building empathy for the authors of the existing codebase. We learn that not all bad code is the result of stupidity, but rather, that a combination of factors conspire to make the code look worse when we come back to it than it did when it was first committed to source control. First is the fact that code is just as hard to read as it is to write. The process of writing code starts by filling your brain with an enormous amount of context. You study the problem space, you look up algorithms, you trace through the control flow, you carefully design and whiteboard and refactor and think through the solution to the problem, and only then do you begin to create something new. Reading the code requires all of that same context. One of the hallmarks of a senior engineer is an understanding of this phenomena. By having empathy for their past self, they can also exhibit empathy for their future self, by not just capturing the code being written, but also capturing the relevant context, comments, documentation, designs, decisions and resources to make it easy to rebuild the mental state that allows the code to be understood and altered.
We also learn that code is often not bad, just misused. Chances are, the reason you are reworking old code in the first place is that it is being used outside of the application or parameters it was designed for. This might have been because the requirements were poorly understood, or because the code was misused, or because requirements change over time. Design choices that made sense for one cohort of customers are nonsensical for others, or the script that was meant to process a thousand records as a one-off hack, is now the lynchpin of a pipeline that cranks through gigabytes of data per day.
I bring all of this up – that we initially treat poorly understood code as the product of stupidity because as a manager, there is a similar phenomena, but it is even less forgiving. When you make a decision, or take an action as a manager, you will not even be given the benefit of the doubt that perhaps you were foolish or uninformed. The default assumption is that poorly understood managerial decisions are actively malicious.
There are a bunch of factors that lead to this assumption. If it is not obvious why a change is being made, a natural answer is “because it benefits someone” and if that someone is not me, then it must be to the benefit of the person requiring the change. There is also a natural tendency for folks to be suspicious of those who wield power and managers have the power to take actions that will impact the careers and lives of their teams. Lastly, we live in a climate of general distrust in institutions, and corporate management is yet another institution that warrants distrust. It is incredibly easy to find real examples of genuine bad behavior in the news or through social media, and significantly harder to find case studies of good behavior, even if the latter is hopefully much more common in practice.
Still, at least in my experience, managers are not trying to screw everyone over at the expense of their team and the company as a whole. When I have encountered confusion or hostility in response to the choices I’ve made as a manager, inevitably there is a difference in assumptions, or a breakdown in communication. It is a sign that I’ve been working off a different understanding of the world than the members of my team, and the solution is to bring the relevant context and provide a clear explanation of why changes are happening that can take the place of the story of managerial malice.
Even better is to set the context ahead of time. Before you even start talking to folks about the details of a re-org or change in strategy, or reprioritization of a project, you should be outlining the problem that needs to be solved. If you want to reorganize so that teams are more closely aligned to the code that they own, start by beating the drum about bugs that fall between the cracks because of poor ownership. If you want to bring two teams together, start by highlighting the overhead (extra meetings, conflict in code reviews, lack of clear ownership, etc…) of them operating separately. If you outline the problem well enough, a good solution will feel like an obvious step forwards rather than a mysterious whim. The google keyword here is “Change Management”.
I’ve seen organizations that have tried to solve this problem by telling everyone to simply “assume good intent.” This is ultimately doomed to failure, because it is demanding trust rather than providing the transparency required to earn it. Successfully managing and communicating change is a tool for creating an organization where everyone can assume good intent.
Going back to the analogy from the start, just as an engineer learns empathy for their peers and their future self, and learns to over communicate the context of their work to make it easy to understand and build on top of, a good manager needs that same empathy for those who will be consuming their work. Doing this not only allows those impacted to understand why things are happening, but it empowers them to contribute to solving the problem.
Imagine you are instituting a new policy to limit how many defects a team can keep open month to month. Be clear about what the problem is. Maybe it’s that the endless pile of defects in your ticket tracking system means that low value bugs get fixed, while the ones that cause the most impact carry forward month after month. Your hope is that the new process will let you focus on the biggest issues without distraction. Share that context with your team. Highlight the issues that you want to see less of. Not only will the organization resent the new process less, but they might find additional ways to improve the situation outside of the process you’ve created. If you don’t share the real motivations for your changes, your team will try to work backwards to discover why this change is happening, and you might not like the conclusion they come to. Maybe they decide that you were just looking for a metric to superficially improve to look good to your superiors, and provide a similarly superficial response to your request.
It can be a bit distressing to think that people on your team will, by default, assume malice in your work. Don’t take it personally – it is a natural part of human behavior to gravitate to stories and build narratives. If you leave the story unclear, you should expect others to fill in the blanks in ways you did not intend. Instead, provide an explanation and your own narrative, so that it is not left to others to define why you do the things you do. Over time, as you act in a transparent and consistent fashion, you might see that the stories people tell about your decisions become more accurate, but until you’ve built that foundation over time, it’s best to assume that all decisions made by management will be considered malicious until proven otherwise.
Leave a Reply