from Hacker News

Senior Engineers Build Consensus (2019)

by lopopolo on 3/19/21, 3:23 PM with 115 comments

• by hprotagonist on 3/20/21, 3:01 AM

  https://billwadge.wordpress.com/2019/03/24/laws-of-the-unive...

  Wadge’s Law (of Meetings).

  Before every formal meeting there’s a smaller, more exclusive, less formal meeting where all the important decisions are made.

  This is based on decades of experience in academia and friends’ experience in industry and government. Sometimes there’s an even smaller, more exclusive, less formal pre pre meeting where all the decisions of the pre meeting are made. Maybe even a pre pre pre meeting … until you reach some guy deciding everything in the shower.

• by andrewem on 3/20/21, 5:12 AM

  I used to work with an engineer who would have a loud negative emotional reaction the first time they were told about some new thing that would be happening at our company, and after a little bit would be totally fine with it. After one or two instances of this pattern, the manager learned to talk to the engineer ahead of time, so the upset reaction wouldn’t happen in a big meeting. I suspect that more of us are like this than would like to admit to it.

  The manager’s new tactic seems to me both more effective and kinder, because it takes into account the engineer’s need to process a change outside of a public setting.

• by whateveracct on 3/20/21, 4:38 AM

  "Build Consensus" - hah, the words of an org chart climber.

  I've recently joined a BigCo (as a senior+ engineer), and the culture here isn't building consensus (out of authentic building blocks) - it's a toxic "we must be consensus after every meeting."

  There's always a "champion" idea (but you can bring a "challenger" idea so people feel heard), there's always a need to "be in alignment" after every 45 min chunk of time, etc.

  Consensus is clearly an end in itself, not a means by which we solve problems.

  I'll just slither around in it though. Talk the talk so no one gets wise $_$

• by ZephyrBlu on 3/20/21, 5:29 AM

  Is this not kind of intuitive to people?

  If you rock up and go, "we're doing this big thing tomorrow and oops sorry we didn't mention it before" of course you're going to encounter more push back.

  On the other hand, if you get people on your team before doing something then they will trust you and possibly even become advocates!

• by ggm on 3/20/21, 6:14 AM

  Sometimes consensus is impossible. You have to move on without it. Either you get stasis, or gradual change, or revolution or fracture/fork and no matter what you get dissent, consequences and cost.

  Consensus doesn't always exist. Its great to build it and its great to seek it.

• by zemo on 3/20/21, 4:31 PM

  clicked through to this not expecting anything new, didn't find anything new, this stuff is all obvious and should be clear to everyone. Clicked through to see the comments and ... the amount of pushback in the comments is very weird. All this is saying is "you should make sure that people want something before you build it" and the replies seem to be "how DARE anyone else affect what I build", from a bunch of adult children that think they are solitary geniuses. Every single person mad at the idea that building consensus is an important process is annoying to work with, full stop.

• by siliconc0w on 3/21/21, 3:29 AM

  To challenge this a bit - this actually sounds like a bit of a dysfunctional culture where you have to handhold stakeholders in 1:1s or risk knee-jerk opposition to change. This isn't to say this doesn't work. It certainly works and there are many companies with this kind of culture that will pay you to do this well but it isn't a fast or scalable way of making decisions.

  Ideally you can document the pros and cons of, say, moving to EBS storage vs instance backed and stakeholders give you comments with their concerns and you document and incorporate these and given enough stakeholders you can say, this is probably good enough for now and you trial using EBS-backed instances, improve your tools, document your learnings, and go from there. This can happen asynchronously, includes anyone interested, and can probably happen in around 1-2 weeks in a healthy culture. You do this so when there is the next EBS-outage you can point to this and say this was a deliberate decision and make an informed evaluation if the argument still holds rather than avoid going in reactionary circles. 1:1s don't document anything and only incorporate the views of people you think you should be consulted which is likely a subset of the people who want to be consulted.

• by baby on 3/20/21, 7:30 AM

  Is this a case of survivor bias / took the path less taken? As in, I just had a win so it must be that I was using the right techniques.

• by kvark on 3/20/21, 12:39 PM

  So this behavior has a name... I'm sick of this nemawashi thing used by people as an instrument (in the context of cross-company working groups).

  It's not about building consensus together, it's about sneaking your "consensus" into the group by the means of divide-and-conquire. It's very hard to build a solid alternative consensus (or a defense strategy) if all the opposing points have been voiced independently, and whatever one you can think of ends up with "oh, we discussed this with the other party, and it wouldn't work".

  Please respect your team and don't use nemawashi. If you are on the other side, learn to recognize it and call it out.

  TL;DR: nemawashi considered harmful

• by hn_asker on 3/20/21, 9:40 PM

  Agreed. How consensus is achieved varies. As an engineer, I am biased towards numbers because numbers are easy to compare. Use data to guide you on what the desired state is and getting to it.

• by TheDudeMan on 3/20/21, 3:46 AM

  10x engineers get it done without others even knowing about it.

• by syastrov on 3/20/21, 12:12 PM

  A bit off-topic, but as the article notes, Stripe is using AWS. Could someone share their experiences with AWS versus Google Cloud for a smallish business using mostly compute plus managed Postgres? The pricing differences shouldn’t be an issue, it’s more a question of whether they make a lot of breaking changes, have too many limitations, or have a bad UI, or too much complexity.

  If a company was starting fresh, which would you choose?

• by jart on 3/20/21, 5:09 AM

  One can use Nemawashi to lay the foundation for consensus. An even more powerful technique is to use Numerology to identify the consensus that already exists. See https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... and https://justine.lol/ape.html