[HN Gopher] Collaboration sucks
___________________________________________________________________
Collaboration sucks
Author : Kinrany
Score : 224 points
Date : 2025-11-11 20:27 UTC (2 hours ago)
(HTM) web link (newsletter.posthog.com)
(TXT) w3m dump (newsletter.posthog.com)
| ssalmon74 wrote:
| Gravitational Pull" is the solution!
|
| Instead of the "Collaboration Sucks" approach, we need to apply
| Gravitational Pull. For every key project, the Driver defines
| three essential stakeholders (e.g., Tech Lead, Business Owner,
| Target User) who form the "Quantum Sync Circle."
|
| Everyone else is noise. This prevents endless discussions and
| focuses accountability right where it belongs.
| kevinob11 wrote:
| "Instead of the "Collaboration Sucks" approach, we need to
| apply Gravitational Pull. For every key project, the Driver
| defines three essential stakeholders (e.g., Tech Lead, Business
| Owner, Target User) who form the "Quantum Sync Circle." - this
| sentence had me so freaked out with all of its buzz words, but
| man I think I really strongly agree with it. I love the
| inclusion of target user!
| kingforaday wrote:
| If this takes off, I think you've coined a new term there with
| "Quantum Sync Circle."
| agildehaus wrote:
| The Conjoined Triangles of Success
| bryzaguy wrote:
| I would argue the opposite. If your collaboration sucks IMHO you
| haven't done enough. It's a skill. Imagine you're playing a team
| sport and you recommended people play together less to win more
| games. Now look up Globetrotters vs Lakers.
| sfpotter wrote:
| Programming isn't a sport.
| bryzaguy wrote:
| I didn't say it was.
| singron wrote:
| I think the sports analogy would be passing the ball back and
| forth in front of the goal instead of shooting. Nearly every
| time, an athlete with the ball in front of an open goal will
| take the shot themselves instead of passing. Even in a 2v1
| situation, passing is a huge risk and taking the shot has a
| high likelihood of scoring, so you only want to pass if the
| defender is leaving your teammate open (usually they split the
| difference, so it's complicated). Too many passes in a 2v1
| guarantees that more defenders will show up and you lose your
| advantage.
| bryzaguy wrote:
| I'm just thinking in terms of coordination between people as
| a skill and using a basketball team as an example.
| keeganpoppen wrote:
| it's funny because the facile sportsball analogy actually fails
| horribly here. "playing together more" is the absolute last
| thing that the undifferentiated mass of hundreds of people
| hitting the like button on a random nonsensical comment need to
| do more of. the _only_ situation where collaboration of this
| sort is productive is when you cannot reasonably expect any
| other participants to have some sort of proprietary knowledge
| over their domain. think contestants on Survivor trying to put
| a puzzle together faster than the other team to get an immunity
| idol, not "i'm gonna mansplain Calculus to Terence Tao".
|
| 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.
| mcdow wrote:
| I've used both approaches and I can't disagree more. Writing code
| first might feel faster but it isn't. It's great for surface
| level issues but just muddies the waters for any consequential
| feature.
|
| Measure(communicate) twice, cut(build) once.
| mrkaye97 wrote:
| IMO this is very dependent on the risk of cutting once, so to
| speak. I'd imagine that at PostHog, the idea is there's little
| risk of cutting many times - iterating - and more damage is
| done by the measuring taking far too long.
| mcdow wrote:
| This is true but there is another cost. If you carelessly
| write you can end up with a system which is a mountain of
| bandaid fixes; an incoherent and unmaintainable mess.
| john_moscow wrote:
| If you know how to get stuff done yourself, start your own
| company, get stuff done, and enjoy the profits (or losses,
| depending on how good you are). It's your risk and your reward.
|
| If you are working for someone else, the unwritten rule #1 is
| that a single employee should not amass too much influence within
| the company to start dictating their own conditions. So, the
| management culture averages decisions across multiple people, to
| make sure the loss of one-two team players won't be noticed.
|
| It can be extremely demotivating if you are smart and capable,
| but these are the rules of the game. Be nice, get paid,
| accumulate some savings, make connections with other smart
| people, learn the market, and eventually start your own game on
| your own rules. Until then, trying to stand out will get you
| labelled as a troublemaker, and will hamper your progress in the
| long run.
| kykat wrote:
| good advice, someone should have told me this years ago, when
| you start, you need to know that this is not your game, work,
| watch and learn. Don't even think about "this is wrong" "they
| should do this instead" "they have no idea" "I would do it much
| better"
| throwaway713 wrote:
| > 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 request your report to
| go back and make changes. This is a great way to lose employees.
| kykat wrote:
| At my previous job, "what about..." slowly became a trigger
| word for me
|
| EDIT: In the context of infinite pixel tweaking, layout
| tweaking, and of course, new features that would require
| significant full stack rework
| hinkley wrote:
| The four worst words on a software project are: "Why
| can't you just..."
| fullofideas wrote:
| Closely followed by "This should be an easy lift"
| Aperocky wrote:
| I mutter this a lot. Except when I do 95% of the time I
| perform the easy lift right after.
| neilv wrote:
| "Delivering this feature goes against everything I know
| to be right and true. And I will sooner lay you into this
| barren earth, than entertain your folly for a moment
| longer."
|
| -- Krazam, "Microservices",
| https://www.youtube.com/watch?v=y8OnoxKotPQ
| marcusb wrote:
| I once worked at a place where one of the partners
| consistently claimed the engineering team over-built and
| over-thought everything (reality: almost everything was
| under-engineered and hanging on by a thread.)
|
| His catch phrase was "all you gotta do is [insert dumb idea
| here.]"
|
| It was anxiety inducing for a while, then it turned into a
| big joke amongst the engineering staff, where we would
| compete to come up with the most ridiculous "all you gotta do
| is ..." idea.
| 0x457 wrote:
| Have WE tried using caching?
| theideaofcoffee wrote:
| Similar to my experience doing low-level systems work, being
| prodded by a "manager" with a fifth of my experience. No, I'm
| not going to implement something you heard about from a
| candidate in an interview, an individual whom we passed on
| within the first 30 minutes. No, you reading out the AI
| overview of a google search to me for a problem that I've
| thought about for days ain't gonna work, nor will it get us
| closer to a solution. Get the fuck out of the way.
|
| "Can't we just..."
| CBLT wrote:
| I'm there right now at my current job. It's always the same
| engineer, and they always get a pass because (for some
| reason) they don't have to do design reviews for anything
| they do, but they go concern-troll everyone else's designs.
|
| Last week, after 3 near-misses that would have brought down
| our service for hours if not days from a corner this engineer
| cut, I chaired a meeting to decide how we were going to
| improve this particular component. This engineer got invited,
| and spent thr entire allocated meeting time spreading FUD
| about all the options we gathered. Management decided on
| inaction.
| bfkwlfkjf wrote:
| I just gave this feedback to my boss today
| tombert wrote:
| 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.
| AceJohnny2 wrote:
| One of the many reasons I'm still at Apple. My manager honors
| my decisions (sometimes, let's be honest, with gritted
| teeth).
|
| ("People don't leave jobs, they leave managers")
| JKCalhoun wrote:
| Yep. There are many, many teams at Apple. Your manager
| makes all the difference in the world. Hated working on the
| Photos team at Apple, loved all the other teams I worked
| on. (So I left the Photos team to go work on a team where
| the manager was cool. I was able to stay at Apple, just
| move about.)
| IshKebab wrote:
| I normally move _within_ a company when I want to quit a
| manager. It 's much easier than getting an entirely new job
| usually. And you have a lot more information about the
| potential role.
|
| It's also a good way to get into areas you have no
| experience of.
| 867-5309 wrote:
| one tactic is forming a group which bullies a manager out
| of their job. it's depressingly effective and rife within
| the professional public sector
| jstummbillig wrote:
| > This is a great way to lose employees.
|
| A great way, you say. Taking notes!
| hinkley wrote:
| There are worse outcomes than that. Software devs are clever
| people. Not all of us can be confrontational, and confrontation
| is not the only tool available to those who can.
|
| 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.
| ninetyninenine wrote:
| Software devs also all think they're smart and they talk that
| way and take pride in it. The reality is many software devs
| are dumb af.
| binary132 wrote:
| "trust nobody, not even yourself" applies here for sure.
| hinkley wrote:
| 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.
| appreciatorBus wrote:
| Developers may be hired for cleverness, but cleverness in
| code and technical matters does not necessarily carry
| over into cleverness with respect to office politics or
| good management.
| hinkley wrote:
| Management often spends less time with the users than we
| do.
| ninetyninenine wrote:
| Cleverness in code actually correlates with cleverness in
| social aspects. People come up with this artificial
| dichotomy of the awkward nerd with high iq but zero
| social skill but the reality is both of the two correlate
| slightly.
|
| At the very least we know there isn't an inverse
| correlation meaning the stereotype isn't really true.
| InexSquirrel wrote:
| Hired for ultimately a fairly narrow field of expertise.
| But do need support in the sense of building the right
| thing, ensuring that thing aligns with business
| objectives, that constraints and requirements and
| customer needs have been communicated.
|
| So in that light - either you give engineers the support
| they need (which can be quite a lot, more than I think
| most care to admit), or accept they're going to get a lot
| of stuff wrong. Probably technically correct and good,
| but still wrong.
| ninetyninenine wrote:
| It's not clever to brag about how smart you are or imply
| you and your entire cohort are smarter than other
| occupations. It's a sign of how much you are the opposite
| of clever.
|
| Additionally the average IQ of software developers is
| measured to be 110-113. That's barely above one std of
| the average so you're actually wrong. Software devs
| aren't particularly clever but a disproportionate number
| likes to think they are smarter than normal.
|
| So bragging about something that you're completely wrong
| about... is that clever? No.
| ergocoder wrote:
| The equivalent of "I told you so". Yeah, you should never do
| that in any situation.
| petralithic wrote:
| Exactly, these two sentences seem at first related,
|
| > _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.
| codegeek wrote:
| "Unfortunately for me, not all collaboration can be rooted out,
| and even I will admit that some collaboration is useful. Ian and
| Andy edited this newsletter after all."
|
| So "good" collaboration does work. It is just that the post is
| talking about things that are not really true collaboration and
| those should be avoided. Title is click bait but posthog is
| famous for these.
| jdauriemma wrote:
| Framing obvious/old ideas in a novel way can be helpful.
| "Collaboration" is a meme that makes it easy to view all
| collaboration-shaped exchanges as helpful and the opposite as
| harmful. A memorable counter-narrative can help people think
| more critically when faced with an applicable situation.
| asdfman123 wrote:
| The problem is design by committee.
| mnsc wrote:
| But the click bait was conceived and written super fast by a
| daring driver!
| snackdex wrote:
| damn. super cool that posthog is acknowledging the pains of
| growing even at their scale.
| kristianc wrote:
| "If you want to go fast, go alone; if you want to go far, go
| together"
|
| I've often noticed that this is a favourite phrase of those whose
| preferred motion is narrating other people's work rather than
| doing it themselves. Teams do go further together. But only when
| everyone is rowing.
| slacker7081 wrote:
| In the original article the author says "ultimately leads us to
| ship less." as one of the drawbacks to collaboration. Says a
| lot really, if quantity of features shipped is a priority.
| Great way to build a feature factory, everyone shipping without
| feedback and having others question what you are doing.
| ergocoder wrote:
| > But only when everyone is rowing.
|
| 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.
| devin wrote:
| This feels silly. I think this is just "ask for forgiveness, not
| permission" but made more clickbaity.
|
| It also borders on a kind of edgelord attitude that I've seen
| from people who I wish not to work with again.
| jesse__ wrote:
| While I don't agree with Charles' (clearly nuts) distaste for
| sparkling water, I'm happy to see people finally talking about
| this issue publicly.
|
| I've suffered through this at several companies, down to the
| level of sometimes spending like 3x the time it took to implement
| the actual feature on answering and 'fixing' pedantic stylistic
| nitpicks during code reviews. While having a homogenous style is
| important, I'm solidly in the camp of "if you want to give me
| style nitpicks, just change them yourself, tell me, and save us
| both some time". This extends to like 80% of feedback I see in
| code reviews.
|
| Be weird and do stuff. https://www.youtube.com/shorts/DjvVN4Vp_r0
| happymellon wrote:
| Have a formatter. There are plently out there that can be part
| of the compile/build/commit flow, to the point of failing
| pipelines if the files you changed not match the style.
|
| Let people know if you have a requirement on layout and enforce
| it. Code review is far too late.
| bitexploder wrote:
| Where I work the formatter is the final arbiter of formatting
| code. If you don't like it, good luck justifying a change and
| you had better have really thought about it and why your
| change is good, because thousands of engineers have tried and
| been defeated for one reason or another :)
| thisrobot wrote:
| amen. i don't really care about style/format. my opinion is
| that if you care you should automate it.
| joaohkfaria wrote:
| This has no relation with collaboration. Being nitpicky about a
| PR is wrong, you should have a linter or enforce the culture of
| not being nitpicky about code.
|
| This is not a "culture of collaboration" by any means.
| hinkley wrote:
| Every delivered feature is a liability not an asset.
|
| 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.
| fhennig wrote:
| > Every delivered feature is a liability not an asset.
|
| > 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.
|
| You're mixing up the feature and the moving parts.
|
| A feature is an asset. Moving parts (or code) are the
| liability. They are not the same.
|
| Sometimes you can even improve the product by removing code,
| or refactoring things so you have less or clearer code while
| at the same time improving the product. Maybe you unify some
| UI, so more functionality is available in more places, while
| also cleaning up the code, maybe reducing line count.
|
| > 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.
|
| It's a fair point, but depends on the scale I would say. Some
| smaller things can be easily understood (but maybe that's not
| the stuff that causes the cluster to be on fire). Also, IMO
| at least one person should have reviewed the stuff, and
| therefore be at least a little bit knowledgeable about what's
| going on.
| hinkley wrote:
| > You're mixing up the feature and the moving parts.
|
| No, you are, and this is why so many of us are shit at UX.
|
| The ability to accomplish a task with software is an asset.
| Not every application takes the same number of interactions
| to finish a task, and each interaction is a feature.
|
| Features in neither waterfall, scrum, nor Kanban directly
| correlate with the ability of the user to accomplish
| something meaningful. They are units of measure of the
| developer accomplishing something meaningful, but the
| meaning is assumed, not real.
| petralithic wrote:
| > _Every delivered_ feature _is a liability not an asset._
|
| > _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?_
|
| Wrong analogy, use the word _feature_ in both emphasized
| terms. Consider two products and one has half as many
| _features_ , which is more profitable to maintain? Well, it
| depends whether people are paying for the other half of the
| feature set or not, as oftentimes people will pay for more
| features than fewer.
| hinkley wrote:
| It's a perfectly fine analogy if you can get over your own
| ego enough to realize your customers don't want to hear
| about how very clever you are, they just want to get shit
| done and move on to four other tasks.
|
| They don't care about us. They don't. They just want to do
| what their boss asked them to do or kill the bad guy to get
| the treasure, and we are often enough as much in the way as
| we are facilitating that.
| m463 wrote:
| Can't help but think this is human nature.
|
| 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.
| makeitdouble wrote:
| > style nitpicks
|
| 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.
| lionkor wrote:
| Even more than that, it means the developer has spent no time
| understanding the surrounding code, and thus is likely adding
| debt/CRUFT/risk.
| iLoveOncall wrote:
| 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.
| willsmith72 wrote:
| not at all. me, owner of a new feature: hey boss wanted to get
| your thoughts on this. Boss: "let's schedule a review for next
| week, and pull in x and y who are familiar with the space"
|
| Vs Boss: "your call"
| cestith wrote:
| You seem to view them as opposites because you expect ownership
| to mean that all employees are motivated to have a sense of
| ownership over the whole process. There's some benefit to that,
| sure.
|
| 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.
| klik99 wrote:
| There's no one size fits all - what they're saying would
| absolutely fail at the company I'm currently at, but sounds like
| it works for them. The key thing is to have a process that works
| well for the people who are there, and hire people who work well
| under those conditions. The people who do well at our company
| would not do well at their company, and vice versa. I don't like
| how this article makes a claim about what works well for them is
| actually a universal truth. It really depends on the people
| there.
| upghost wrote:
| Taking the article's analogy of the "collaboration while
| driving", the F1 sport is quite insanely collaborative. For
| example, the drivers literally do have someone in their ear by
| radio being their coach and spotter for the entire trip. I've
| never heard of the equivalent in software. Does anyone know of
| anything like this?
| jiggawatts wrote:
| Pair programming.
| stevage wrote:
| That was too easy.
| outside1234 wrote:
| Github Copilot
| devin wrote:
| This is like playing both sides of the board in chess and
| claiming you had an opponent.
| leptons wrote:
| We don't collaborate, we iterate. I'm the lead of my department,
| so I sst the initial direction of the new feature, discuss it
| with my team, assign it, and let someone build the basic
| functionality. Then I'll review it, and I will pick up the code
| and move things around, refine the UX, refine the code, and then
| maybe pass it back to the developer for more changes, until we
| arrive at something really good. It doesn't make anyone unhappy
| or slow us down, and we often don't know where we're going to end
| up when we start a new feature. Things are fluid, but we have a
| goal of making things easy to use. Iteration among the team
| members also ensures more of the team knows how the code works,
| and we often learn from each other. Maybe this is "collaboration"
| but we call it _iteration_.
| onion2k wrote:
| _This sometimes leads to valuable insights, but always slows the
| driver down._
|
| In cases where the insight is genuinely useful that's better than
| going fast mostly because you were probably going fast in the
| wrong direction. Ideally you would optimise collaboration to
| increase the likelihood of valuable feedback (because that saves
| more time and money) rather than optimizing for speed.
|
| That said, I've lost track of the number of meetings I've been in
| so that someone can cover their ass by making something a
| 'collaborative decision' instead of taking responsibility, so I
| can totally see where the author is coming from.
| brendanfalk wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| ergocoder wrote:
| 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 wrote:
| 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.
| KaiserPro wrote:
| 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
| thoughtlede wrote:
| 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.
| moralestapia wrote:
| This kills the product manager, though.
|
| That's why it still persists.
| commandersaki wrote:
| I can see how the lack of collaboration lead to the posthog.com
| website design.
| ergocoder wrote:
| This is an example of why collaboration and feedback before
| launch are mostly useless.
|
| 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.
| portaouflop wrote:
| I think it's one of the best marketing websites for a SaaS I
| know, if not the best. Taste is clearly subjective
| didip wrote:
| For real. The only collaboration that is super fast is between
| yourself and Claude Code.
| tombert wrote:
| I feel like collaboration can work great with a group of exactly
| two people. It's not terribly hard for two people to partition
| work and actively help each other. With two people working on a
| project, both people can realistically understand most of the
| codebase, and can competently review each other's pull requests.
|
| I feel collaboration suffers from combinatorial complexity
| though, and I feel any number bigger than two ends up doing more
| harm than good. Once you have more than two people, the codebase
| starts becoming more segmented, it becomes really difficult to
| agree on decisions, and the project becomes a lot harder than it
| needs to be.
|
| If I ever get into management, I think I will try and keep this
| in mind and try and design projects around two-people teams.
| patrickmay wrote:
| If each person can eat half a pizza, you've reinvented the
| Amazon approach:
| https://martinfowler.com/bliki/TwoPizzaTeam.html
| throwaway7783 wrote:
| >>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"
| hinkley wrote:
| 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 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.
| CGMthrowaway wrote:
| _> 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._
|
| This works for software dev. Would be more difficult in anything
| else, where you're not constantly updating an existing product on
| a weekly basis.
| foobarbecue wrote:
| I don't think this is good advice for building, programming, or
| operating spacecraft.
|
| Edit to add detail: a spacecraft tends to have lot of subsystems
| that need to work together well, each requires a specialist lead,
| and there's a high return on investment for things like improving
| efficiency, sharing resources between subsystems, etc. leading to
| reduced power, data, and mass requirements. They tend to be
| bespoke and high value so it's critical that detail knowledge is
| spread among multiple people, edge cases are carefully
| considered, and lessons learned get learned by everybody.
| Collaboration is key in that kind of endeavour. If you're
| slapping together a CRUD app that can't hurt anyone, sure, go hog
| wild.
| manmal wrote:
| Or medical software. It's great advice for people building
| products which don't need to work correctly up into the high
| 9s.
| wagwang wrote:
| This is so dumb, its how you end up with 37 versions of the same
| thing.
| zzzeek wrote:
| wow add Posthog to Places Id Never Work
|
| "you asked someone what they thought of your approach? BAD!
| that's not our culture!"
| lonesword wrote:
| If I don't like my coworkers, I'm out. I like people who give a
| shit about the work I do (a.k.a "collaboration"). "Whatever, you
| own it" is just lazy for "I can't be bothered to understand what
| you are working on".
|
| The problem is not the collaboration, it's the ineffective
| collaboration. Maybe the author should fix that instead of
| pitching magic anti-collaboration click-bait pills.
|
| Also, the problems you solve must be pretty straightforward and
| unambiguous (or you have a small codebase) if you have the luxury
| of being able to just make a pull request for it.
| VBprogrammer wrote:
| It's obviously written in a "hot take" fashion, to be
| deliberately provocative. Taking it literally would be foolish
| but there is certainly some degree of truth in there.
|
| 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.
| usernamed7 wrote:
| Take a look at their codebase (posthog is open source) and then
| tell me again that collaboration sucks, because i feel like the
| lack of collab is why their codebase is in such terrible
| condition.
| cestith wrote:
| The dose makes the poison.
| chadrs wrote:
| Collaboration slows things down but going fast at all cost leads
| to tech fragmentation, tech debt, and product debt.
|
| fwiw I'm not in the camp of "we must have everything done in one
| consistent way" but there are places, for example a public API,
| where having 4 different names for the same concept, 3 different
| response format/url path styles, etc. starts to look really
| sloppy.
| anal_reactor wrote:
| In my company we have the best of both worlds - things are slow
| as hell and there's shitload of tech debt. This is direct
| result of "collaboration" aka "nobody actually owns anything".
| I put forward a proposal to standardize various things across
| our software, and in response my manager called a meeting of 10
| people. No proposal can survive a meeting of 10 people at once.
|
| 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.
| NumberCruncher wrote:
| Marketers ship code, salespeople answer technical questions
| without backup...
|
| ...and you dentist cuts you hair and your hairdresser pulls your
| teeth. Because everything is a trade what can and should be
| learned, except if it's related to writing and selling software.
|
| To be fair, you did not say that marketers ship working and
| maintainable code, salespeople answer technical questions without
| backup the correct way. Therefore you might be right, thought.
| TZubiri wrote:
| My girlfriend enter a new job and she told me about some scenario
| related to IT, kind of asking for my input. At one point she told
| the IT guy, who was discussing through emails or chat, that they
| should hop on a call. I told her that the IT guy probably hated
| that, but she couldn't understand why.
|
| I think speaking to people is a stressor, it's an activity that
| drains energy, like running or literally doing anything, but IT
| people can go for weeks without talking to people, so they have
| that muscle atrophied and even the slightest of real life
| interactions feels like excessive to them.
|
| This article is just peak IT. Collaboration is normal man, you
| probably didn't invent a "it's your call" solution to the
| "problem" of collaborating in companies. I wish you the best of
| luck in building your social skills.
| billy99k wrote:
| I'm not sure where you work in IT, but if I went weeks without
| talking to someone, I would be out of a job.
| criemen wrote:
| > A discussion about building a specific feature can devolve into
| reevaluating the entire product roadmap if you let it.
|
| Well, if the product roadmap doesn't hold up to scrutiny, it
| _should_ be reevaluated. Too often people commit to something,
| and then continue building it, despite the market realities
| having shifted underneath them. I see most teams not asking
| themselves often enough "should we still be doing what we're
| doing", than the opposite. The sunk cost fallacy is real.
| ergocoder wrote:
| It's called "thinking from the principle" for a reason.
|
| You will have to re-invent the whole product from the start...
| ripped_britches wrote:
| I love this, thank you posthog for being great
| krosaen wrote:
| No so much about why collaboration sucks as and argument for how
| important direct ownership / responsibility is. Good post.
| mpweiher wrote:
| It helps to go to the classics.
|
| ...
|
| Expected Benefits of Modular Programming
|
| The benefits expected of modular programming are: (1) managerial
| --development time should be shortened because separate groups
| would work on each module with little need for communication: ...
|
| _On the criteria to be used in decomposing systems into modules_
| , D. L. Parnas, 1972,
| https://dl.acm.org/doi/10.1145/361598.361623
| energy123 wrote:
| You can collaborate with smart and driven people. For the rest,
| you can "collaborate", which means doing it yourself and sharing
| the credit.
| AceJohnny2 wrote:
| > _others feel obliged to give feedback because we have a culture
| of feedback._
|
| See also "bikeshedding". Made famous by FreeBSD core developer
| Poul-Henning Kamp (phk). I see there is now a website dedicated
| to his email: https://www.bikeshed.org
|
| In short: people give feedback and quibble _because they can_ ,
| to demonstrate that they're participating, that they can
| contribute.
|
| Being aware of this habit _and inhibiting it_ is something I
| teach to every new employee in my team. (If you know how to avoid
| it always, teach me)
| IshKebab wrote:
| You don't really need to explain bike shedding to HN.
| sodapopcan wrote:
| It's quality isn't your main metric then ya, knock yourself out.
| milesvp wrote:
| I'm a little disappointed at the amount of me tooism in this
| thread. I think a lot of people here have maybe had really bad
| collaborative experiences. Maybe that's the default? most orgs
| are going to be bad at most things (tm).
|
| I can't help but think about this paper I ran across over a
| decade ago, that found a very high correlation between team
| diversity and paper citations.
|
| https://arxiv.org/abs/1803.02282
|
| This one always stuck with me, partially because of personal
| biases, but also because it just seems so powerful to have access
| to different perspectives when trying to build something. I know
| from personal experience, that when someone on my team has
| something unusual about them, when we build a thing with them in
| mind, the final product is just better. It might be related to
| the old advice of making sure that everyone's computer is
| different to make it more likely to run into bugs. Or make sure
| the devs don't have the fastest computers so they notice
| performance issues. But I also see it a lot in gaming too. If you
| tell me a game has color blind settings, that immediately gives
| me a big hint as to the quality of the rest of the game.
|
| So this begs the question to me. What is it about building with
| someone in mind that is different than the collaboration that the
| author is talking about? Like, we expect committees to produce
| spheres. And we expect bike shedding to derail meetings. But what
| is different? is it agency? is it a single vision for the design?
| There is definitely something to be said for having one person
| who really understands the problem being the one to arbitrate all
| decisions about the thing. Is it how criticism is offered, or
| maybe whether a criticism can be ignored without social backlash?
| Is collaboration really that different than customer feedback
| which is generally seen as healthy for a product?
| Ericson2314 wrote:
| I'm just going to say it's not a coincidence that this
| individualistic stuff is full of driving metaphors.
|
| Driving is one way to get around; it's not the only means of
| transportation.
| tikhonj wrote:
| > _Imagine you are driving a car._
|
| Rally races sometimes have two people, a navigator and a driver.
| The dynamic between them is absolutely fascinating. I recommend
| watching some videos because, before I saw it, I would not have
| imagined that driving a car like that would have been possible
| much less effective.
| commandlinefan wrote:
| I interpreted it as a joke, although I couldn't help but agree
| with a lot of what I think was meant to be ironic.
|
| The problem I always run into is that the potential usefulness of
| collaboration breaks the insistence on predictability: nothing
| can be done unless it can be put to, and measured against, a date
| and a timeline. Collaboration is inherently unpredictable and
| worse, spreads blame around, so there's always this insistence
| that collaboration take place in very constrained ways (usually
| in the form of pointless meetings to review line items in a text
| document that doesn't end up being very useful).
| joaohkfaria wrote:
| Everyone reading this article: Don't fall for it.
|
| There're scientific evidence that collaboration > individualism.
| Please, just search online about it. If it wasn't the case, do
| you really think every company in the world would just work in
| collaboration without any particular reason?
|
| https://atlas.northwestern.edu/wp-content/uploads/2017/03/De...
| https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/...
| https://journals.sagepub.com/doi/10.1518/001872008X375009
| straydusk wrote:
| > I disagree on some of that, but it's your call.
|
| This sucks. I can't believe they used this as an example to
| follow. "I think it's bad, but I'm not going to tell you why, I'm
| just going to say that and then tell you it's on you".
| philippta wrote:
| Reminds me of Casey Muratori's talk on Conway's Law: ,,I always
| know what I am thinking..."
|
| https://youtu.be/5IUj1EZwpJY?si=b7rG7_vemkiOL8Bp
| stevage wrote:
| This is a fun piece, though I definitely don't agree with it for
| the teams I have been in.
|
| OP seems to assume that code is better than no code. Often this
| has not been true, and collaboration has either pointed out that
| a feature already existed, or was a bad idea. So in this
| metaphor, it stopped the driver...from driving to a bad place.
| vapemaster wrote:
| You guys need to work on harder problems.
| xrd wrote:
| 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 smart collaboration and not in
| progress collaboration.
|
| Getting things done is an important metric.
|
| Getting the right things done is much harder to measure and I
| think the hive mind helps a lot with this.
|
| If you have good writing skills and can communicate well about
| what you are working on, feedback and collaboration can be fast
| and effective. And, is the only barrier to tunnel vision. You
| cannot be a good engineer without some kind of self absorbed
| focus on a problem, and you can easily lose sight of the forest
| in the trees when doing that. Without collaboration it is
| unlikely you can pull yourself at the optimal time.
|
| "Perseverance bias" or "sunk cost fallacy" and "cognitive
| entrenchment" are not mentioned in the article, but they should
| have been.
|
| We've lost focus on the importance of good writing skills and
| good communication skills. AI is going to make that so much
| worse. If you can effectively communicate in progress tasks, many
| of the collaboration problems described here can be avoided.
| bunderbunder wrote:
| I worked on a team that did something like that for important
| stuff. (We didn't bother for the relatively routine or
| uncontroversial changes.) Although in our case we did it in a
| team meeting rather than asynchronously.
|
| It really was horrendously valuable. Many, many times someone
| would save a their teammate an ungodly amount of time by
| pointing out an easier way to do something. It was a big
| complex system so naturally none of us could be expected to
| know every nook and cranny.
| lionkor wrote:
| > 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.
| anthonypasq wrote:
| scrum planning doesnt usually get too nitty gritty on
| implementation details in my experience if you dont want the
| meeting to last 4 hours.
| lmm wrote:
| > 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?
| hinkley wrote:
| I'm shocked this title is coming from a PostHog employee but more
| shocked that is seems to be relating not his experiences but a
| shared one. But as I read I quickly noticed a problem.
|
| Charles isn't describing Collaboration.
|
| He's describing people being voluntold to seek validation from
| other people. That is politicking and blame diffusion and has
| fuck-all to do with collaboration.
|
| Collaboration is a small number of people reaching a consensus on
| a thing, understanding how and why the decisions were made, and
| executing on those decisions. All of these things are necessities
| in a 24/7 operation. You need a bus number on everything and how
| are you going to get a bus number without collaboration? It can
| be done but it's slow. Often painfully so.
| sethammons wrote:
| This is simply an awful thought piece and is wrongheaded.
|
| The problem is not collaboration nor feedback. It is the lack of
| a decider. Deciding by committee is a bad way to run as an org
| grows. Collaboration is still key.
|
| One person needs to be the person who decides. Decides what? That
| is the trick. The further down you push decision making, the
| faster things go. But someone is the decider, not a group.
| sibeliuss wrote:
| Yes, exactly. In many cases you don't exactly need to involve
| the whole group but without a decider things stall out. And
| suddenly getting a decision about something looks like
| "collaboration", and gets struck down by the great confusion
| which is this authors take. It's a lack of decision making,
| simply put.
|
| Articles like this are quite poisonous, because they take
| language and mutate it for purposes that aren't quite sincere,
| and then next thing you know something necessary and good is
| worthless.
| romanhn wrote:
| 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 longterm? I
| suppose that doesn't tell a great story in company all-hands and
| corporate blog posts.
|
| On the bias for action front, one trick a previous company
| implemented that worked wonders was stating (in Slack, meeting,
| whatever): "I'm planning to do X, any strong objections?". The
| strong objection part generally dissuaded most lazy bike
| shedding, especially if paired with "do you really feel strongly
| about it". Of course if people do, then you have a discussion,
| but most of the time it's a thumbs up and off you go.
| fhennig wrote:
| I think the car analogy is great and also even shows that some
| degree of collaboration is great! IMO it's about the scale.
|
| Like someone giving you directions while driving, IMO it's great
| to have input from 1 to 2 people on a PR, and also while planning
| a feature. For me this has helped me avoid some basic mistakes
| and helped me not to overlook some pitfalls early on. Same for
| reviews.
|
| But the screenshot from a PR with ~10 people reviewing it is
| where it gets crazy, I've never seen that.
|
| Personally I usually just don't add to discussions like that,
| seems pointless. IMO it's also about trusting your colleagues:
| probably they have already said all there is to say.
| slashdave wrote:
| I suppose if your primary goal is to write code and ship, you
| might like this advice.
|
| Some of us like quality products. Maybe I am just old fashioned.
| perlgeek wrote:
| One reason for collaboration is to raise the bus factor.
|
| For small to medium-sized applications, it's not hard to get a
| single good developer to crank out feature after feature... but
| they're the only one that understands any of it. Then that single
| developer is hit by the proverbial bus (or Corona, or retires, or
| resigns, or whatever...) and you have important software without
| any maintainer.
|
| That might be OK for some startups where the expectation is that
| the code will be thrown away and replaced by something better
| pretty quickly, but for slower organizations, that's often a
| nightmare scenario.
| cbreynoldson wrote:
| For relatively straightforward groups whose tasks are self
| explanatory and/or isolated, sure. For any kind of invention,
| however, I don't think this line of thought works. Alan Kay has
| said in a number of places that Xerox PARC (likely) couldn't have
| worked if they had been remote, nor could it have worked if they
| hadn't had the time they did to goof off, argue, share
| hypotheticals, etc. Developing a shared intuition and connection
| with others in your group is an immeasurable quality that doesn't
| get enough love.
|
| In other words, if your organization is made up of a bunch of
| geese that lay golden eggs, by all means let them lay eggs, but
| don't ignore the fact that your _organization_ could itself be a
| goose that lays golden eggs _together_.
| emphis wrote:
| Elon Elias Musk saw right through this as he silently stared at
| each and every one of Twitter's dream-team that was expecting the
| ride to go on. He saw right through the cracks, the Staceys, the
| Mikes. He had the final tweet and blew most of the crew. He would
| agree with you Charles, he would agree to the point of saving
| screenshots of your website so you can collaborate with his
| memes.
___________________________________________________________________
(page generated 2025-11-11 23:00 UTC)