Live data from Hacker News

Collaboration sucks

newsletter.posthog.com

201–210 of 262 posts

Re: Collaboration sucks

#202
The problem with no collaboration is that it can lead to fragility. Context transfer is costly, but without it work bottlenecks around key individuals. When those individuals are explicitly disincentivized to transfer knowledge preemptively, you lose the slack in the system. Vacations and exits become more fraught. Deadlines are harder to hit reliably. You have less systemic resiliency.

Instead, encourage targeted collaboration (in particular, pairing: collaboration with a goal of accomplishing something) within the scope of a team, and avoid cross-team collaboration, which is the expensive part.

Re: Collaboration sucks

#203

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…

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

Re: Collaboration sucks

#204
post #103

I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really…

And PostHog does that too with [RFCs](https://posthog.com/handbook/company/communication#requests-...) when you require some sort of smart collaboration. The way I read OP's post is not about isolation, but rather about trust.

Re: Collaboration sucks

#205
The basic insights seem similar to Fred Brooks The Mythical Man-Month (1975), Brooks' Law: "Adding manpower to a late software project makes it later. " https://en.wikipedia.org/wiki/The_Mythical_Man-Month (the book is worth a read still today! Some of the essays you'll skip or skim, others will strike you to your soul).

But OP seems to take it to a ridiculous extreme. Discouraging even asking questions of someone who might know more about what you are into than you do? Discouraging any and all collaboration entirely?

I wouldn't want to work there.

All things in moderation and reasonableness. Contrary to the opening hook, I think humans actually are meant to work together, we evolved that way.

I want to have autonomy and independence and be able to ship things and use my judgement and not drown in beureacuracy and I want to work with people collaboratively where appropriate and useful, with appropriate roles and sized teams and responsibilities, and clear owners of each piece. You actually can do both?

I agree that clear owners/decision-makers is key.

Re: Collaboration sucks

#206

The author talks about having a clear bias for action (a great thing!) but in the process throws the baby out with the bathwater. Without collaboration you'll end up with silos, overconfident decision-makers, and all sorts of preventable production issues, all in the name of avoiding the dirty C word. How about following the approach of pragmatism and finding a solid middle ground that achieves the best results longt…

The culture of feedback has the infected your brain. The "strong objections" framing is just collaboration cosplaying as decisiveness. You're still waiting for permission, just with extra steps and passive-aggressive phrasing designed to shame people into silence. It's corporate theater. You've invented a mechanism that still makes one person wait on others, fragments their attention, and creates the expectation that…

First of all, just because you (or the author) call collaboration a bad thing doesn't make it so. Secondly, you seem to have misunderstood the process. The steps are: I will be shipping shortly, here is the direction I decided on because XYZ, if you want to react there is some limited amount of time to do so but those objections better be nontrivial. There is no waiting for permission, the path is set - yes, barring strong objections. Apparently you think it's best to leave those for after the fact, well, good luck with that.

Re: Collaboration sucks

#208
post #76

>>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process. Don't confuse this with "Don't test and don't do code reviews"

The line you quote is oddly one of my strongest arguments against Scrum. 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 relat…

In my teams, I try to pre-empt as much as possible by getting feedback from users on mockups. And then the item is "done", only when product verifies the core flows before it goes to production. I don't do Scrum/sprints (I think it puts artificial timelines and unnatural item splits) , but more aligned with Kanban (this gives me never-ending grief about quarterly releases, QBRs etc, but thats another story). So we try to make what's "done" fairly well defined. Does this slow down shipping? A little bit. But in practice, we end up shipping something at least a couple times a week.

We used to play a bit fast-and-loose with what's defined as "done", and that allowed us to ship everyday, but the loose part of that invariably came back from our customers, at a much higher cost. So we went back to being a little more rigorous.

Re: Collaboration sucks

#209
post #203

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…

> 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…

GAF score sounds like a great idea!

Re: Collaboration sucks

#210
post #87

Earlier quoted context omitted.

We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average. It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both. But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that…

> You can blame Taylor for that. No, you can't. Taylor was a huge advocate for standardizing people's work so it could be studied and improved. He was also an advocate for well-studied people to go and teach workers how to do their jobs, and a not intense advocate for thinking ill of workers based on everything you can expect from a rich 19 century guy. What he advocate a lot against was doing power games against wor…

Standardizing people’s work turned them into automatons to be studied and improved by a management elite.

Which all came crashing down when Deming had to go to Japan to get people to listen to his ideas and triggered a massive recession in the US.

Deming and (to a lesser extent) Goldratt pull the employees back into the conversation. Tether are closest to the problem and even if they can’t solve it, they can help you shape the answer. Taylor was neofeudalism and he can rot.

Post reply on HN