[brendanfalk]

I think the real problem here is "decision making" as opposed to "collaboration"

I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.

Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)

[criemen]

This is the key insight for me about this post, and I fully agree with you.

No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth.

Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all relevant parties. As long as they trust that they're being listened to, they don't get a say in the actual decision making process themselves. I also agree about taking reversible decisions faster.

Another point I deeply disagree with is

> collaboration forces the driver to slow down and explain stuff (background, context, their thinking).

Yeah, and that's a good thing. It forces them to properly think through their thoughts, if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.

[46Bit]

> if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.

I kind of agree. Without what you describe, teams often get lost. But I’ve also seen that approach keep teams stuck in comfortable local minima. Sometimes you’ve got to take risks.

[criemen]

People need agency, and feel empowered to go forward. I'm not arguing against that interpretation of the post. But having agency doesn't equal a lack of accountability, or being able to explain what you're doing.

In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.

[methyl]

> Quality goes up by slowing down.

Not necessarily. You get biggest insights about quality after you ship, not before. Slowing down means you ship later, which means the insights are delayed. Unless you work in a rocket industry et all, slowing down will be detrimental to the quality.

[jjcm]

> Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)

I'll add one more to this - not knowing how set in stone any decision is. I'm a PM, and I'm often the one charged with making the final call on many things. One thing I've often seen go wrong is a PM or an exec will say something like, "we should do x" in some review, and the team moves heaven and earth to achieve x, only to find out later it was just a drive by comment from said person, not something they deeply cared about.

One thing I've started doing is adding a GAF score (Give A Fuck score) to many of my decisions that have engineering ramifications, especially for anything that affects platform or architectural aspects. IE I might say something like, "this needs to have less than a 200ms round trip, this is a GAF-10" if something is direly important, and if we should commit significant engineering effort to making the decision happen. Or I might say, "I think we should go with approach A instead of B, but this is a GAF-2, so come back to me if you feel like A becomes untennable".

This way the team can move forward, but wont overindex on decisions that become bad decisions.

[anssip]

GAF score sounds like a great idea!

[actsasbuffoon]

> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing

I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”

Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.

I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”

And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.

I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”

I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”

This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.

I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.

[thw_9a83c]

> I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.

This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly

[thoughtlede]

For me there are two things about collaboration.

Decision making is one, which you emphasized.

The other is knowing what the collaboration brings to the table and shaping the rules of engagement to fit that expectation. Sometimes you collaborate with SMEs; they bring the domain knowledge - you don't, but you understand the goal better than them. Sometimes you are creating or refining the corporate strategy based on the actions from individual projects or partners; you are learning ground realities from them. Sometimes you need help from others to improve your take on a subject.

In each of these cases, you have to be clear about what you expect from the collaborators (and motivate them to contribute). Without being clear on what the collaboration is about and what they get in return is the number one killer of collaborative projects even though there is no ill-intent anywhere.

[KaiserPro]

One of the things that good managers/leaders do is not "make decisions", ie do it this way, but increase the number of decisions that can be made autonomously.

THat could be giving guidance; The product is aimed at x, which means that feature y will need to happen before feature z

Or a framework; We choose to prioritise small throwaway prototypes vs ground up intensive planning

or just taking away decision dimensions: buy this software in and concentrate on this other thing

[ergocoder]

The thing is: once you have feedback, you have to act on it. Ignoring the feedback is dangerous unless sanctioned by higher leadership.

This is our nature, and the blog does hit this point where we default to collaborate.

There is of course a better way. A senior employee should be more intentional about feedback e.g. whether can be done later, put it on a backlog, or must address right now. A junior employee should be intentional about what specific feedback they need.

[forgotusername6]

With PRs we prefix comments with issue/question/nitpick. Not everything must be fixed, but it's still useful to at least read the comments.

[gregw2]

I agree with your comment that getting feedback is different to making the final decision.

But I'm not sure the real problem fits solely in your two buckets.

I've been in recent situations where there is a less-technical person charged with making the "final decision" and a lot of other senior people in the room who don't all /have/ to agree. But the degree of "why not do it this way?" questioning+discussion will grow with the number of meeting participants (and/or worse, the # of meetings before a decision is made if it is not settled in one meeting and then new stakeholders arrive and have their own thrashing out to do.) And even with one final decider, you can end up a bit still with "Design By Committee" decisions when the final decider goes along with the group consensus or doesn't have a strong point of view on an issue.

[Aurornis]

> I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.

Getting measured feedback is good when it’s coming from a place of genuine helpfulness.

I’ve been in multiple companies where, for various reasons, feedback rounds turned into a game of being maximally contrarian. It didn’t matter what you proposed, a few people would make it their mission to fabricate some objections and come up with reasons to rewrite it into something else. It was a way of exerting control and stealing ownership/credit by replacing others’ ideas with your own.

The most frustrating situations were when you’d rewrite something to accommodate some staff engineer or manager, then at the feedback session for the review they would complain and propose your original version, seemingly forgetting that they had rejected it once previously.

[solatic]

100%. Three decision-making styles are dictators (make decisions without feedback), arbitrators (listen to feedback, then the arbitrator makes the call), and mediators (mediators guide discussion until consensus is reached). Arbitrators are far and away the most successful and best liked. The key insight is that a culture of arbitration is not natural and must be intentionally built.

[danielmarkbruce]

Collaborate has a reasonably well defined definition, approximately:

"To collaborate means to work jointly with one or more people toward a shared goal or project, especially by contributing ideas, skills, or effort"

What you are talking about isn't collaboration, it's feedback. You have the goal, it's your thing to do.