"Performing" Consensus
Posted by gollyned@reddit | ExperiencedDevs | View on Reddit | 20 comments
There's a pattern I've noticed in my org that basically goes:
Write a doc that's light on details, with a section of people from various teams for 'approvals', and hassle them for signoff. Then announce that you've built consensus about something while deferring the actual decisions until later.
I'm thinking about incentives & appearances. Having a document that actually raises difficult decisions, choices, trade-offs, or dates just ends up inviting pushback. There's enough social pressure to keep good relations to sign-off, and a doc without hard choices is impossible to disapprove of.
My reaction is first to be cynical about this kind of approach. I'm thinking: is it also actually useful in terms of trust-building to show alignment? Or is it really all a cynical show? I'm trying to figure out if it's a strategy I should adopt. It's one way to force engagement on documents, with a section left empty or blank for signoffs.
Once, I was even impelled to give a signoff. I ended up delegating to someone else since I wasn't ready to either sign off or block. The engineer is very experienced, more than me -- is this kind of thing normal and actually a good practice? Or am I feeling put off by what looked like a false display consensus-building?
1000Ditto@reddit
The main point of this doc is an initial charter for a project: that is, get general buy-in (no hard Nos) that a project would be accepted by potential stakeholders. It's to broadly scope out the business impacts, resources required, why it should be done, risks/mitigations ,costs and maybe a WAG of how long it would take (think business impacts//eng mgr concerns).
Once there is some sort of concencus, a more specific project proposal featuring the more specific details such as architecture, tech stack selection, ie more technical proposal stuff (highly varies), which is what you're looking for (think staff/tech lead concerns).
gollyned@reddit (OP)
Interesting -- I've seen documents that do part of that kind of charter, but based really on setting out some intention to build things stakeholders like in bullet points (like "LLM Gateway" and "Cost Efficient Serving") but without the risks/mitigations, costs, etc.
Is the signoff itself purposeful? It doesn't seem like it'll be blocking anything.
driftingphotog@reddit
It's to force alignment that you're solving the right problem and it's worth solving the problem.
In a healthy org, the sign-off isn't truly that important. It's just a way to enumerate stakeholders and a forcing function to engage them.
I don't really use them, but sometimes I've had misses where we forgot to talk to an important group and defining it at the top probably would have caught it.
You had a separate point about the social pressures to sign off. Consider that the review meeting isn't necessarily the actual review. If I'm proposing something actually contentious, I'm talking to people prior so that when it comes time to review we're already aligned.
gollyned@reddit (OP)
Frankly I think the biggest thing is that “consensus building” checkmark. I’m seeing this most from a manager and IC who are historically seen as not easy to work with. I don’t like to be cynical since it’s easy and often wrong or can’t be proved right. But I’m seeing docs with basically no objectionable material being pushed for sign off, then celebrated.
This exact case is an issue where they refused outright to engage even conversationally with me. I’m thinking: if I followed their tack, and forced their signoff or refusal, things might have gone differently.
But still, I think probably not. I really think they’d just refuse to engage and say they don’t have bandwidth, and would have to rearrange their roadmap to even read a doc.
8ctopus-prime@reddit
This can be different based on the organization, but those initial sign offs are often a sign off that work needs to be done and thats it. Its a paper trail stating in broad terms that they've approved work on the "what." The more detailed documents are the "how" and it's often not their job to know the details of that. They often honestly don't have the bandwidth to know all the how's, even if they can understand it.
It's also a boon to not have that codified at a high level because it gives the individual contributors flexibility in execution.
A good approach to take is their responsibility is the high level what and they're trusting that you will take care of the how in a way that is a win for your team. That's what you want.
tevs__@reddit
What are your artifacts? We have four in the process:
RFCs tend to be the starting point for tech work, Proposals for product work, but sometimes we go through both on the same project.
From what you've described, it's either an RFC or a Proposal, it's not super detailed on the solution. No ADRs have been created so it's not tieing anyone to anything yet.
gollyned@reddit (OP)
PRD. We have a template, similar to proposal, but it wasn’t really followed in this case. TDD as well. One-pager, which is just a smaller TDD.
In this case, it was PRD with a bunch of copied and pasted things from other docs, and a decision log. Sign offs were meant to indicate agreement with 3 things that set structure, but it ended up turning into “sign off means decisions will be pending follow up TDDs”. Which means: we’re agreeing to there being future work to decide things.
It was announced to be successfully signed off on, consensus achieved in record time, without actual signoff from my team. My teammate who I gave ownership to on this had to end up signing it after the fact.
tevs__@reddit
Oof, feel for you. Sounds like the decision was we'll just make decisions on the fly
Maybe use this as an example to propose some better processes? Maybe keep it in the back pocket for when this project derails..
gollyned@reddit (OP)
Frankly this team really hates me. I'd tried to do the same kind of consensus-building a few months ago, since we were trying to build the same thing, and thought we should combine forces.
They were adamantly against it and apparently thought I was trying to take over the project. There's bad blood going way back.
Their director hated my director and wanted my director's job and me and their team were building the same kind of system (again). My director got fired and their project failed. So they had to come over to join my team & my project. I was moved to another team to make room for the other engineer (and promoted to his level).
Last year I made some very tame comments on one of their docs questioning if they were concluding on a major tech choice without good data. They (especially the manager, her first year as a manager) took it as an attack. The manager sent me a message saying she would circulate feedback amongst management that I was not operating at my (newly promoted) level -- I understood that to mean that their former director would end up attacking me at perf calibration. Ever since then things have been a constant petty battle where they're trying to one-up me or 'score points'.
The fact I wasn't in the meeting, and they were able to achieve consensus when I wasn't able to -- I'm certain will come back to be a case of "gollyned cannot work internally in the platform". Since me and that other engineer are at the same level and in the same platform, we're essentially competing for performance review.
Just a really awful situation. I think basically anything I do will end up making me look bad. It sucks feeling like they're looking for any opportunity to attack me as 'retaliation' for something so innocuous and petty, and that it's been almost a year for it.
severoon@reddit
It depends on what your company is building. What is the desired functionality of the thing?
Do revenue streams depend on it? Is it mission critical? Will people die? Then push back. If they want to go forward anyway, then say, "Yes, the goal isn't to block progress! Just note it as an open issue with a deferred decision and go forth and prosper." As long as you provided due diligence, you did your job, and the thing will be followed up on later.
Is it software that is designed to comply with regulations that no one cares about, including the regulator, but it has to be done to tick a box and "show reasonable effort." Then sign off and go have a matcha latte in the break room with the author.
You always have to take context into account. If the thing can break in prod and it will just be an annoying hassle for the owner to fix, that's okay.
gollyned@reddit (OP)
It’s really low stakes. It’s how we can work together to build a UI.
It’s the process itself that smells bad to me. They were quick to announce alignment (even before the person I nominated in my team to sign off actually signed off) and celebrated it publicly.
This was something I’d tried to do before. They flat-out refused to begin a conversation the moment I mentioned a UI, then now misrepresented my previous efforts as a “discarded alternative” they agreed in a meeting I couldn’t make to discard.
I can’t help but think this was all about scoring points, making themselves look good, and me look bad when I’m not in the room. It tells a clear story where: now that I wasn’t in the room everything went fast and smooth. When really, they were dead set on not engaging at all.
Traditional_Fox7091@reddit
Why not just ask for the details as a review comment ?
gollyned@reddit (OP)
I am wary about being seen as a blocker. I’ve had a lot of contentious moments with this team. Even about this topic. I think they are eager to show they are able to achieve consensus where I failed months ago, due to their flat-out refusal to begin to engage.
small_e@reddit
Man I’m done with this shit. Every single post is AI slop.
ijblack@reddit
this is one of the most obviously not AI written posts i've seen on this sub and even has missing words and tense mismatches. you should recalibrate your AI detector
futuresman179@reddit
Don’t bother. I have a feeling these comments are AI generated
CatalonianBookseller@reddit
Nice try Claude
YeastyWingedGiglet@reddit
How are you even determining if it’s AI generated?
gollyned@reddit (OP)
Seriously? What makes this seem like AI slop?
seinfeld4eva@reddit
It depends on the company and the people involved, but no, planning a project shouldn't be just a performative show. In a good work environment, you have people who really care about what you're building. It's important to have the tough conversations with them before you've gone too far down a certain path. It can be painful and difficult at first, but you should invite discussion and try to agree on a solution that everyone supports. Of course, plans always change, but it's easier to effect those changes when you have the initial buy-in. If it seems like people at your company aren't interested in solving difficult problems together, then you should probably look for a better company to work for. This tends to be a bigger problem at large companies where there is a lot of politics and bureaucracy. A startup might be a better place for you.