Earlier quoted context omitted.
> because there was no advance warning or discussion. As a manager I learned to keep my senior engineer pre-informed the hard way. Personally, when I was an IC, I was totally fine not being kept in the loop because I was impervious to such news or changes. So I just assumed that’s how it’s with everyone. Clearly I was wrong. That said, it is important to release that pre-information in an informal fashion lest they s…
What is an IC? I don't recognize the acronym in this context
Senior Engineers Build Consensus (2019)
61–70 of 123 posts
Re: Senior Engineers Build Consensus (2019)
#62If a company was starting fresh, which would you choose?
Re: Senior Engineers Build Consensus (2019)
#63Is 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!
Re: Senior Engineers Build Consensus (2019)
#64https://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 decisi…
That’s called an oligarchy in politics. Can’t say it’s a great operational model
The problem being solved is that most ideas are not good, so any single person with an idea looks to vet it among a trusted group of advisors/peers. If this group is too large, it's hard to deal with the noise, too small and it may kill or ok an idea when it shouldn't be.
After refinement with the smaller group, an idea now has enough substance to bring to the larger group and hopefully not waste their time.
A simple example this process helps avoid would be pulling together the full group, presenting an idea, and then legal killing it with their first comment. Everyones time was just wasted since the idea as presented had legal issues and needed more refinement.
Re: Senior Engineers Build Consensus (2019)
#65It'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
Re: Senior Engineers Build Consensus (2019)
#66https://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 decisi…
So at the meeting, only hitches to the (expected) plan are expected. Not building a plan from scratch. Its more like a standup than a bull session.
Re: Senior Engineers Build Consensus (2019)
#67"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…
> "Build Consensus" - hah, the words of an org chart climber. Not necessarily. You want to convince your team or other teams to adopt a new tool or practice? You need to build consensus. It's a good skill to have if you want to be able to shape your workplace to your liking. It doesn't necessarily have to involve org chart climbing at all.
"let's have an endless, design by committee approach where the backend dev with no knowledge on UI decides how the UI should look rather than letting the UI designer create a few samples and iterate and everyone else giving feedback like a user would"
or
"we already decided this is going to happen, but for the sake of formality we want you to agree with it so we can feel good about ourselves bullshitting one another into believing everyone has a say, so give us the ok or we'll pester you until you do"
It also stimulates the idea that disagreements are inherently wrong and nothing should happen while a disagreement is in place. Sometimes, it's ok to disagree with someone else and see what happens. Some might call this a form of consensus, though I've had managers get uncomfortable when I didn't vehemently agree with the plan, but was willing to keep my nose out of it and focus on my own things so others could take the risk.
Re: Senior Engineers Build Consensus (2019)
#68I 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…
The engineer in this case had an emotional control issue: they reacted badly to anything new, even if they had no rational reason to do so (they were fine with it later). This could have been tackled by working with the employee to get them to understand that this type of loud public reaction is causing problems for everyone, including the perception of their own skills, and that they need to learn how to take a deep breath when a new change is announced - maybe wait a few minutes to write down what they wanted to say and then wait a few days before hitting the send button. Lots of approaches. Instead everyone else adjusted their behaviour to avoid tackling the underlying problem.
The manager’s new tactic seems to me both more effective and kinder
Maybe I'm just some asshole manager but I never saw it that way. You externalised one person's problem onto the whole team, who now all have to be aware of this special exception. Most obviously it makes it difficult to have brainstorming sessions, or if someone comes up with a new idea half way through a meeting unexpectedly, they can't raise it there and then, they have to wait for the meeting to end, pre-brief this one guy, let him/her get over it, then raise it with the rest of the team.
So whilst it may have been kinder to that one specific person, I'm not sure it was kinder to everyone else, let alone more effective. Especially because once such a culture is embedded, sooner or later half the team has some weird quirk that everyone is expected to work around or ignore.
Re: Senior Engineers Build Consensus (2019)
#69Earlier quoted context omitted.
Oh I've already experienced my opinion not mattering at all. I haven't been put off trying to be involved just yet though. I'm also more interested in understanding and being involved than simply being frustrated and venting.
That's what I thought, until I never understood and was way more emotionally involved than I actually was involved. How will you handle that frustration? I didn't realize it at the time, but everyone of the same seniority level, but a few years older, already realized not to give a single fuck about anything beyond their immediate sphere of influence. They had already learned that the work truly did not matter, and a…
Your advice is contradictory: you’re just immediately causing future pain.
Re: Senior Engineers Build Consensus (2019)
#70I 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 seems like an instance of a common tactic (or problem, depending on your perspective) that is especially common at software firms where management learn to work around employees' problems instead of challenging them to improve. The engineer in this case had an emotional control issue: they reacted badly to anything new, even if they had no rational reason to do so (they were fine with it later). This could have…