Collaboration Sucks

and man i wish i could go back in time to when i merely thought the "Globetrotters vs Lakers" thing was just a ham-fisted phrasing some sentiment along the lines of "the Lakers are better than the Globetrotters"...

but, unfortunately, i "took one for the team" (read: "collaborated with the team"), and am now dumbstruck as to what could possibly have been meant by this metaphor. for those of you who have yet on this fine day to regret the dual, magical gifts of sight and literacy: apparently the Globetrotters and Lakers played an exhibition match of some sort in 1948. the Globetrotters won 61-59. and it was apparently some sort of watershed moment in America's collective realization that Black people are actually also good at basketball. i wish this was merely my being grouchy, glib, and reductive. but just read the Wikipedia article: that is literally what happened and what it meant. in historical context. that, and nothing more, is the object lesson so signified.

so, now that i have made peace with my dual inabilities to magically unread and unlearn, pray tell: who are the metaphorical Black athletes being discriminated against, metaphorically, in this... metaphor? is the implication that Tammy from HR or Chad the BizDev Bro are better designers than Klaus from the Bauhaus? is it that the Lakers "played together less" than the Globetrotters? surely it can't be that there was a giant societal misapprehension (read: racism) that caused people to systematically misevaluate talent and, as sports experts as you say, pass the wrong people the ball? if only the Lakers had collaborated more, they could have overcome their systematic racism that blinded them to the basketball nous of their fellow man! now that would have made a great sports movie. for 1948. because otherwise it sure seems like it is not only an argument in favor of the most abjectly banal-at-best-and-insidious-at-worst flavor at the Baskin Robbins of collaboration. "French Vanilla" collaboration, as it were. But whereas Vanilla at least has a certain je nais se quois in its blandness-- a certain out-of-fashion purity not too dissimlar from how even a now-octogenarian would view that barely-contemporaneous time and episode— this canvas is painted with subtractive colors, producing a tastes-worse-than-even-its-shitly-pallor-would-suggest goulash.

anyway, so back to basketball. the point of "playing together more" isn't so that the 7'2" defensive savant who can't pass nor make a basket from further than 5 feet away from the rim gets more touches at the top of the key. it's so that everyone from the stars to the role players know exactly what their job is and, CRUCIALLY, what it isn't. if you can't shoot and can't dribble at the level of an all-conference Point Guard, go stand in the dunker spot or set a screen or both. literally anyone who isn't a top 25 point guard in the NBA cannot be trusted to dribble more than three times without dribbling off their foot and turning it over. and there's no shame in that: Klay Thompson scored 60 points in a game while dribbling a grand total of 11 times.

collaboration of the kind the OP describes, and somewhere between endemic and pandemic in the corp-o-collab-o-sphere isn't of the "oh wow that Capital Markets person we hired is actually even better at UX than at their real job" variety. it's a bunch of people just throwing shit at the wall to see what sticks with absolutely no context and nary a second thought. because why should they? it's not impossible that there's a Good Will Hunting out there cleaning off the whiteboards and wiping down the Kombucha kegerator; to condescend that it is at all likely to bear fruit is the height of arrogance. wouldn't have been a very compelling movie, otherwise.

and yet your contention is that it's not that these people have too much time on their hands, it's that they don't have enough! pull aside your friendly neighborhood designer sometime and ask how thankful they are that everyone seems to have opinions on design because people seem to think that having eyes and a mouth are the only prerequisite qualifications for being a designer. good design collaboration: "hmm i think the font sizes between these views are a bit inconsistent". bad design collaboration: "hmmm... i think it just needs to 'pop' more".

high-performing collaboration looks like Watson and Crick, Jeff Dean and Sanjay Ghemawat, or The Beatles. not design by committee-of-people-who-have-no-particular-insight-and-don't-even-care-they-just-want-to-be-seen-to-be-collaborative. There is a specter haunting corporate america-- the specter of conspicuous collaboration.

EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework

If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them.

They’re letting you choke to death on your own arrogance and control issues.

> No deadlines, minimal coordination, and no managers telling you what to do.

> In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself.

but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.

On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing.

If a manager, denotationally, can call out that there is something missing, then it was not implemented right.

