Things I didn’t know about management, before I went into management

aka What Do They Do All Day?

I was talking about software development with some software developers, as one does. And one of those software developers said a thing that I found really interesting:

“Realistically having no hierarchical structure at all is actually the most suitable design pattern.”

This is a great example of the sort of thing I believed about management, before I actually became a manager. I now know it to be absolutely incorrect.

(I also am aware of how self-serving it sounds for a manager to say that, and that it's a long shot to be able to convince anyone who hasn't actually experienced it otherwise; but I'mma give it a try.)

There were a tremendous number of surprises in store for me when I first officially crossed over to the management track -- not least, that it was in fact a full-time job. When I was first asked to take on a job with the word “manager” in the title, I did so under the illusion that I would be able to continue productively coding alongside my managerial duties. That lasted... maybe six months. Two things happened: first off, there just simply wasn't time enough in the day to do both the building and the managing -- there's effectively an infinite supply of tasks available in both piles. And we had other people around who could do the “building” part. Second, I just wasn't being a terribly effective developer, even when I could carve out the time for it: once you're no longer regularly working within a particular codebase, it starts to move on without you. The tasks that I could reasonably take on with my split attention and availability got progressively smaller as time went on, until it became obvious it would make a lot more sense for me to let go of the IDE.

But so let’s go back to that “having no hierarchical structure at all is ideal” thing. Sure, as a manager I’m able to fill my days and then some, but maybe I'm kidding myself: maybe it's all just bureacracy and sitting in on meetings, and I'm at best ineffective or at worst an active hindrance to getting things done. It sure feels that way from the developer’s seat, sometimes. So now that I've played for both teams I'm going to try to list out, first off, why management happens; and then what it’s actually good for.

Management Is Inevitable

Companies are made of people. People have opinions. Opinions differ. Absence of hierarchy can work in an extremely small group; in a teeny tiny startup you may be able to achieve consensus on every significant issue, but at any real scale at all there are inevitably going to be conflicts that must be resolved somehow. For a company to be successful everyone needs to be pulling in at least mostly the same direction. It doesn't even necessarily have to be the best possible direction, but if you're all canceling each other out you're not going to get anywhere.

Even in the total absence of hierarchy, when those conflicts arise, one of two things will happen: it’ll fall apart, or a hierarchy will naturally emerge. And ad hoc hierarchies tend not to be sustainable for long. The leaders that naturally emerge in that sort of situation are often the least suited to leadership, they're too often the ones who talk the loudest or with the most certainty, not the ones with the best understanding of what's really needed or how to get there. For another, stepping up to that leadership position means taking on a buttload of extra work and responsibility; if there isn't some sort of compensation for that, the only ones who'll be willing to take it on are the ones who are in it for the power and status. So, again, the least suitable people.

If you want good leaders you need to treat it as what it is, a job that's distinct from day-to-day engineering, with sufficient rewards (financial or otherwise) to make it worth taking on.

So, fine, we've got a relatively flat hierarchy, now we grow the company a bit more, enough that we need two or three or four teams, more than a single manager or lead can reasonably handle... guess what, someone needs to make sure those teams aren't working in conflict, so guess what, you either end up accidentally letting the least qualified people drive the bus or you officially add a layer to the hierarchy.

Now zoom out a bit more, you've got engineering, you've got a product team, you've got a design team; someone's got to make sure they're working together and communicating with each other and etc. And so on. End result: large scale bureaucracy.

(And yeah, the bigger a company gets, the heavier its bureaucracy gets, and the more they slow down. That's part of the natural lifecycle of companies, and it's why startups can still succeed -- they can move faster at smaller scale while they hope to grow up (or get absorbed in). And all that extra bureaucracy and slowness has a hidden benefit: it acts as an insulator against bad ideas. The costs of a catastrophically bad decision as a startup are relatively small: you just go out of business and try again. In a giant company, a catastrophically bad decision can end up costing millions and millions of dollars or putting thousands of people out of work or, like, reshaping all public discourse if you're named Zuck or Musk... so maybe it's not a bad thing to slow that new idea down long enough to be sure.)

And aaaaaall of this so far is just the "telling people what to do" part, which is arguably the smallest part of what a manager does all day.

A Sampling Of What Managers Do Besides Tell People What To Do, In No Particular Order

Recruiting and internal career development.

You can't just hire people and put them to work, it's not that simple. Senior engineers come in with their own opinions about how to do things, you need to make sure they become aligned with the rest of your codebase and strategy. Most of the time you want to promote from within, and put the people who already know how your code and product works in control of more of it -- this means identifying the good future leaders, encouraging them to grow those skills, finding tasks for them that will let them learn and make mistakes and grow their abilities and knowledge. It also often also means gently dissuading the ambitious but not-suited-for-advancement developers from trying to put themselves in a role that will be harmful to the company, or finding ways to satisfy that ambition more productively. And it means finding training and continued education for everyone at all levels, so they don't stagnate or fall out of date.

Establish processes and structure.

There is so. much. more that goes into creating a software product than just writing the software. How should we organize the work itself? Scrum? Kanban? Something else? What should our code review process look like? How do we ensure code quality? What should our tests look like? How much time should we devote to maintenance vs new feature work? How do we decide what to prioritize and when? What should we document, and to what level of detail? What does our QA process look like? How much of all of this should be left loose now, at this stage of our company's growth, to evolve organically rather than being imposed from above?

Risk management.

What are we going to do if things go wrong? If the proverbial engineer gets hit by a bus, or that server crashes, or that high-value customer starts asking for a lot of custom feature work, or asks us to comply with some new security or legal standard [shakes fist at SOC2], or someone oopsies on the command line in production, how do we recover? How do we prevent those things happening in the first place? Who should have access to this data or that server or the other customer's email address?

Vendor and third-party partnerships.

There are a billion SaaS products out there to help with everything from observability tooling to recruitment and interview processes to static code analysis to data storage to etc etc etc. Which ones are most appropriate for your company at this stage of its lifecycle and budget, or should you be rolling your own? (Sure, you could treat this as a set of specialist roles, and decide which specialists you can find and want to hire -- but be careful; a database specialist whose only context for the rest of the department's work is being the database specialist, are they going to be able to make good decisions about what the people who'll actually be using the database every day will need?)

Cross-departmental advocacy and strategy.

Sales wants a constant stream of new features to sell. Engineering wants to spend the next few months refactoring the garbage code they had to churn out for the last few months' constant stream of new features. Design wants to update the UI across the product line. None of those people are wrong, there are always competing interests, and management within all of those groups and more need to either figure out how to come to consensus or how to define a new hierarchy so someone can make the decision and get us all pulling in the same direction again.

Morale, culture, and personalities.

Employee A needs a lot of handholding but is afraid to ask for help. Employee B has some kind of beef with Employee C that neither of them wants to talk about. Employee D is talented, but not nearly as talented as they think they are. Employee E is low-key racist. Employee F is usually great but is going through a divorce so isn't really focused on getting their sprint done. Employee G just wants to punch the clock until retirement. Employee H is a rockstar in the IDE but has limited English-language skills. Employee I has a grating personality. Employee J doesn't see the value of unit tests, so refuses to write them, and their code keeps breaking in production. Employee K keeps showing up to meetings late or not at all, and even when they do you're petty sure you know the reason their camera is always off. Employee L is bored with what they've been working on and wants to switch to a feature area they don't have any experience in. Employee M keeps trying to shed their workload onto Employee N. Employee O is basically useless and everyone knows it, but their uncle is on the board. Employee P is a complainer. Employee Q has a lot of great ideas but no followthrough. Employee R is quiet, poker-faced, and impossible to get a read on. Employee S puts in the hours and then some, but their code is unreadable. OK, those are your reports, now figure out how to get all those people working together as productively as possible, or decide which ones are unsalvageable and need to be fired (but figure out how to do that in a way that won't freak out the rest of the department). Good luck have fun!

So, yeah, that's some of it. I was sort of aware, when I worked as a developer, that this sort of thing was going on; but the amount of day-to-day energy that has to go into it, and the degree to which that effort shapes the company, really caught me by surprise. All those meetings and memos and directives and decks aren't just for show or to get in the way of the real work. (Even more surprising was seeing from the other side the amount of influence individual non-managers also have on shaping the future -- but that's a whole other story, we'll save that one for later).