[graypegg]

I think every good experience I've had as part of a team, was because the business people, the designers, and the engineers were all respectful of each other, and had no power over one another. So I totally agree! Nothing stops that.

People always imagine every team has to be some little internal war, and I think the whole methodology-mill industry is built around that belief. People CAN'T compromise or work together, or at least we can't bet on that, so here's some process. That rubs me the wrong way. It's pretty patronizing, you're right that it's like treating engineers like children.

> Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.",

This is a totally respectful conversation with understanding on both sides. I might want to just make sure that the engineer in this scenario would be open to:

    Marketer: "Feature XYZ is going to make a massive impact if we could get it with some clients this year before competitor X. Even feature XY without Z would beat their offering. What do you think?"


    Engineer: "Ah yeah, I can see how that would be a really good advantage to have. I think XY might still be a bit hard to hit for EoY with the quality requirements we have, do you know precisely what they're planning?"


    Marketer: "They are really only shipping feature X for the first month I think. No screenshots of Y in their announcement. Being the first mover would be good, even without Y."


    Engineer: "We can make X happen, easy."

That conversation is also very respectful and everyone is adding valuable knowledge. It feels more realistic to me as well. Sometimes "no" isn't a great answer when "could we try for something at least?" means we could solve a lot of problems/make a lot of money. That's sort of my ideal way of working now. I'll hold everyone to the expectation that they're good at what they do, and they respect that I'm good at what I do.

[bluGill]

That works when there is 1 engineer and one marketer. When there are hundreds of engineers and many marketers you risk the marketer unknowingly asks an engineer who isn't the right one and that person over promises not realized the full scope of the problem and how it will affect others who are also making their own promises.

[graypegg]

I'd rather have a (high!) chance of that happening as a mistake low down on the hierarchy tree, where it's just the marketer (or maybe a region's marketing team) and two engineering teams involved that have unfuck their situation, than high up at the top where the C-suite only talks about the roadmap with the marketers and the bad decisions just wash over the whole company.

Don't think there's any solution that fits all scales of head counts in all fields of work. Middle management exists because employing 1000 people to each do something specific is inherently a hard task. Are they doing the thing, are they stopping other people from doing their thing, have they signed this form, have they got their benefits for this, are they getting paid the right amount, etc.

You actually save a lot of hassle with hierarchy, in the people-wrangling group of tasks.

But I still think some inefficiency at the lower level between motivated product teams with a few mandates each, is a better long term bet than assuming the same reasoning for middle management to exist applies to other fields. Engineering/design/marketing isn't people-wrangling so we shouldn't assume the same solutions that work for wrangling more people work for shipping more products.

[alganet]

A company with hundreds of engineers and anyone of them can overpromise on some random feature?

Sounds like a widespread communication issue.

[bluGill]

That is why we have processes - so people know what promises they can make.

Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.

[alganet]

I've been there.

If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance.

If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process.

I've been on teams that transformed every little mistake into a lesson, burdening the whole team with cargo cult processes. Things we did because "once upon a time....". That's not healthy. I'm not implying that's your case, just showing another perspective.

[bluGill]

Do not throw away process because bad and wrong processes exist. Anytime you have a process you need to have a process in place to review and modify the process as needed. You should reward people for successfully changing the process - enough that people don't feel like it is a wasted effort, but not so much people look for ways to change it just to get the reward.

The right process is very valuable. However I will fully agree that there is a lot of bad process out there that people are following because change is too hard (sometimes this is all in their head and change is easy if you would just try!)