For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.
What, exactly, does your boss do for you?
For many years, stretching all the way back to the beginning of time (or so it seems), software developers have writhed under the lash of the software development manager. Managers, it seems, are responsible for all things “wrong” in a software developer's life: the impossible deadlines, the highly-misplaced budgets (plenty of money for buying an enterprise license for a tool that does nothing and that nobody will actually use, but no way, no budget for that training course), the promises made to the Sales folks that couldn't ever be built, and so on. Everywhere we turn, the ills of software development always seem to stem from the universally loathed “boss” who seemingly controls all aspects of the developer's life: what they're working on, when they're working on it, what they get paid to work on it, and even, sometimes, how they do the work. Is there no relief from this madness, this curse, foisted upon us by the clueless gods of corporation?
One company, Zappos, even went so far as to take the radical step of eliminating all corporate hierarchy. This action gathered a lot of attention and press. Roger Hodge, writing in The New Republic, called it “a radical experiment...to end the office workplace as we know it.” Known as “holacracy”, the intent here is simply to cut out the middle management, and let employees make strategic decisions as they see fit, capturing all of those decisions in a centralized application for visibility. What software developer wouldn't love this idea?
As it turned out, lots of them didn't: Zappos' employee turnover rate rose 10 points over the calendar year in which they executed on the holacratic model, as reported by The Atlantic in January of 2016:
holacracy has led to what's being called a Zappos exodus, as 18 percent of the company's staff have taken buyouts in the last 10 months. That takes Zappos' turnover rate for 2015 to 30 percent, which is 10 percentage points above their typical annual attrition rate.
Granted, this is a solitary data point, but elsewhere (Medium, for example, was also a huge proponent of it, and ran into equally disappointing results), holacracy has yielded the same results - tremendous hope and excitement, only to drop the concept within a few years.
What is it, exactly, that management does? Why would its absence suddenly start causing employees to leave or, worse, projects to fail and companies to suffer huge setbacks?
Management Myths
When a rookie manager begins their first management job, they often bring with them a set of myths about management that they've carried around with them while not being a manager - in fact, these myths are so pervasive among the new-manager community, I'd submit that they're myths that most employees have about their management in general. Within these myths - and the debunking that follows - lie the seeds of what it is that a manager actually does, so let's walk through a few of them.
The Myth of Authority
Often, because “the boss” gets to tell their team what to work on, there is a presumption of authority that we assume comes with the title. The thinking goes, “Once I become a manager, I will be able to exercise that authority, and make the kinds of decisions that need to be made, instead of having to do all these stupid things that my manager currently has me doing.” Underlying that myth is a sense of decision-making, that now it's the manager's ability to “call the shots” and tell everybody what to do. And, in particular, when that manager isn't a developer, having them make decisions about which frameworks to use or platforms to adopt just doesn't make sense to anybody. “Once I become the manager,” so the thinking goes, “no longer will I be burdened by the unreasonable demands of others.”
Alas, reality is far, far more complicated than that. It would be easy to simply point out that most managers in turn report to their own manager, and so decisions simply “roll downhill,” as the saying goes. Thus, for real authority, one must be at the top of the management chain. But even then, authority isn't all found at the top - the CEO reports to the Board, and the Board reports to the shareholders. More eloquently, however, it's important to realize that ultimately everybody at the company reports to the customers, because if the customers stop buying the product, the company isn't long for this world regardless of who holds what title.
What's worse, new managers often find that interdependencies against other departments and/or organizations (inside or outside the company) often hem them in far more than anything their management chain could impose. That ridiculous and impossible deadline? Turns out that was imposed by Marketing because if they want to run TV spots, they need to have screen shots a full six months before the spot airs. Why? Who knows - that's what the local TV station told them. The budget for training? Slashed because the company is tight on funds. But the enterprise tool the company could afford? That turned out to be a freebie offered by the vendor as a loss-leader to try to gain a foothold inside the company. Or it was a part of a site license deal done by the parent company so it's free to us. Or so on.
More deeply lies the hidden danger of authority - in addition to having the power to make decisions, so long as it fits within the restrictions imposed by all the interdependencies, you also have the responsibility to own the consequences of that decision. You have the authority to bring that industry “thought leader” in as a consultant on the project, like you always wanted - but now you also have the responsibility to justify that leader's six-digit consulting bill, and the corresponding realization that your budget can't afford bonuses for the team if you do. You can hire your close friend, because she's just amazing at doing this Web stuff - but now you also have to be responsible for firing her if she's not working out. And so on. As the manager, you, more than anything else in the company, are responsible for your employees and their continued ability to draw a paycheck.
The Myth of Control
Frequently, the new manager assumes that they're meant to issue marching orders, and that their team is expected to comply with said orders. That might work in the armed forces, but it definitely doesn't hold much water with the group of highly creative individuals that software development teams are encouraged to be. Think about it - when you had a boss who told you what to do, how often did you leap to it, eagerly and enthusiastically? Certainly, there are those infrequent times when the boss instructs you to do what you wanted to do anyway, but the rest? Bah. You'll do it because the boss told you to, maybe, but as soon as something comes along that provides even the slightest hint of a distraction, you're on it.
Why should this be any different if you're the boss? Particularly in those situations where you weren't promoted up out of the team, they're going to have the same skepticism about “the new boss” as you would. Getting your team to commit to you as a manager takes time and trust.
The Myth of the Trains
Also known as, “My job as a manager is to make sure the trains continue to run on time - that the operation (development, QA, or whatever it is) runs smoothly.” And the corollary to that myth? That the fires that emerge are yours to fight. Any fire that appears is on you to deal with - you're the manager, right? As the US President famously put it, “The buck stops here.” If there's something going wrong within the team, it's your job to straighten it out, eliminate the bottleneck, or remove the obstacle. It's on you, it's your neck, because it's your team.
Except, as new managers often find out, the fires never end. The great quote from the classic movie, Men in Black comes to mind: “There's always an Arquillian Battle Cruiser, or a Corillian Death Ray, or an intergalactic plague that is about to wipe out all life on this miserable little planet, and the only way these people can get on with their happy lives is that they DO NOT KNOW ABOUT IT!” Like the galactic agency knows, the truth of management is there's always a fire waiting.
Management 101
This brings us to the real truth of management, and although it's not a deep or hard truth to grasp, it's a truth that many will spend their entire careers seeking to master, and which will cause many more to choose never to manage. The simple, honest truth of management is that unlike your previous positions as an individual contributor, management is not, and never will be, about you. Management is about your team: making them better, making them smarter, making them shine in front of anybody else, and so on. Your job, in many ways, is to hire the best, give them what they need, and then get the hell out of their way.
“Sure, sure, that's what I'm doing when I'm out there fighting fires,” the new manager tells me. “If I don't get those fires out of their way, they can't do their job.” It's not entirely true - some fires, sure, your team won't have the ability to deal with, but not all fires will be ones that require your presence. As hard as it may be to understand, sometimes the best way to fight a fire is to stand back and do nothing, and let your team do what they are paid to do. Fighting fires is often a signal that the new manager wants to do something, not just stand back and watch. But if the team has the right skills to deal with the issue, then the manager's job is to do exactly that: stand back, watch the team do its thing, and look for ways to help the team do it better next time.
There's a lot more to be said about management - whole forests have been sacrificed to the topic - but it all comes back to the central core issue that management is not about you, it's about your team. Embrace that, and you'll be taking the first steps to becoming a great manager. Or, at least, recognizing a good one when you have one.
