Live data from Hacker News

Collaboration sucks

newsletter.posthog.com

221–230 of 262 posts

Re: Collaboration sucks

#221
Bureaucracy was originally intended as an idyllic ideal: everything would be written down and everyone’s job made clear, so everyone could get the info to do their bit and just get on with it.

And all collaboration that will be needed is perfectly anticipated then shifted to compile time by being designed into the system on day one. Everyone just does their bit and the whole thing functions perfectly, because the designers anticipated everything.

So yeah, no need for collaboration

/s

Re: Collaboration sucks

#222
post #36

> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw). Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively…

One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.

"Just decide for yourself and be self-reliant... no, not like that!"

Re: Collaboration sucks

#223
post #145

Earlier quoted context omitted.

> 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? That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.

> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?

Then your team is too big. If you have more than, say, 7 people in a planning, your team is too large.

And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins..

It's not perfect, but if you're gonna do planning, just do it properly.

Re: Collaboration sucks

#224
It‘s basically just another way to describe the working doctrine Amazon follows since 30 years (and which Stripe has also mimicked according to Patrick). It bascially allows every individual to make decisions on their own (within their scope), without appproval. Except decisions that can not be undone easily, those still need „collaboration“.

Re: Collaboration sucks

#225

Praising people for saying "it's your call" and in the same article boasting about "extraordinarily high ownership" is simply laughable. The two are literal polar opposite.

What do you mean? If I really own something, it's my call.

Re: Collaboration sucks

#226
Collaboration is the activity of a group of people to create and maintain a shared understanding of a problem in order to solve it.

The author addresses issues that I would not relate to the concept of collaboration as a specific type of groupwork.

Re: Collaboration sucks

#227
Collaboration is when all want to get to the same place and take unplanned turns to drive while the others are sleeping and a hitchhiker you picked up on the ride drives you over the finishing line.

And it's beautiful when that happens.

Re: Collaboration sucks

#228
post #145

Earlier quoted context omitted.

> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?

Then your team is too big. If you have more than, say, 7 people in a planning, your team is too large. And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins.. It's not perfect, but if you're gonna do planning, just do it properly.

> And it's never really asynchronous. It's more honest to block everyone who might have input.

How? Even if you decide you need everyone to look at it, letting everyone check it off asynchronously is more respectful of people's time and concentration. Maybe occasionally there's a big difference in people's assessment and you need to have a synchronous discussion, but there's no need to pessimize the common case for the sake of the rare case.

> It's not perfect, but if you're gonna do planning, just do it properly.

What's "properly"? Doing your planning in a more difficult, time-consuming way might feel virtuous, but it's not actually beneficial.

Re: Collaboration sucks

#229
I agree with some of the points here, but I roundly disagree.

Agree with: people are employed to do a job, they should be empowered to get on and do it with minimal supervision, escalation, and distraction (particularly from "PR Theatre"). Also agree that sometimes unity of vision and focus time can yield exceptional results.

However, this doesn't work unless you can work every part of a system with a high-level of alignment with vision and commercial context to make good decisions and you test mercilessly. I know, have worked with, and still work with, an "entrepreneurial developer" type who can do that, but over time their "isolationist" approach leads to misaligned features that are usually anathema to good by the end of the startup phase.

Additionally, the ability to work with that level of alignment and autonomy simply doesn't describe the majority of the developers on the market and who really just want to be given tasks in their area of skill. Are they acceptable for a startup? Probably not. But in the SME context that's fine because collaboration fills the gap.

Also, while there is a lot to be said for T- and V-Shaped engineers, I-Shaped engineers are much more common and that's not a bad thing because – if one can get a designer, fe, be, and operator collaborating _effectively_ – you can still get good results.

Re: Collaboration sucks

#230
This only works if everyone on the team is VERY good at what they do. I have worked in plenty of teams where it was absolutly necessary to collaborate, lest people just go ahead and implement some horrible solutions.

I've seen the opposite problem many times. Someone has confidently implemented something terrible, and I'm just thinking, why didn't you ask anyone about this!

Posthogs solution seems to be to "only hire very good people". Which is kind of funny to me. That might be possible in a hip company working with exiting new tech. But for many companies such as "boring" companies with old outdated stacks or start ups with no money, that just does not seem to be possible, at least in my experience.

Post reply on HN