I'm sure there are places where that job is primarily about engineering... But that's just a place that doesn't actually need EMs! Maybe you are saying this is the ideal org, and yeah I probably agree. So I guess this is just a semantics thing.

This is the biggest difference between companies that fade out, and the ones that keep being innovative as they grow.

Inaction in this regard leads to the company becoming top-heavy with people that have no clue on how to drive the company forwards, they only know how to climb the ladder.

There are people whose entire careers are built on this!

Counterintuitively this is precisely why the people who care more about things being right than about winning need to work on their persuation skills: Otherwise the wrong thing will get done and guess who will have to deal with it.

But accounting for that, too, is part of persuasion — even if it's not on this list.

* there's a set of graphs I can't find, objective quality on the x-axis, bell curves, vertical lines drawn in different places for each country, US labelling everything that's better than terrible as "amazing" and vice-versa for eastern Europe.

No country is immune from that either. Get a large enough group of people and politics is the default.

I think we've all had to deal with difficult people or organizations that might need methods like these to allow them to come to a mutually beneficial decision either faster or at all.

A common technique I've heard of is "hairy arms". This is from the graphic design world, an area that practically everyone thinks they are qualified to judge or comment on. Some stakeholders will always give a comment or request a change, no matter what is presented. So the technique is to put hairy arms on the mascot, the lady, etc. A small flaw so that stakeholders can feel that they've given feedback, been heard, but avoid large changes that often cause multiple rounds of feedback.

Should you use that technique on everyone and every project? I think that's a bit disrespectful. Should you use that technique when dealing with a client that always has feedback, even on excellent work? Probably.

This is so wrong on so many levels. At its basic, it’s exhausting to speak up about process improvements and see things turn to shit each time one comes up.

This greatly depends on work culture and ARL's - adulthood readiness levels.

Many people are not graceful with open criticism even if done privately and constructively.

Without falling into stereotypes culture still matters specially in an international setting. Some cultures expect a lot of innuendo and indirection, for example in British or Japanese work environments. West coast US typically expects a lot of positive praise even when pointing out negatives. Whereas others like the Dutch expect more direct or even literal speech.

So like, applicable to 98% of all organizations?

As an engineer I agree that an organisation should work as you described. But depending on where you are and what it is you need to do you might need to persuade somebody to do something. Or if the doing is implied you might need to persuade somebody to do something faster (means: they should priorize your thing above other things) or with a higher quality than usual (means: they should use more time, put their best hire to work or whatnot).

I agree that this isn't optimal, but each department may see other things as important. For accounting that audit might seem more important than getting your order done quickly, because for them it is the bigger, scarier and more complicated thing. So persuation sometimes just means reminding people why the thing you're doing is important.

when you work among 180 thousand other people, a good chunk of you energy will be spent on justifying your existence.

in a top-heavy, cutthroat place like a FAANG, people will fight fiercely for promotions (that's half a mil extra cash in your pocket this year!), and for managers that means getting into the newest hypest shiniest projects or fall behind and eventually get kicked out. The way you join hyped-up projects (or even hear about them before it's too late): you invent one if you have the balls and the energy to pull it off, or persuade someone influential to let you join an existing one. So, strong disagree on "managers don't pitch projects".

I did a stint with a large US org where my SOW was to do azure (hashicorp) vault. The org already had about 20 aws vault clusters, GCP was a likely new target.

I sold k8s. That was seen as risky despite being less overall work, so I delivered direct on azure clusters, then was given a SOW to do k8s POC ( with a view to doing GCP ).

POC delivered a fairly production like service in ~a week using the most junior person on the team, only to spark outrage that I ( a person with about 10 YOE with k8s ) had delivered a POC without discussing with the core platform team ( which was intended to be POC 2, separating the issues of concern ).

Now I get why people do platform teams, and this platform wasn't bad ( more work than rolling my own equivalent; but the processes in theory ensure the less experienced people don't do terrible things ).

End result was pretty much a blocker on GCP vaults because we were awaiting said platform team to deliver for us, and me ( a contractor that delivered several at risk SOWs ahead of schedule ) cut loose because we're blocked by the other team.

In such an org, it's the job of the EM to advocate for their delivery stream, mine didn't quite manage it that day.

However, this org was probably the best ran at scale I've ever seen ( usually you can nuke an org in like 10 minutes after they give you access to the SCM & CI/CD ).

You don't want to manipulate anybody, but man are customers stupid sometimes (cue "clients from hell"). E.g. a pattern I noticed was that especially self-important customers always wanted to change "something" if presented with one draft — not because that change made sense, but because they felt the need to be in control. And if you know that is going to happen irrespectively you might as well just control the context within which it happens.

This is why I switched to presenting multiple drafts after each other with the first one being the "lightening rod draft". This way all the self-importance could be channeled there and they would (empirically) be far less likely to make destructive proposals on the later drafts which they then also liked more.

That is certainly manipulation. But manipulation done with the intent of saving customers from making stupid choices that fall back on me after a while, because of in the heat of moment paychological needs. If I was someones customer I'd like them to do the same for me.

If someone really didn't like all drafts I'd recalibrate and figure out what they want, I can be wrong and my ideas are not holy. But if you hired me, it was very likely that I know more about the craft than you did.

I suppose Facebook hires for cultural fit and shared vision, and I suppose that working there must require lots of manipulation.

No, it's better to find their flight schedule and wait at the gate.

Humans aren't rational.

This describes the boss / owner at my very first real computer store job (sellin' office machines) way back when the local Radio Shack was still sellin' the Tandy TRS-80 to home users. He treated all us employees with the same respect he expected of us, and he recognized and rewarded hard work and good ideas, and it really showed in how we all treated customers as well, which of course led to lots of happy customers buyin' stuff, which led to lots of free "word of mouth" advertising, which led to lots of sales, which led to happy boss, which led to happy well-paid employees ... Everyone wins. Funny how important "the little things" can be sometimes.

He was also the only boss I've ever had tell me "The customer is always right ... unless they're wrong ... Then you send 'em straight to me." (Usually so he could tell 'em why they're wrong and then either make the sale, or tell 'em where else they can take their money to. :)

One repeating issue we have had with our managers is they will try to label missing features as bugs, to put the blame on the product team when they have sold something unfeasible to a customer.

Another one is that they pretend that the feature was decided on long ago, when it was only briefly discussed and then decided against.

LinkedIn noise indeed.