Collaboration sucks

I often explicitly discuss roles. Who is responsible for a feature (must be exactly one person). Who will have input (without veto power), who will have input (with veto power), who is the “decider” if the responsible person gets vetoed and they don’t agree. Setting up all of this early (and keeping the veto list as small as possible) makes collab a million times easier.

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.

I'll admit that some of this resonates with me, but as a line-level manager at a HUGE tech company, there are severe limitations on how much I could implement this philosophy.

This sounds like a really good excuse to not bear any responsibility for anything other than what you want to work on. PR reviews will mean nothing; they will all be rubber stamps or style nits because no one else will understand the code other than the owner. Your bus factor will be crazy low.

Collaboration sucks because of the way it is done, not because it has to. Pointless meetings for decision making that should be async. Brainstorming over Slack when that's what a meeting is actually good for. Looping people in to collaborate at the end instead of at the beginning. This is all possible to fix.

What I do is have everyone work in pairs. Pairs are small enough that communication is easy and there's no design-by-committee. But there's always someone to have your back and help when you get stuck or bogged down (e.g. decision fatigue), which happens plenty even to senior engineers. The pair starts and finishes work together, which mostly eliminates the need to loop someone else in randomly and needing to explain the thinking and background context, because they can bounce ideas off of each other and leverage each other's different areas of expertise. Whatever the end result is of that collaboration is treated as a finished unit of work, it's already been looked at closely by two people, it doesn't need a complicated approval process. The automated tests run, the release manager looks for any obvious mistakes, and then it ships.

The hardest nut to crack is the "who is the driver and who is the navigator" problem. I find that it is best to leave that up to the pair to work out for themselves, since it depends on the personalities involved. But with some guidance to not step on each other's toes. Working on the same line of code at the same time constantly is clearly the "too much collaboration" extreme that the article's author dreads. It's better if one person designs while the other codes, or one works on the logic while the other does the TypeScript types, etc. Usually the pair struggles with this for a week or two and then they develop a groove and it's rarely a problem after that. Spontaneous or infrequent collaborators never reach that groove, hence it can be inefficient and frustrating. Long-term pairs get to know each other and then work fast and smooth.

That’s the only way I would utter it — if I can then sit down and so do it. If I am asking someone else to do I would ask them to tell me how hard it would be and if they need help or if they suggest a different approach.