What’s wrong with software development? Promoting the knowledge hoarder
I take issue with the criteria to become a manager in many, not all, shops I’ve worked for. It represents a flaw in the industry which should be addressed.
In an ideal world, when I join a team, I would find that management is skilled at facilitating the success of the members of the team. They’d be gifted communicators whose interest and focus is on listening carefully and course correcting regularly, clearly communicating their vision in a fair and proactive way. They’d genuinely want everyone on their team to succeed, and they’d recognize that tools, documents, meetings, and means of communication need to be fine tuned for the team regularly and even tuned as granularly as the individual in the team in some cases. They’d recognize bottlenecks to success and work as managers to resolve them as their first priority.
This is the kind of team lead I am. I’ve had employees cry when I was replaced by a cheaper resource as team lead. I still have a lot to learn, and I regularly fail to do the things I set out to do, but I try. This is my credo when I am a team lead.
However, this, by and large, is not the state of the industry I have encountered in my 20+ years of experience.
Rather, in far too many cases, I see individual contributors being promoted to manager due to their hard work and their technical knowledge. In my heart, I know those people feel they earned a promotion. They worked hard. They excelled. Why shouldn’t they be managers?
The fact is that we as an industry put too much value and, yet, not enough value on the meaning of being a manager.
I would suggest we do what companies like GE have done, and we as an industry make a track for people not interested in learning or executing management finesse — individuals who are very skilled in learning and mastering new tech. I’d have a track of systems architects and chief engineers lined up for these folks, with equal weighting to the manager role, but with one caveat: the individuals must have a proven track record of mentoring others and sharing knowledge.
We value the name “manager”. We value the responsibility it represents. A manager should be able, no matter the tech stack, to move from job to job simply based on being able to lead a team. In the real world,yes, tech stack can get in the way of a job interview if the person is totally unaware.
What we don’t value are the qualities I laid out above. Many of my managers have been completely reactive. They sit back, doing tasks which are required of them, are probably highly bureaucratic in nature, and then, when a problem occurs, BOOOM! They are quick to tell the team member what he or she should have done. To give a non-technical example, I am going to the grocery store, and I buy the wrong type of mouthwash. When I get home, the manager tells me: you should have checked your to do list! I know that. This is not management. If you raise concerns to this manager, he might try to help, but he should be where the hockey puck is going to be, not where it was — to borrow a Gretzky aphorism.
The true meaning of being a manager is not the title or the authority to hire and fire, but the ability to manage a team of diverse individuals to a collective success. I find it odd, just to throw it out there at this point, that managers are seldom reviewed by their subordinates. In fact, in many work cultures, me reporting the problems of a manager to his or her superior would be seen as an improper escalation.
The worst case situation, of course, and the inevitable one of the way our industry promotes managers [or hires them from other companies] is that some people will do anything to become a manager.
This means knowledge hoarding.
Knowledge hoarding, or the practice of strategically keeping knowledge secret so that other people cannot effectively do their jobs, is corrosive to a team, but it does one thing — it keeps the hoarder vital to the team. Who hasn’t been on a team with someone who performed a critical function — I mean a life-saving day-in-and-day-out sacrificial task of utmost importance — but, when called on to explain what he or she did, could not find the time? I mean: how can you find the time if you’re always fighting fires? And management: do they force this person to share knowledge? Of course not. Doing so would cause the knowledge hoarder to threaten to quit, which would dismantle the enterprise.
After many years of being indispensable [a term our industry should say is a bad quality, not a good one], the knowledge hoarder is in a great place to be promoted.
The irony is that this corrosive force is the very last person an organization should promote to management.
However, our merit-based system, based mainly on technical knowledge and individual contribution, is the very system which qualified that person for management.
A good manager, and I blush to say this, should be able to manage without understanding the specifics of the tech stack.
This person should have a fundamental working knowledge of how software systems work, of course, and should be an intense listener — willing to discern good explanations from team members from bad ones — but he should be first and foremost a manager, not a tech person. I say this as someone with considerable technical knowledge.
It is bewildering to me how our industry can make the same mistake year to year, company to company, team to team. Even if, best case, you get an earnest but poor management-skilled individual as manager because that person knows the tech stack in and out, that is not a satisfactory outcome for our industry and our craft.
The inevitable end of this method of promotion into the ranks of management is, of course, to promote knowledge hoarders.
This, to me, seems like it should be as obvious to companies as would be offensive to companies.
Sadly, it is not.
Thanks for reading! When I see applause for a piece of mine, I want to write more pieces! Please applaud if you appreciate people writing about topics like this.
If you enjoyed this piece, you might consider reading some of the other stories I wrote for this series. Thanks!
Disclaimer: I am a senior software professional with experience as project lead, team lead, and lead engineer in the greater Boston area. I am actively seeking a job while currently fully employed. The world of software development can be an ugly place, and I hope to expose some of the more bewildering and uncomfortable corners in the hopes of improving the industry and the craft. Out of respect for current and former employers, I will keep the names of employers and/or clients scrubbed and anonymized as best as possible in these reports.