by joshstrange | 2025-08-01 12:23:33+00:00
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.