5 ms·

At my company you can see other people's calendars by default so I can easily know what anybody on a manager-schedule is doing unless they opt out of sharing.

At my company you can see other people's calendars by default so I can easily know what anybody on a manager-schedule is doing unless they opt out of sharing. I am not sure why people think it is bullshit. 1:1s, cross-team meetings, project planning, sitting in on various engineering-driven meetings (e.g. "What should we do about this problem that popped up?" "How should staffing work for this new project?"), hiring, and other managerial odds and ends (your report has a question/needs XYZ) amount to a large amount of work for a larger team. I am not a manger, but I go to many of these meetings. A lot of these recurring cross-team meetings are phenomenal wastes of time - most people don't say anything, other people only talk maybe 5% of the time or less, really only 2-4 people talk a lot. Many "process" meetings, like whatever agile/scrum/story/retro bullshit are also filler. However everything else is IMO kind of necessary, and I'd say it is real work. People won't manage themselves, projects won't plan themselves and align them with people's needs or career plans, and fundamentally a tree structure is usually a much more efficient way for info to be communicated than an ad-hoc peer to peer structure (no, maybe not for the more senior people, but if you have worked with junior people, you know what I'm talking about) - we're talking O(n) compared to a pessimal O(n^2). People can and should still communicate peer-to-peer anyway, but it makes sense for mangers to take on as much of the overhead as necessary. The problem with the OP is they have found a way to somehow stuff their calendar with the worst kinds of meetings - random webinars, "status updates", and jira jockeying.

feoren 5y ago
Why do people think it's bullshit? I'll give it a shot: "1:1s" - time-filling waste at best, a chance to micromanage at worst. If individual contributors need this much help all the time, they should have a technical mentor. Mentorship doesn't come in weekly 1 hour increments, either. "Cross-team meetings" - Most likely, people from within the teams should be talking to each other when they have questions for each other. Why the telephone game with managers? "Project planning" - In software development, project planning is mostly fiction anyway. Way too much project planning all over the place. You're exploring a vast uncharted territory; stop planning and start exploring. "Sitting in on various engineering-driven meetings" - the "sitting in" has given it away. That's all they're doing. Sitting. "What should we do about this problem that popped up?" - get an engineer working on it now if it's super important; put it in the backlog otherwise. Why is some manager who barely touches the code trying to tell me how to solve the problem? Your advice is useless, just let me fix the damn thing. "How should staffing work for this new project?" - The same way staffing works generally? I'm confused. Get some engineers on it. Preferably smart ones. Preferably ones that aren't already overloaded. > A lot of these recurring cross-team meetings are phenomenal wastes of time. Yup. > People won't manage themselves They will if you let them. > Projects won't plan themselves Your plan is wrong anyway. > we're talking O(n) compared to a pessimal O(n^2) Peer-to-peer is only O(n^2) if everyone is spamming their conversations in a group channel. It's just about maximally efficient if everyone knows exactly who to ask for their specific problem.
- BigRedDog1669 5y ago
  I agree with some of what you say, a lot of big meanings could be compressed to emails. But I think you are really simplifying a lot. "1-1s": If they are used to micromanage they aren't 1-1s anymore. There are a lot of politics in a medium to large sized software org that can be difficult to manage. How do you get ahold of a person in another team you rely on but isn't responding? How to juggle contradictory requests. How to get better in some area? How to prioritize/manage time? The answers to these can be hard to intuit, especially for a new team member and might need to be discussed as issues pop up and can be very context specific. Staffing: When resources are clearly defined and a person is working on one project for a clearly defined amount of time it is simple. But often times there are new hires, people leave, someone might be switched projects, projects might get delayed, etc. There are actual trade-offs to consider here. They probably don't require a weekly meeting, but you are doing a lot of hand-waving. People managing - People can manage themselves for things that they are incentivized to do (normal project work for example), but if it is unclear what the priority is or if something is necessary, they won't do it. Many times there were "team initiatives" to improve code quality or testing and they never went anywhere because there wasn't appropriate time allocated to do it and there were project priorities. Same with asking people on other teams to do something for integration or to fix a blocking bug, often times they wouldn't respond or delay many times and it would be necessary to talk to management. I feel like a lot of your points are assuming everything is constant and things are running perfectly. But in any software organization things are constantly changing
- dgb23 5y ago
  Your post comes off as a bit arrogant to be honest, but I think you are essentially right. The most convincing argument is this: > > People won't manage themselves > They will if you let them. I feel like this is kind of the root of it all. You also mentioned mentorship. Maybe more experienced workers should consult, teach, mentor others to help everyone to become more autonomous, rather than "managing" them. And yes, that means it's people who know how to do the work, have done it in the past and hopefully will do it still. There is value in having people who make high level, strategic decisions, and those typically don't need this kind of level of expertise, but should rather trust their experts. But that's usually not what we mean with "management". You see I strongly believe in autonomy, which is why I have decided for myself to not have managers/bosses anymore. Just clients and colleagues for the time being. There are environments which are deliberately focusing on and enabling autonomy, which is very attractive.

feoren 5y ago

Why do people think it's bullshit? I'll give it a shot: "1:1s" - time-filling waste at best, a chance to micromanage at worst. If individual contributors need this much help all the time, they should have a technical mentor. Mentorship doesn't come in weekly 1 hour increments, either. "Cross-team meetings" - Most likely, people from within the teams should be talking to each other when they have questions for each other. Why the telephone game with managers? "Project planning" - In software development, project planning is mostly fiction anyway. Way too much project planning all over the place. You're exploring a vast uncharted territory; stop planning and start exploring. "Sitting in on various engineering-driven meetings" - the "sitting in" has given it away. That's all they're doing. Sitting. "What should we do about this problem that popped up?" - get an engineer working on it now if it's super important; put it in the backlog otherwise. Why is some manager who barely touches the code trying to tell me how to solve the problem? Your advice is useless, just let me fix the damn thing. "How should staffing work for this new project?" - The same way staffing works generally? I'm confused. Get some engineers on it. Preferably smart ones. Preferably ones that aren't already overloaded. > A lot of these recurring cross-team meetings are phenomenal wastes of time. Yup. > People won't manage themselves They will if you let them. > Projects won't plan themselves Your plan is wrong anyway. > we're talking O(n) compared to a pessimal O(n^2) Peer-to-peer is only O(n^2) if everyone is spamming their conversations in a group channel. It's just about maximally efficient if everyone knows exactly who to ask for their specific problem.

BigRedDog1669 5y ago
I agree with some of what you say, a lot of big meanings could be compressed to emails. But I think you are really simplifying a lot. "1-1s": If they are used to micromanage they aren't 1-1s anymore. There are a lot of politics in a medium to large sized software org that can be difficult to manage. How do you get ahold of a person in another team you rely on but isn't responding? How to juggle contradictory requests. How to get better in some area? How to prioritize/manage time? The answers to these can be hard to intuit, especially for a new team member and might need to be discussed as issues pop up and can be very context specific. Staffing: When resources are clearly defined and a person is working on one project for a clearly defined amount of time it is simple. But often times there are new hires, people leave, someone might be switched projects, projects might get delayed, etc. There are actual trade-offs to consider here. They probably don't require a weekly meeting, but you are doing a lot of hand-waving. People managing - People can manage themselves for things that they are incentivized to do (normal project work for example), but if it is unclear what the priority is or if something is necessary, they won't do it. Many times there were "team initiatives" to improve code quality or testing and they never went anywhere because there wasn't appropriate time allocated to do it and there were project priorities. Same with asking people on other teams to do something for integration or to fix a blocking bug, often times they wouldn't respond or delay many times and it would be necessary to talk to management. I feel like a lot of your points are assuming everything is constant and things are running perfectly. But in any software organization things are constantly changing
dgb23 5y ago
Your post comes off as a bit arrogant to be honest, but I think you are essentially right. The most convincing argument is this: > > People won't manage themselves > They will if you let them. I feel like this is kind of the root of it all. You also mentioned mentorship. Maybe more experienced workers should consult, teach, mentor others to help everyone to become more autonomous, rather than "managing" them. And yes, that means it's people who know how to do the work, have done it in the past and hopefully will do it still. There is value in having people who make high level, strategic decisions, and those typically don't need this kind of level of expertise, but should rather trust their experts. But that's usually not what we mean with "management". You see I strongly believe in autonomy, which is why I have decided for myself to not have managers/bosses anymore. Just clients and colleagues for the time being. There are environments which are deliberately focusing on and enabling autonomy, which is very attractive.