sorry for the delay, hope you end up seeing this reply.
so, specifically with “management hast decreed thou shalt do X”, there’s always quite a bit of politics stuff that can be played here.
- do they also want Y?
- out of X and Y, which one do they want more?
- if the engineering team are really resistant to Y, can we say we’ll do X first and see if they forget about Y by the time we’ve done X?
- what about Z? Z is kind of similar to X, but solves a specific customer’s problem alongside it. can we suggest Z instead?
- or are management too pissed if from last month when i spent half of it negotiating about S? do we just need to lump it with X?
- is engineering fed up with these requests? is morale tanking because of micromanaging from executives? or are people fine with it?
- is there some 80/20 hack solution we can put live in one sprint and then depreciate in 3 months time? are they going to notice this?
those are the sorts of questions i’d have around X being asked by management.
unless it’s a legal compliance thing, i generally doubt anyone in management requests anything because they use the product and want a solution to a problem.
so, they get a very strong filter applied to them.
like, $previousJob built a poor man’s clone of apache airflow in django. management were coming up with new feature ideas while we were literally in a meeting about replacing everything except the frontend with apache airflow or similar.
like, no, we won’t be adding event/time based triggers. airflow does that already! that’s the point of this meeting dammit!
the data science team on the other hand are basically dogfooding our imaginary product, so their filter is a bit lesss harsh. they actually have problems that need solving in the imaginary product.
so i usually “negotiate” less with them and focus more on understanding why they want what they want.
Ah, okay, I think somehow you parsed my very terse comment to mean something about (top) management's request, but I wanted to illustrate that a (line = engineering) manager knows roughly how their team(s) would react to these requests, and knows which battles to pick and with which side(s).
Like you said, if there's something crazy coming down from up? maybe it's umbrella time. If there's a company- or industry-wide shift and someone in a team is not having it? Maybe it's time for some fluctuation. And so on.
I'm trying to say that most things are "obvious" (well, yeah, either so obvious that I wasn't even able to describe it by the examples, or "so obvious" that it takes 4 pages of back-and-forth to clarify it :D)
My comment was a reaction to your recommendation of Columbo style. "How am I going to find out if most people on the team think this way" ... and my very "zen" (and unhelpful?) answer was that "it should be obvious", uh, sorry :)
so, specifically with “management hast decreed thou shalt do X”, there’s always quite a bit of politics stuff that can be played here.
- do they also want Y?
- out of X and Y, which one do they want more?
- if the engineering team are really resistant to Y, can we say we’ll do X first and see if they forget about Y by the time we’ve done X?
- what about Z? Z is kind of similar to X, but solves a specific customer’s problem alongside it. can we suggest Z instead?
- or are management too pissed if from last month when i spent half of it negotiating about S? do we just need to lump it with X?
- is engineering fed up with these requests? is morale tanking because of micromanaging from executives? or are people fine with it?
- is there some 80/20 hack solution we can put live in one sprint and then depreciate in 3 months time? are they going to notice this?
those are the sorts of questions i’d have around X being asked by management.
unless it’s a legal compliance thing, i generally doubt anyone in management requests anything because they use the product and want a solution to a problem.
so, they get a very strong filter applied to them.
like, $previousJob built a poor man’s clone of apache airflow in django. management were coming up with new feature ideas while we were literally in a meeting about replacing everything except the frontend with apache airflow or similar.
like, no, we won’t be adding event/time based triggers. airflow does that already! that’s the point of this meeting dammit!
the data science team on the other hand are basically dogfooding our imaginary product, so their filter is a bit lesss harsh. they actually have problems that need solving in the imaginary product.
so i usually “negotiate” less with them and focus more on understanding why they want what they want.
don’t let shit roll down on the team basically.
that help clarify things? probably not :/