So you're a manager now

Sort of in the same vein as "you don't need to understand gravity to recognize that it's important," you not understanding what the answer is doesn't mean there isn't an answer and that the answer isn't important.

I don't have "the answer" (I have _an_ answer, see below), and I also don't need to know "the answer" in order to understand that the managerial class doesn't exist for shits and giggles. There's value there.

If Bezos thought getting rid of managers at Amazon would make him another half a billion dollars, you bet your ass he'd do it.

My answer? It's exactly what that group of seniorish people would do: make decisions. But the seniorish people can't make decisions all day and ALSO do the things they're senior at. You may not like that answer -- and you don't have to! -- but "making decisions" is something that needs to get done at scale without sacrificing the actual productive work that ICs do.

But again, I think you're asking a great question, and I think there's room to say "Is the current paradigm the best paradigm?" and explore other alternatives.

But the very clear answer from all research in addition to basic intuition is "As far as we know, yes."

Why? Doesn't really matter. We just know that if we didn't have managers, the world as we know it wouldn't exist. (For better or for worse!)

> You don't have enough clout to make organizational-level changes. So process things that you see that are really inefficient, and you have some ideas how to address them? Now you've got to convince your manager and probably theirs, too, and they usually don't want to rock the boat.

As long as you are a go-to person, you have more clout than you realize. Spend your social capital while you have it and make changes. Also, making change requires allies but they don’t necessarily have to be in your direct chain of command. Lastly, to make a change in an org, just change. People will follow. Most people are not leaders, but you are. Act like it and you will see that you command far more respect than you think you do.

> But what goes on in those meetings, in your experience?

It's all over the map, but here are some examples

- Weekly planning meeting with higher-ups to discuss what their priorities are for the next few weeks

- Weekly Product Status meeting to discuss what the teams accomplished over the last week, any blockers, etc

- Standups, for a while I was running them for (and managing) 3 different teams

- Meetings with design to go over mockups and point out issues before they reach the team ("That's not possible with our current data", "that is an expensive lookup currently", etc). Let them know what is/isn't possible (or rather, isn't possible without a bunch of work, almost everything is "possible" if you have unlimited time)

- (every other week) Process improvement meeting to go over changes we might want to make to the (growing) company, re-evaluate processes we have in place, etc.

- Weekly demo meetings, though developers are in this

- Twice a week architecture meetings, though developers are in this, discuss problems we need to solve and how we want to solve them. Equal parts "present an idea to the team" and "I have a hard problem, help!"

- Monthly check-ins with my direct reports

- Weekly Planning meetings with the team, though developers are in this

- One-off meetings with individuals or small groups to discuss a plan for a feature/bug/etc (so with some developers but not all)

- PR meetings, some PRs benefit from being on a video call with the developer so they can explain their reasoning/code/etc. Sometimes it's due to the size/complexity of the PR, sometimes it's due to the person who wrote the code (who might need more guidance than others, I don't advertise this)

- Solo PR "meetings", if I don't block the time out, my schedule will fill up

- One-off meetings with business about urgent issue or new ideas they've had

- Interviews, this is temporary but currently every free minute of my day is scheduled to talk with potential new employees

- One-off meetings to help a developer with something they don't understand or need help solving. This is rarely visible to the rest of the team as I don't advertise "Johnny needed my help yesterday"

- Production issues. I'm not sure how common this is or if your manager does this but I get tapped for the vast majority of production issues due to my familiarity with the code (and having written parts or at least worked with most of it).

- HR-type meetings, to discuss an employee. These are, thankfully, rare but when it does happen there are normally multiple over a week or two

- PIP-type meetings, another things I, obviously, don't advertise. When I need to meet regularly to talk with an employee about their performance

Not listed here is the "prep time" for these meetings. Some require little/no prep but others I'm expected to present info in and so I need to collect/organize it so I'm ready to go. Things like "ticket/backlog refinement" fall into this category as well. Sure I just have a 1hr planning meeting per team but sometimes it takes me that long or longer to go through things business wants worked on, fleshing them out, asking them questions to clarify, etc.

None of this is to say "Your manager's meetings are all legit", I have no way of knowing that. Just like I have no way of knowing how my experience lines up with other people in, ostensibly, the same role. "Manager" can mean a bunch of different things.

One small thing I'll tack on, sometimes I don't share the subject/contents of meetings because I know it will be depressing/distracting/unhelpful. I don't share every whim of the business side of the company or every bug mentioned because it's not what we are currently working on and it will be a distraction. Also, sometimes I have multiple meetings in which I'm pushing back/"fighting against" a proposed path forward. There is no reason to let the rest of the team know about that since it will only anger or distract them.

I'd argue it's not my job to "shield the team". It's my job to enable the team to question "dumb shit" and put them in a position where they can discuss these matters constructively with management (or whomever).

Also - I "deal" with underperformers because my team needs to deal with them. It all comes back to "what benefits the team".

I see that there are a lot of different varieties of agile coaches out there.

Article author here, that's a great point. I've got a followup post coming soon about performance management (both high and low performers), but you're absolutely right, hiring and firing is such a critical part of management that also (usually) doesn't come with any training whatsoever. Great ideas for some more follow up posts, thank you!