[twelve40]

i think this is actually good advice when rephrased as: you are now a low-to-middle manager (that is called out specifically), so you neither call the shots nor are you mainly measured on your daily tech contributions, so from now on you can no longer avoid whimsical, irrelevant BS that is a waste of time like debating the branch names, because fielding that is a part of your job description now, so you need to embrace it and handle these conversations with a happy smile on your face, so that the people who actually move the project forward are not distracted by it.

[dijksterhuis]

Sort of. I wouldn't call it whimsical, irrelevant BS though. From the article:

> I remind myself that my role isn’t to be the most skilled person in the room but to create an environment where the most skilled people can thrive.

If most people in the team think we should switch to main instead of master, why would I sit there and deny the change? How am I going to find out if most people on the team think this way? Ask the question, let a discussion in whatever forum ensue, make some notes, ask some "dumb" columbo style questions, see what comes out of it.

It's not about me being right anymore. It's about the team being right. Ideally, together.

[pas]

Usually these things are obvious, no? (If not then it's going to be very challenging to be a [people] manager.)

Depending on location and/or cultural composition of the team these things will be either no-issue (no one cares enough to voice either approval or opposition, if some change is requested by management or some platform introduces some changes it's just inconsequential for the team) or there will be someone who sometimes will voice suppport/opposition so their needs have to be weighted (but as long as there's no conflict within the team it's smooth sailing) and then, if there is conflict then there's obviously a cold war in the making. (And at that point either the manager has enough authority and agency to work out some lasting compromise, start removal of someone, or they are at least can recognize that it's time to look for a new job, as things about to get ugly.)

[dijksterhuis]

I find your comment interesting. You start by saying, well, this should be obvious, right? Then you list five cases where, to me, things are not obvious. Like, i have so many hypothetical questions about each case. I won't bore you with them, but the change being pushed by management one i find particularly interesting.

Usually these are things we don't want to do, or shouldn't do (else we'd probably have done it already or have a plan for it at least). But folks in "management" or "executive teams" usually don't listen to engineering arguments about complexity spirit demons :(

so there are a lot of political questions i'd be asking in my head with that. e.g. Can we use this as a negotiation tool to stop "management" pushing for this-other-thing-we-also-don't-want-to-do?

[pas]

I have trouble applying your comment to mine (and back to yours about master/main changes, or in general to issues relating to culture fit), sorry!

Can you give a concrete example?

[dijksterhuis]

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.

don’t let shit roll down on the team basically.

that help clarify things? probably not :/

[pas]

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 :)

[bilvar]

Oh my god, if my manager asked me to waste my time on such trivialities - or even worse, calling team meetings to “discuss” them so that we can now collectively waste our time, I would quit the next moment. During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.

[dijksterhuis]

> calling team meetings to “discuss” them so that we can now collectively waste our time

it's not a dedicated meeting conversation. I would probably post it as a slack thread. If anyone wants to put their thoughts in, go ahead. If you don't, fine.

Number of people in the team who don't post by the end of the day ==> number of people who don't care.

Number of people in the team who do post by the end of the day ==> number of people who do care.

if number of people who do care > number of people who don't care, read the comments on the train home and have a think about what to do about it.

> During my exit interview I would state that my manager was an imbecile, incompetent and the reason I am leaving.

Well... that sounds like a good way to burn a reference.

edit —

> waste my time on such trivialities

in your own individual personal opinion this thing is trivial.

being part of a team means being part of a larger whole. whatever that looks like — including if other people on the team don’t share your opinion, or have similar but different opinions.

funnily enough the article explicitly mentions differing opinions being a good thing.

[bilvar]

Your job as a manager is to cut noise down for your team, so that they can focus on the signal. If you cannot decide on your own that some things are just plain silly and not worth their time to democratize the decision, then you’re not cut out for this job - sorry.