Comment by 9rx
5 days ago
> I'm not even sure I would call my experience "management" except companies kept naming it that.
What is a manager anyway? I've been in this industry for multiple decades and I honestly still have no clue. They are never willing to assert what they are working on, or what blockers they have, during standups. They aren't striking deals with clients. They aren't building the product. They demonstrate no visible function. What, exactly, are they doing behind the scenes?
That's not to imply they aren't doing anything. I just can't figure out what it is and I'd love to know more. The article says "Learn from them.", but I have never seen anything to learn from. It is all shrouded in mystery.
I fully understand this viewpoint having been on both sides. Here are some examples:
- Creating tickets. It’s very easy to scoff at this, but it’s much harder than you might expect. Business gives vague or unclear request and you have to translate that into tickets that your team can actually work on. Even when business creates their own tickets, you have to review them fix the mistakes in the assumptions that they’ve made or figure out how we will implement what they’re asking for.
- Answering questions. Either via Slack or by jumping on a video call, this can eat up a huge portion of the day. You have to do a decent amount of handwaving in the descriptions of tickets, which means sometimes you’ve missed something or you just haven’t been clear enough. It can often feel like being more clear in the ticket leads to almost work than just doing the ticket yourself.
- PRs. Reviewing code can be incredibly difficult. Making sure you load up the full problem space in your head and are sure that the code you’re reviewing won’t break something that the developer isn’t aware of. Depending on how good your QA is at the company, this might be all or most of the review code gets before being released. That makes it very stressful. It’s also painful to have to go back and ask a developer to completely rewrite something or change their approach because they’ve misunderstood the ticket. Even more painful when you’re on a deadline. This can lead to either you wanting to just fix the code yourself or merge it as is hoping that you can clean it up later.
- Meetings. “How hard is it to sit in a meeting?”, it’s a valid question. But often you are ask to present updates on the work your team is doing and ask questions completely out of left field about future work, ongoing projects, etc. These fill up your calendar quickly if you’re not careful and leave little time for future planning so you feel like you’re always sliding into homebase on Friday.
- Releases. Of course this depends heavily on what your release cycle looks like. However, the longer your release cycle is the more painful this can be. If you have a good chunk of work sitting waiting to be released it stresses not only the team, but also the manager and makes it difficult to have a feature leapfrog all of that work and get released earlier because a client needs it NOW. This is especially true when you have no direct control over the release process. Being asked multiple times or about multiple things “when will that be done/fixed?” And knowing it’s sitting there just waiting to be released is frustrating.
- Interrupts. It can be very frustrating to have a plan be executing on it and then have business come in and change all the priorities. Maybe it’s just for a day or maybe it’s drop that project completely and go work on something else. This is stressful, especially if part of the project has already been committed and you either need to back it out or find a way to hide that work (from the released product) until you can get back to it.
- Performance review. Even for high performers this takes time but for people who aren’t pulling their weight, this sucks. As a manager, I think it’s common to feel like you failed them in some way, you haven’t been giving enough advice along the way, or nudging them in the right direction but when you finally have time to take a breath and think about their performance, you realize it’s not up to snuff. Having hard conversations earlier helps, but it’s much easier said than done.
- Sprint Planning. On top of all of this, every one to two weeks you need to have enough work ready for the team to work on for the next sprint. This of course gets much more difficult if business isn’t even sure what their priorities are until a day or two before you have to plan.
- Development. It’s not uncommon to have the manager also expected to write code. Finding uninterruptible time blocks can get very difficult. Switching between writing code, PR-ing, it and sometimes acting as QA is rough.
I’ve rambled for long enough, so I’ll stop here. None of this is to say manager’s jobs are harder or anything like that just trying to point out some of the things they work on. Also, everything I wrote above won’t apply to every manager. It’s a massive spectrum.
Last thing I’ll say is that a lot of managers try to be the “pain sponge” for the team. Not all managers do this, but often hiding the frustration or the work they’re doing is done to shield the team from it. Not to mention a manager isn’t always going to advertise some of the things they’re doing “Well Johnny’s PR took forever because he messed up a bunch of stuff”, “I had multiple meetings this week to discuss letting Johnny go”, “I had to hold Johnny’s hand for two hours the other day to help solve a problem”, etc.
As always, YMMV, not all managers are the same, not all managers are asked to do the same things. This is just what I’ve been responsible for.
Interesting stuff! I wouldn't say a lot of it applies to my personal experience — much of it sounds more like what I do — but understood that no two organizations (or people) are alike.
> Meetings.
This seems to be where all of their time is spent as best as I can tell as an onlooker. But what goes on in those meetings, in your experience? "I worked on meeting with Mary to deal with X so that we could Y. No blockers." doesn't make it to standup, strangely enough. Which is sad as that is the only information I'd want to know about from a standup! I already know about what the developers are doing. Their work is highly visible.
I don't mean to imply that there is no reason for those meetings, or that they are somehow easy, but I'd love to know what it is all about. One part just because I'm plain curious, one part because I wonder what information isn't making it back to me that would improve the ability to do my job, and one part because I want to know if is something I'd want to take more involvement in.
> 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.