[andykx]

Very well said. A friend of mine worked at a winery and he was very enthusiastic about his work -- he loved making the best wine he possibly could.

He recently bought his own winery and, to his (and my) surprise, maybe 5% of his job involves interacting with the winemaking process. The vast majority of his job concerns compliance with regulation, bookkeeping, and communicating with vendors/suppliers.

I think it's good to have a holistic view of an industry before you dive into it. There are a ton of "housekeeping" things to be done in every industry, but in a sufficiently large company, you're often shielded from the things that aren't your direct concern.

[ZephyrBlu]

I'm surprised that both of you were surprised that most of his job comprises of logistics. That's kind of how things tend to work.

[bryanrasmussen]

from outside, when not dealing with the logistics, you do not have an understanding of just how many logistics there are. This is why developers think managers don't do anything.

[WalterBright]

> This is why developers think managers don't do anything.

A programming dev manager told me years ago that his mornings were spent dropping by each member of the team. He'd ask how they were doing, and what they were working on.

He'd then gently nudge them back onto what they were supposed to be working on.

[tobr]

Because they were always working on the wrong thing, or because he had just interrupted them with chitchat?

[tsukikage]

Usually this sort of thing occurs when management perceive fixing technical debt as a distraction instead of an investment.

[IneffablePigeon]

That's the cynical take - not that it doesn't happen, but there's a lot of reasons why a manager might have better context for what is important to work on at any given moment that are genuinely useful. For example: business priorities (not just "tech debt" vs "tick feature boxes", but "which of these 8 aspects of this feature should we build first", etc.), more experience in what aspects of a problem are worth spending time on, being more connected to what others are doing around the business in different departments, having more time talking to customers to know what their real pain points are, etc. etc.

In fact, as a manager in my current team I probably spend more time nudging people to fix technical debt they've forgotten about because they're excited to work on the next feature than vice versa. In other teams I've spent more time cautioning away from writing functionality that isn't needed right now to avoid overengineering the solution.

How you communicate that guidance and extra context has to depend on the team, what works for one won't necessarily work for another. What you found to be terrible another developer might love - as a developer who now has some management responsibilities I had to learn that some people actually want a lot more management than I would have ever wanted - my "micromanagement" is their "I am supported and know what's going on".

