What’s wrong with software development? Managers, not leaders
Special Note: Recently, I was offered the privilege of speaking with the folks who created and host The Leadership in Tech podcast series. Thank you, Zac and Errol! You are working to improve an industry I care deeply about. Your insights will help not only people working in the industry, but also the customers of the tech industry who rely on the industry to deliver quality, innovative goods and services in a timely and cost-efficient fashion.
I’ll be the first to admit that the definitions of “manager” and “leader” I’m about to use are not official dictionary definitions. I made this distinction, between “managing” and “leading”, during a recent Agile meeting, and I discussed it a little during the episode of Zac and Errol’s The Leadership in Tech on which I had the pleasure to speak.
Let me be clear at the start:
Managing is simple, too simple. Anyone can do it, and too many people think this is best, possibly the only, way to cause a software engineering team to do something.
Here is managing: you tell the team to do something, and you tell them when it is to be completed. The key aspect of managing is that you assign deadlines because you are a manager. It is what makes you a manager, right?
Leading, however, is difficult. I’ll get into it more later.
Here is more about managing a software engineering team:
The manager tells someone: You need to make the DeathStar App destroy Alderon on Tuesday of next week. Easy, right? You can just tell the software engineering team to do something, then wipe your hands of that task. If they don’t do it by Tuesday of next week, it is their fault.
At least two things are missing: communication with stakeholders [customers and engineers], and an honest appraisal of feasibility.
Another thing managers do is delegate. They have read somewhere this is what managers do. But they end up delegating rote chores. Because why would a manager do a rote chore? That’s for engineers to do!
Here’s an example:
Manager: Hey, you know how every week I assemble the OfficeSpace TPS report?
Engineer: Yes? You mean the report of numbers which the team makes up and we all know the numbers are made up, but someone else needs those made up numbers?
Manager: Exactly the OfficeSpace TPS report I’m talking about.
Engineer: Yes, I know the report.
Manager: Here you go! I’m delegating. Now you have ownership of a management task.
Manager: Every employee in the team is supposed to take safety training by Wednesday.
Engineer: Yes. That’s true.
Manager: Make sure they do it.
Managing involves telling someone to do something by a certain day, or delegating work which should not be delegated.
I don’t have statistics, but in my spitball estimates: companies employ far too many managers and not enough leaders.
Managers rule by fear, secrecy, and command, and leaders rule by inspiration, education, and listening.
Let me give you an object lesson in the difference: A person, Person A, is leading a series of planning events to get inputs from the team on when to deploy the software they’re working on and how to do it the best way. It is an arduous but rewarding process, and they are keeping key stakeholders in the loop on impediments and milestones. During the course of discovery, they learn a lot as a team, and key contributors have a voice in what is feasible and what bears risk.
Person B, who has not been participating in the discussions, attends a discussion and blindly says that the team is dragging their feet and, hey, we’ll deploy on Wednesday. It is revealed that Person B doesn’t know the scope, the risks, the installation steps, or the people involved. However, that person feels that managing involves setting a deadline.
Amazingly enough, the Person B approach gets a deadline set, but it does not set a successful deadline. If the team achieves the deadline it is not because Person B set a good deadline or because Person B knew how to lead. Person B is making an uninformed but assertive deadline rather than contribute to the task of organically developing a deployment of sufficient complexity.
As for delegating mandatory chores of value, a leader knows how to inspire a team. A leader understands chores like doing mandatory training on time are something to be encouraged as part of the success of the project. A leader does not appoint a “hall monitor” to harass the team about mandatory training. In a team run by a leader, each engineer feels it is part of his or her individual success, the team’s success, to complete mandatory chores, and that person does those chores because they are as important as an iteration deliverable, not because he or she is being harassed by someone a manager appointed.
A leader knows to push back on reports where numbers are routinely fabricated rather than hand the responsibility off to another person.
In short, a leader only delegates tasks which truly add value to the person he or she is delegating to. It does not help an engineer to be that person who drops by your desk and emails you to complete training. It does not help an engineer to be that person who fabricates numbers for the team. It might free up the manager’s time, but a leader understands when an activity is a waste of time and addresses the issue at the root, rather than giving it to another person.
Obviously, these are not textbook definitions of leading and managing. They rely on one or two distinctions. Yet, I believe the industry would benefit from understanding that our teams require leaders to function capably and effectively, not managers.
Managers are termites gnawing away at our teams, and there are not typically great means of evaluating their performance before they have damaged teams, relationships, and entire projects.
Leaders nourish teams and grow other leaders.
Please share an example of a difference between managers and leaders in the comments below.
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.