It’s so easy to blame your manager or management staff when things are going wrong. But if you subscribe to the belief that people are honestly trying to do a good job and that generally, they are capable of doing so, you must then ask, “What can cause a team with good management to go bad?” When teams suffer from major cultural problems and under-performance, they may not be suffering from bad managers. They may be suffering from something I call “managerial debt”.
If you are from the world of software development, you have probably heard of the term “technical debt”. In simple terms, it is the code in your software that is “ugly but works.” It needs to be cleaned up, but doing so is hard to justify when there is no additional feature set being delivered to your end customer. It is created when engineers are slammed in trying to meet deadlines, such as when they are bringing a product to market, and instead of coding everything perfectly, which will take more time than they have, they ship the functioning-but-ugly code instead. They always want to come back, and if they are fortunate, they can from time to time. Or eventually there is a huge overhaul needed to clean up the technical debt they borrowed when they scrambled to meet the last five deadlines.
I’m a manager. I’ve managed or worked on tons of software projects, big and small, with a variety of disciplines, such as Embedded and Software Engineers, Artists, Technical Artists, UI Developers, Network Engineers, Quality Assurance, etc… Those projects have been in a wide variety of industries such as gaming, automotive, mobile, beverage, industrial, theme parks, and my own ventures. After having joined many projects where things have gone awry, I now can usually see when managerial debt exists. It’s exciting to me, because it means I can make a difference.
When you consider technical debt, you may not even see the impact of it in the end product, if you are lucky. However, you see it as clear as day when watching a software team struggle to add features to that product. There are “TO DO: (fix this)” statements everywhere in the code, paragraph sized comments explaining some weird decision in this chunk of code, and people complaining in the hallways about how they broke something completely unrelated in their code by making a minor change in a separate file. The whole balance of the product’s stability comes into question, when changes are mired in technical debt. “Don’t touch it, man, it works,” is a phrase I recall hearing many times over the years. And often the previous engineers who built the code are blamed for the debt in the first place.
In the same fashion, there were several times where I joined a team as a manager, and I was told by team members, “you must get rid of those guys, they are terrible at ________.” Or “_______ really didn’t know what he was doing with the project.” Or “ ________ didn’t care enough about us to do ________.” Often times when a manager leaves a project, complaints will come out of the woodwork on what they did wrong. I have seen it as well with individual contributors (engineers, artists, etc…) but as a manager, I am often sensitive to hearing those statements when I join a team. Whether it is out of concern for what they will say about me when I leave the project or because I am effectively being trained by the complainers on the new team in hopes that I will run the team in a way they think it ought to be run, I am still concerned by comments like that.
Even still, I learn a ton when I join a new team, because I always ask what the problems are. I came across a particularly large team in recent years, where things simply felt “off the rails.” And as the new guy, I tried to ensure I respected the culture of the team by learning why and how they had gotten into such rough shape. (This is also the same recommendation I make to junior engineers who complain about bad code when they join a new team, by the way.) The team was not self-regulating. Feature owners didn’t own their feature sets. Development teams did not care if they missed deadlines. The culture was rife with politics and finger-pointing. Ramp-up procedures for new hires did not exist. Meetings slid into meetings which slid even further into other meetings. The same was true for feature development sliding on an on without end.
Through a variety of conversations with other leaders (technical, managerial, art, etc…), I was able to piece together how the team had gotten into this territory. Over time, several managers on the team had either been cherry-picked onto other teams or had left. They had not been replaced, resulting in the few managers that had stayed, having to increase their work hours significantly to manage the workload. Slowly, oversight, such as planning meetings, product demos, team review meetings, had gone neglected or faded out of existence. Career management efforts like one-on-ones, hiring efforts, ramp-up and employee training efforts had done the same.
People would then vent or imply to me that the remaining managers were incompetent or simply did not care about them as individuals or as a team. I had the fortune of having the history of the management team’s depletion explained to me. I also learned of regularly changing direction from upper management on where the product was headed. It became pretty clear to me that the managers who had stayed and carried the load were actually quite competent and diligent people. They pulled tons of overtime but had come to the point where they knew some things were just going to get dropped. They simply couldn’t handle the workload, and no replacement requisitions were being opened to backfill the managers who left. i.e. they could not convince upper management to hire another manager to get them some help.
One day it hit me that the managers who stayed were carrying mountains, and they literally had no time left to address all those things they needed to address in order to keep the train on the rails. They were exhausted. And most importantly, they were so mired in daily grind of work, they could not rise high enough above the team to solve the large categorical problems needed to help the team get back to a healthy culture with good ramp-ups, good self checks, self-guidance, a sense of ownership, among many other things. To return to the debt metaphor, they were so busy paying the weekly bills, that they couldn’t pay the monthly ones. They couldn’t work on fixing the team. They could only work on fixing the day to day problems. The most important ones. The squeaky wheels. The fire fights.
If you are on a software team, you can quickly spot the technical debt. Just ask someone. They may laugh and jestingly tell you about system X that needs major repair. If you are on a development team, you can’t ask about managerial debt, because it is not obvious. It is soaked into the culture. It is behind the scenes. It is also taboo to discuss where management is suffering or failing. This is because people expect that either their managers should have all the answers, or conversely that their managers are incompetent. It rarely occurs to people who have not managed in the past, that perhaps there is just not enough manpower on the management staff to go around. Ironically on one team suffering from managerial debt, I had one person tell me we had too much management. In the same meeting he proclaimed he didn’t know how to use project management tools because no one had trained him. This was quintessential to me for this concept, because he didn’t realize that the very thing he needed, training in this case, was neglected by the management staff on his team, because they were swamped with other project issues. The fires the managers were fighting had been caused by him and other feature owners not owning their workload, which included embracing the project management tools they were given. It was quite a complicated web of problems that intertwined, but the lack of managerial manpower that existed as much as a year earlier had let the team slide deeper and deeper into a quagmire of confusion around responsibilities and tons of blame by leaders pointed at each other for failing do their jobs.
Managerial debt is most obvious to you when you see a team that is off the rails. When you see politics, major failures to communicate and failures to stay directed along a path, an overall lack of clarity as to what it is you are even doing, and many more issues, you are more than likely looking at managerial debt. When you get the sense that your manager or management is working hard and yet they seem a bit incompetent, this could very well be due to a lack of manpower at the leadership level to keep things guided as planned. The next time you are in this situation, instead of assuming that your manager is incompetent (which sometimes they may admittedly very well be), first look around and watch the team from a wider perspective. See if there are way too many developers and not enough managers to go around. (A good rule of thumb, is one manager for 5 to 7 people. You can potentially stretch that to 10 in some cases, but going past that starts your team down the path of debt accumulation.) You might find your manager is trying to be a hero instead of asking for help. They might be too embarrassed to ask for help. They might have asked for help and been denied the budget. If you are a leader, and you are helping a subordinate manager bring a team back from the brink of disaster, you might also consider where managerial debt needs to be paid here. If you have just joined a team as a manager, be respectful of the manager who just left, as it may not be clear yet whether they had debt to clean up too.
In order to pay technical debt, engineers either fix a little code here and there as they have time, or they perform a large, painful overhaul of the code. I recall one consulting team even did the overhaul “on the sly”, as they could not convince the customer it was worth doing. The result was an incredibly more stable product and much more maintainable code base in a product that is now shipping in the millions. Although the customer never knew it, they paid less in the long run due to this team consciously paying their technical debt.
In order to pay managerial debt, you can do the same thing. You may have to sell hard to get upper management to bankroll another manager or assistant, but it will be better for the neglected team, if you can get one. So sell it. As a leader, you can delegate day to day grind items, such as basic project management, meeting notes, follow-ups, etc… If you can’t get a full-fledged team mate who is qualified enough to take over a portion of your team, then a junior manager can take those delegated tasks as an opportunity to prove their metal.
Delegating the grind tasks well will free up some of your time to work on cultural damage that has come as a result of the managerial debt. For example, if your team does not hold itself accountable to deliver features they committed to at the beginning of a development period, that can be “job one” on your cultural improvements list. Whereas it was something you had to just accept while you fire-fought other problems, a little of your extra bandwidth there can go a long way to not only making the team more self-managing, but also strengthening the culture into one with a real sense of ownership. And when the team owns its own success, that will in turn mean less debt accumulation for you to manage later. I won’t go into details on how to solve cultural problems for your teams in this article, but that is one example so you can see how to apply practical solutions to your managerial debt situation.
A technique you can use in selling upper management on this additional headcount is to list for them what you would share or delegate and how that would benefit the team (reduced attrition, more business value for the customer, on-time deliveries, on budget deliveries, etc…). Alternatively, if you can’t get the additional help, you will have to push more of the leadership work to leads on you team. It’s more than likely something you should be doing anyway, but the debt clean up will go more slowly. And lastly, you can work on ways to replicate yourself. Training videos on common tools and establishing a pattern of having the new hires document what they wish someone had told them when they started are cheap techniques you can use to chip away at that managerial debt.
Debt, no matter where it comes from, financial, technical, or managerial, is still debt. It’s still ugly, and it still hurts your company. And it may not be any one manager’s fault. If you have recently taken over a team and you lull yourself into believing that the previous manager was just incompetent or not as good at management as you are, you might very be leaving that team sometime later, wondering why your techniques didn’t work any better. Look for why the debt exists first, then plan on how to clean it up. It is cultural and it will often take time to drive buy-in with your team. But as a leader of any team, it is just as much your responsibility to clean up managerial debt (and minimize its growth) as it as the responsibility of good engineers to clean up and restrict the growth of technical debt in their code.
Have you seen the side effects of managerial debt on your teams? How did you solve the problem?