Anyway I'm not saying there aren't bad managers out there (or that I'm a good one), but it's a lot more nuanced than you imply, and what you might hate in a manager others might actively seek out.

[bryanrasmussen]

perhaps the devs on his team were the kind apt to go down interesting rabbit holes.

[WalterBright]

Because they were always drifting off onto something more fun.

[pdimitar]

That's because a huge chunk of them really don't do anything -- but let's not hijack the thread back to programming.

Logistics are an important part of many areas indeed. Programming though? Depends. I've been in companies where DevOps / sysadmins were 5x more than the programmers and they still were struggling, and I've been in companies where 1-2 guys standardized a deployment process over the course of a week and then didn't touch it for years.

[xur17]

> This is why developers think managers don't do anything.

I've started doing more managerial things at work, and it's given me a lot more appreciation for what managers do. Not sure I want management to be the majority of my job long term, but doing a "tour of duty" has been quite eye opening.

[ZephyrBlu]

> from outside, when not dealing with the logistics, you do not have an understanding of just how many logistics there are

For any particular situation, sure. But I think it's a very safe assumption that most your effort will be put into logistics or other admin-like tasks rather than the thing you think you'll be doing.

This seems to be a very common occurrence, so I was surprised the GP and their friend did not realize what they were in for.

[watwut]

Developers are inside. We see managers. Some of them in some companies are useful. Others in other companies don't.

[bryanrasmussen]

As a developer I don't think I get to see most of what a manager does, other than they are in meetings all day long that I don't attend. So I am not inside the logistics of what they do. But I guess you attend all the meetings your managers do and you know everything they do?

That seems to be a surprisingly inefficient company structure.

[netjiro]

I think the most common mistake is the assumption that the coordination by the manager is essential to supply direction and avoid errors and mistakes. This is consistently assumed without actually measuring the amount and severity of mistakes without management direction.

I know I can trust my people to coordinate themselves with very low error rates as long as I provide them with the information and incentives they need to make the correct decisions by themselves.

The total cost of extra full time managers is significantly larger than the measured error cost.

Some of the common management tasks will be loaded onto leaf node staff. This costs less, mostly since they aggressively minimise those tasks to the bare minimum friction while a full time manager tend not to.

It is not 1950. We can trust our people to function much better given the right environment and tools. I've run several large complex international projects with very low management overhead.

[bryanrasmussen]

>I think the most common mistake is the assumption that the coordination by the manager is essential to supply direction and avoid errors and mistakes.

I mean there are different levels of managers, there is your direct manager who probably just needs to delegate some tasks and trust you to manage yourself, and then manage their local budget, but there are managers also of a division with multiple groups in there and they have to manage stuff about budgets that takes into account legal requirements that people lower than them really aren't aware of.

anecdote time about this managerial level (I've told this anecdote before here) - one time I was consulting at a place and they had these Friday breakfasts for about 7-9 teams together (so about 100+ people in a big warehouse eating danish breakfast) and the division managers would sometimes say some things about what was going to happen in the next few months. So, one time the main guys for all the teams gave this speech about why they were doing something in a particular way and it went very deep detail about accounting rules and a particular financing law that applied so that was why they were structuring the next 9 months work in the way they were because it allowed them use a half a million dollars etc. etc.

Everyone was nodding sagely along as if they understood what they were hearing, but I knew a lot of them didn't understand anything, I didn't understand it all either - I just knew I was hearing the managerial equivalent of nerd speak - like the way I would talk about engineering tradeoffs.

A lot of the developers there spent their time going around talking about how these two guys did nothing and were useless, because from the 'outside' of their work it would look like they just sat around talking.

Maybe they are not as useful as other workers, but I do know that I am not able to adequately judge it from what little details I observe about their daily routines.

[qaq]

It's mostly miss-aligned incentive structures and internal politics. Managers are trying to climb up the ladder, increase influence, get more reports and at the same time keep competing interests from doing the above.

[lhnz]

I think it feels slightly different when you're doing it, because internal politics is mostly stuff like "team C has created a new service to do something you'll be doing" and you're trying to work out whether it exists yet, whether it solves your problems, whether it's super buggy, what the roadmap looks like, etc.

If you pick wrong you could end up integrating with something that is vapourware or causes issues, yet if you refuse to pick what is offered it can be treated by the other manager/team as a huge insult and then a narrative can be crafted and verbalised to upper management that it was a non-strategic play on your behalf and wasteful of company resources, etc.

Working within this context with other managers and teams, means constantly needing to understand what they're trying to achieve and offering a helping hand, while protecting yourself from bad decisions that would negatively affect your own team. Even if you aren't trying to climb the ladder yourself, you have to avoid actions that harm your team.

This might be inefficient, but once others are playing this game, you have to be really aware about what is going on, and ensure that you're always playing the right hand.

[watwut]

You don't need to be on every single meeting to get general idea about which manager is adding value and which is not.

I don't need to be expert in management to see that corporate management where managers almost outnumbered team members, changed every few months and attempted to manage without ever learning what product does was bad.

[unclebucknasty]

It's probably the ratio that's most surprising. Sure, most people probably know there'll be bookkeeping and other tasks, just not the degree. I wouldn't be surprised if most people imagine something like 50/50 at worst.

Some might also be surprised by how distinct the logistics/admin work is. For instance, they may think that since it's bookkeeping for a winery it's still work related to something they love, thus enjoyable. Then, they realize bookkeeping is bookkeeping, which further emphasizes how much time they're spending on not the thing they love (logistics/admin).

[MauranKilom]

Joel Spolsky article about exactly this, but for programming: https://www.joelonsoftware.com/2006/04/11/the-development-ab...