[cdaringe]

ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or larger cohesive pjm. “just give me a gantt” like the author says would be an absolutely monumental improvement from how i see things get done

[bruce511]

With software you have a situation with two problems.

First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.)

The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed.

The second problem is that by it's nature software "never ends" and many (dare I say most?) projects fail and are simply abandoned.

The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget".

He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.)

His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying.

The miracle is not that this process sometimes fails. The miracle is that it ever works at all.

And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.

[intelVISA]

It's beyond software: any domain that requires oversight of non-trivial work should really have leadership from the ranks so they are able to ground their observations.

Managers with no domain knowledge are just an extra layer of indirection and overhead without any of the benefits. Would any IC want their career gated by someone who has zero insight into the team's day to day duties, doubly so if it's at a supposed "tech" company?

[randomdata]

> at least understanding the game might help you understand why his job is the crappiest of all of them.

Well, sure, but that's what the daily standup is for. So that the problem solvers on the team can understand the process, the problems it faces, and, importantly, find ways to optimize it.

But it seems, for how crappy you claim it to be, those in that position don't want to talk about it in fear that it will get optimized away. Job protectionism trumps all, I suppose.

[cdaringe]

Trust and rapport are gained in time, often in short order. Small artifacts of evidence should generally prove to the bean counter that they are cutting checks for something!

[shepherdjerred]

This is really interesting. Do you know of any articles/blog post that goes into these ideas further?

[bruce511]

No, alas no material to refer to, other than my own experiences at several places in the food chain.

At the moment I'm having fun developing again, but I have had experience of management as well.

Obviously my experience does not speak to all cases, and I'm fortunate that most middle managers I've dealt with are competant.

I am in the fortunate position of being able to "speak truth to power" though, and generally been able to dispassionate translate technobabble into managerspeak, and help all the layers understand each other better.

I've found that when both sides understand (as much as they able) the complex demands being encountered, more realistic expectations and demands are made (and usually achieved.)

But I've been lucky. I've had good dev teams, good middle management, and good product owners. Who have all been pulling together to make projects successful. When one group is pulling the other way, things get tougher.

[JonChesterfield]

The meetings between engineers are rather unstructured. I hadn't really thought about what meetings between business types would be like. Decisions get made in those that affect whether the company is a viable going concern. That makes for a very uncomfortable line of reasoning.