Though I guess it is in tune with "no managers telling you what to do."

That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.

A great way, you say. Taking notes!

This apparently is an old African proverb coopted by the modern managerial class.

For those thinking about this issue, there are tech-specific related arguments similar to and contrary to the above. I heard the phrase from a Microsoft leader in early 2010s:

* "Heroism doesn't scale" (similar)

While I'm not sure it is completely true, there are respects in which it is deeply true (e.g. ops). It's a double-edged sword I think though; if you take the "Heroism doesn't scale" too seriously, you can suffocate out other key success drivers -- vision, innovation, motivation, design clarity/consistency, etc.

There's also (Fred) Brooks's Law (from Mythical Man Month):

* "Adding manpower to a late software project makes it later." (contrary)

I.e. there are limits to how many people "going far, going together" works for fundamental communication/coordination reasons.

P.S. There are also similar debates about optimal authority/responsibility/coordination across various military cultures, e.g. search for "military command".

Only if everyone is toward the same direction.

Not when one tries to redesign a new boat and the other person tries to row forward.

The popular "Thinking from the first principle" often leads to redesign a new boat. This is where it gets problematic.

Let people know if you have a requirement on layout and enforce it. Code review is far too late.

If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.

So if I deliver a feature all by myself quickly and move on to something else, I’m digging a bigger hole and faster than the wisdom arrives to change directions.

But most importantly, none of the rest of you fuckers know what I built or why, except what you gleaned from standup or whatever docs I wrote in place of collaboration. And docs written without collaboration are usually hot garbage.

So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.

Ask anyone in a relationship if their partner complains about unimportant stuff. With experience and practice you can get past this stuff.

so... experienced reviewers.

Other commenter point at auto-formating, but I think companies not using any are pretty rare, hitting that very issue in several companies is highly improbable.

We're probably down to function/variable naming, ternal operators, return types, this kind of thing ?

Someone who can't bother looking around and adapt their style to the surrounding code sounds like a problem to me. What is seen as pendantic and nitpicky can have pretty large impact on readability and go against others' assumptions.

This is not a "culture of collaboration" by any means.

Vs Boss: "your call"

The meaning the article is using is that there’s an owner, and they own the project without dilution. There’s not death by committee. One person or one team is given something to do, and they go do it without interference from the rest of the company. Whether what’s delivered at the end is fit for purpose is open to other people’s opinions and input. How it gets implemented and reaches delivery is the exclusive concern of one person or a very small group.

By the time a race engineer is communicating with a driver all of that has been shaken out. Specific concrete options are given to the driver, and usually only one.

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.

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.

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.

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.

"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.

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.

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

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.

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.

Posthog is obviously successful. The design is good enough. But is it perfect? nah. would a better design make it more successful? highly doubt it.

If we were to take this feedback seriously, then we would've halted the launch and redesign the site. Now imagine having 10+ feedback like this. This would significantly delay the launch which would impact the success in a significant way.

Agile in general and Scrum in particular don’t want to declare things as done when they aren’t and if you haven’t yet given feedback, is it really Done? I don’t think it is.

With Scrum the pressure to put away the done thing and start something else is very high. The moment you start thinking about your next story, unless it’s very closely related to the previous, your ability to accept feedback becomes quickly curtailed.

This is half of the point of Continuous Integration. Fast feedback is often the only feedback that causes behavioral changes. Things that happened a while ago become abstract. Think about a conversation you’ve seen where someone describes how another person hurt their feelings yesterday, versus five years ago. The reactions are very different.

So if you enjoy talking, I suppose it “works” for you but if you hate having to give the same correction over and over, you need to make the person stop and go back until they learn how not to get stopped. Anything else loses the war.

Any meeting with more than 3-4 people (and maybe even less) is probably a waste of time.

Creating a PR doesn't mean everyone just accepts whatever change you've made. But it certainly gives something unambiguous and tangible for people to form their objections around. Rather than objecting to some misinterpretation of the idea in their own head.

IMO the best way is to split your organization into units that nicely map with technological/business boundaries, and then give each unit the responsibility to own something tanglible. The problem is, if the organization is full of idiots, everyone tries to do the opposite, in order to diffuse the responsibility.