10 ms·

Collaboration sucks

• vapemaster 11mo ago
  You guys need to work on harder problems.
• ssalmon74 11mo ago
  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 11mo ago
    "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 11mo ago
    If this takes off, I think you've coined a new term there with "Quantum Sync Circle."
    • agildehaus 11mo ago
      The Conjoined Triangles of Success
  • gregw2 11mo ago
    Sounds much cooler than what my management likes to call it. RACI or RASCI for every key project.
• bryzaguy 11mo ago
  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 11mo ago
    Programming isn't a sport.
    • deleted 11mo ago
      [deleted]
  • singron 11mo ago
    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.
    • deleted 11mo ago
      [deleted]
  • keeganpoppen 11mo ago
    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 11mo ago
  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 11mo ago
    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 11mo ago
      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.
      • deleted 11mo ago
        [deleted]
• codegeek 11mo ago
  "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 11mo ago
    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 11mo ago
    The problem is design by committee.
  • mnsc 11mo ago
    But the click bait was conceived and written super fast by a daring driver!
• john_moscow 11mo ago
  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 11mo ago
    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 11mo ago
  > 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 11mo ago
    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 11mo ago
      The four worst words on a software project are: “Why can’t you just…”
      • fullofideas 11mo ago
        Closely followed by “This should be an easy lift”
        • Aperocky 11mo ago
          I mutter this a lot. Except when I do 95% of the time I perform the easy lift right after.
          • rdtsc 11mo ago
            That’s the only way I would utter it — if I can then sit down and so do it. If I am asking someone else to do I would ask them to tell me how hard it would be and if they need help or if they suggest a different approach.
• usernamed7 11mo ago
  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.
• snackdex 11mo ago
  damn. super cool that posthog is acknowledging the pains of growing even at their scale.
• kristianc 11mo ago
  “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 11mo ago
    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 11mo ago
    > 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.
  • gregw2 11mo ago
    “If you want to go fast, go alone; if you want to go far, go together” 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".
• devin 11mo ago
  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__ 11mo ago
  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 https://www.youtube.com/shorts/DjvVN4Vp_r0
  • happymellon 11mo ago
    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 11mo ago
      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 :)
      • happymellon 11mo ago
        > Where I work the formatter is the final arbiter of formatting code. And I'm fine with that. Consistency is key for readability, code is read more than written, legacy code is code that people can't read anymore and want to start again, and most of the changes people want to make aren't standard making it harder for new team members to read the code. Install Black, Prettier, Spotless, and move on.
        • bitexploder 11mo ago
• iLoveOncall 11mo ago
  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 11mo ago
    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 11mo ago
    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.
  • j4coh 11mo ago
    What do you mean? If I really own something, it's my call.
• klik99 11mo ago
  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 11mo ago
  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 11mo ago
    Pair programming.
    • stevage 11mo ago
      That was too easy.
      • nkmnz 11mo ago
        Almost like a bait.
    • deleted 11mo ago
      [deleted]
  • deleted 11mo ago
    [deleted]
  • outside1234 11mo ago
    Github Copilot
    • devin 11mo ago
      This is like playing both sides of the board in chess and claiming you had an opponent.
  • aweiher 11mo ago
    Cross-Functional Teams
  • tinodb 11mo ago
• leptons 11mo ago
  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 11mo ago
  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 11mo ago
  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 11mo ago
    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 11mo ago
      > 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.
      • criemen 11mo ago
        People need agency, and feel empowered to go forward. I'm not arguing against that interpretation of the post. But having agency doesn't equal a lack of accountability, or being able to explain what you're doing. In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.
• moralestapia 11mo ago
  This kills the product manager, though. That's why it still persists.
• commandersaki 11mo ago
  I can see how the lack of collaboration lead to the posthog.com website design.
  • ergocoder 11mo ago
    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 11mo ago
    I think it’s one of the best marketing websites for a SaaS I know, if not the best. Taste is clearly subjective
  • aweiher 11mo ago
    Yeah, right? They really have a great website. Even better, the sourcecode is on github with 200+ open PRs, 10.000+ closed PRs and 133 authors in this repo over the last months.
• didip 11mo ago
  For real. The only collaboration that is super fast is between yourself and Claude Code.
• tombert 11mo ago
  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 11mo ago
    If each person can eat half a pizza, you've reinvented the Amazon approach: https://martinfowler.com/bliki/TwoPizzaTeam.html https://martinfowler.com/bliki/TwoPizzaTeam.html
• starkparker 11mo ago
  [dead]
• throwaway7783 11mo ago
  >>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 11mo ago
    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.
    • throwaway7783 11mo ago
      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.
• deleted 11mo ago
  [deleted]
• CGMthrowaway 11mo ago
  >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 11mo ago
  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 11mo ago
    Or medical software. It's great advice for people building products which don't need to work correctly up into the high 9s.
• wagwang 11mo ago
  This is so dumb, its how you end up with 37 versions of the same thing.
• zzzeek 11mo ago
  wow add Posthog to Places Id Never Work "you asked someone what they thought of your approach? BAD! that's not our culture!"
• YouAreWRONGtoo 11mo ago
  [dead]
• lonesword 11mo ago
  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 11mo ago
    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.
• cestith 11mo ago
  The dose makes the poison.
• chadrs 11mo ago
  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 11mo ago
    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 11mo ago
  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 11mo ago
  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 11mo ago
    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 11mo ago
  > 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 11mo ago
    It's called "thinking from the principle" for a reason. You will have to re-invent the whole product from the start...
  • IcyWindows 11mo ago
    Sometimes you can't get every staff engineer to agree to the plan, but you can't sit around forever unto someone caves.
    • criemen 11mo ago
      No, but especially of staff+ engineers I'd expect that they know how to disagree and commit after a reasonable (not too long!) time.
• ripped_britches 11mo ago
  I love this, thank you posthog for being great
• krosaen 11mo ago
  No so much about why collaboration sucks as and argument for how important direct ownership / responsibility is. Good post.
• mpweiher 11mo ago
  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 https://dl.acm.org/doi/10.1145/361598.361623
• energy123 11mo ago
  You can collaborate with smart and driven people. For the rest, you can "collaborate", which means doing it yourself and sharing the credit.
• AceJohnny2 11mo ago
  > 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 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 11mo ago
    You don't really need to explain bike shedding to HN.
• sodapopcan 11mo ago
  It's quality isn't your main metric then ya, knock yourself out.
• milesvp 11mo ago
  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 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?
• philippta 11mo ago
  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 https://youtu.be/5IUj1EZwpJY?si=b7rG7_vemkiOL8Bp
• Ericson2314 11mo ago
  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.
• stuffn 11mo ago
  [dead]
• tikhonj 11mo ago
  > 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 11mo ago
  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 11mo ago
  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/DeChurch-_-Mesmer-Magnus-2010-JAP.pdf https://atlas.northwestern.edu/wp-content/uploads/2017/03/De... https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Collective_Intelligence/Woolley_Aggarwal_Malone_Collective%20Intelligence%20in%20Teams%20and%20Organizations.pdf https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/... https://journals.sagepub.com/doi/10.1518/001872008X375009 https://journals.sagepub.com/doi/10.1518/001872008X375009
• straydusk 11mo ago
  > 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".
• stevage 11mo ago
  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.
• xrd 11mo ago
  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 11mo ago
    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.
    • xrd 11mo ago
      I've been fighting for this approach for ten years now. I can divide organizations into two camps. One will see value in it. The other will not, and they have innumerable problems because they have to constantly refactor, have bugs, and most importantly, no one on the team has any clue of the goals or why of the code.
• hinkley 11mo ago
  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 11mo ago
  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 11mo ago
    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.
  • charles_f 11mo ago
    Yes and no, decision is not the only problem. Some people tend to default to ask for someone's help everytime they get blocked. Or managers drop a quick "ask Bob, he already did something similar", which might be ok on the short term because Bob might indeed give you the answer, but Alice didn't spend the time struggling and learning to be independent in the process, and Bob gets buried in random requests that prevent him from shipping his own stuff. It's not a clear cut thing, definitely helping each other is useful, but like everything there's a balance, and striking it is bot straightforward
  • ryandvm 11mo ago
    Yes, dictatorship works amazingly when you have a benevolent dictator... The problem is that deciders are almost always picked for their ability to kiss management's ass as opposed to their technical savvy. I would agree with you if companies started embracing workplace democracy and electing the decision makers.
• slashdave 11mo ago
  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.
• romanhn 11mo ago
  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.
  • james_marks 11mo ago
    The power of this is in the work you’ve done to frame it as yes/no, with a default to going ahead. This is how things get done.
  • johnnyanmac 11mo ago
    I'm torn on this, probably because either extreme isn't an end all solution. Companies stuck in beauracracy need this advice. Companies stuck in tech debt need to avoid this. But as of now in tech, one of these are clearly rewarded more often, so I get why the article is made as such. For the other extreme, the largest issue I've seen is integration. You make two different systems with no plan on how they integrate. Neither team really takes the time to make them talk properly. That's where some agreed upon architecture helps.
  • lilwobbly 11mo ago
    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 decisions are collaborative by default. Why not just: ship it, get feedback from actual usage, iterate.
• fhennig 11mo ago
  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.
• deleted 11mo ago
  [deleted]
• perlgeek 11mo ago
  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 11mo ago
  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 11mo ago
  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.
• Trasmatta 11mo ago
  Even if collaboration doesn't suck, it's what drains me the most about software development. Give me the power and trust to make decisions, and let me go into a room and build stuff. If you don't trust me to do that, then fire me.
• aweiher 11mo ago
  The author has a point here, collaboration without a driver will lead to a culture of talking instead of doing. To be a driver of a change you need agency. Great example with the PR. If I create a PR at another team, how will they react? "Get off my lawn" or "actually this is not something we had in mind but thanks for the PR, we are putting it behind a feature-flag and will try it out and measure the outcome".
• polynomial 11mo ago
  Related: https://www.sternberg-press.com/product/the-nightmare-of-participation-crossbench-praxis-as-a-mode-of-criticality/ https://www.sternberg-press.com/product/the-nightmare-of-par...
• Congeec 11mo ago
  There is a saying: "big meetings for small things, small meetings for big things". Get sponsors before a meeting if there's anything you really want to push out
• zzo38computer 11mo ago
  Collaboration can be excessive, but it can also sometimes be helpful. For example, if a draft is made available for someone else to review, then someone can comment in case they find something wrong that the original author does not (it is also possible that the original author might find something later that was not originally found).
• QuiEgo 11mo ago
  I often explicitly discuss roles. Who is responsible for a feature (must be exactly one person). Who will have input (without veto power), who will have input (with veto power), who is the “decider” if the responsible person gets vetoed and they don’t agree. Setting up all of this early (and keeping the veto list as small as possible) makes collab a million times easier.
• ndgold 11mo ago
  This spoke to me and hits hard
• locusofself 11mo ago
  I'll admit that some of this resonates with me, but as a line-level manager at a HUGE tech company, there are severe limitations on how much I could implement this philosophy.
• sholladay 11mo ago
  This sounds like a really good excuse to not bear any responsibility for anything other than what you want to work on. PR reviews will mean nothing; they will all be rubber stamps or style nits because no one else will understand the code other than the owner. Your bus factor will be crazy low. Collaboration sucks because of the way it is done, not because it has to. Pointless meetings for decision making that should be async. Brainstorming over Slack when that's what a meeting is actually good for. Looping people in to collaborate at the end instead of at the beginning. This is all possible to fix. What I do is have everyone work in pairs. Pairs are small enough that communication is easy and there's no design-by-committee. But there's always someone to have your back and help when you get stuck or bogged down (e.g. decision fatigue), which happens plenty even to senior engineers. The pair starts and finishes work together, which mostly eliminates the need to loop someone else in randomly and needing to explain the thinking and background context, because they can bounce ideas off of each other and leverage each other's different areas of expertise. Whatever the end result is of that collaboration is treated as a finished unit of work, it's already been looked at closely by two people, it doesn't need a complicated approval process. The automated tests run, the release manager looks for any obvious mistakes, and then it ships. The hardest nut to crack is the "who is the driver and who is the navigator" problem. I find that it is best to leave that up to the pair to work out for themselves, since it depends on the personalities involved. But with some guidance to not step on each other's toes. Working on the same line of code at the same time constantly is clearly the "too much collaboration" extreme that the article's author dreads. It's better if one person designs while the other codes, or one works on the logic while the other does the TypeScript types, etc. Usually the pair struggles with this for a week or two and then they develop a groove and it's rarely a problem after that. Spontaneous or infrequent collaborators never reach that groove, hence it can be inefficient and frustrating. Long-term pairs get to know each other and then work fast and smooth.
• deleted 11mo ago
  [deleted]
• harimau777 11mo ago
  This is satire right? I can't imagine anyone actually thinking this is a viable way to approach development. Anything but the most trivial software system is innately collaborative.
• hshdhdhj4444 11mo ago
  Nearly Everything the author suggests to do to root out collaboration is collaboration… > So if collaboration is your enemy, how do you defeat it? Here’s what we say: > Default to shipping. Pull requests > issues > Slack messages. This seems orthogonal to collaboration…creating unnecessary issues or messaging people when you already have the solution isn’t collaboration. It’s just being annoying (or maybe an overbearing mandatory “process”). > 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). How to make friends and crush collaboration Huh? Collaboration doesn’t mean there is no leader or primary decision maker. > Tag who you specifically want input from and what you want from them, not just throw things out there into the void. Yeah, this is exactly collaboration. > 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. Ok, sounds like they prefer feedback from collaborators after shipping rather than before. Sure. Maybe that’s better. Both are collaboration though. > If you are a team lead, or leader of leads, who has been asked for feedback, consider being more you can just do stuff. A team lead who helps out someone asking for help…sounds like COLLABORATION > When it’s your thing, you are the “informed captain.” Listen to feedback, but know it’s ultimately up to you to decide what to do, not the people giving feedback. Again, collaboration doesn’t exclude decision making. Collaboration is not majoritarianism.
  • zeroonetwothree 11mo ago
    IME “collaboration” as a term means specifically what the article describes and not the more general concept that you are using. So for example yes a team lead helping someone is technically collaboration but it’s not “collaboration” as the management bureaucracy would use the buzzword. How it’s used in practice is exactly as stated in the article: a way of folding in people into a project that probably shouldn’t be involved and don’t add much value
  • deleted 11mo ago
    [deleted]
• klysm 11mo ago
  Ownership and trust
• bguthrie 11mo ago
  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.
• jrochkind1 11mo ago
  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 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.
• James_K 11mo ago
  I can't help but wonder if the fine folks at “post hog” know that their name is slang used for asking a man to publish an image of his genitals.
• ropable 11mo ago
  Notwithstanding that the sentiment of the article speaks to me somewhat, I think that it's overly reductive and lacks nuance. Sometimes collaboration can be bad - when you get bike-shedding, when there's no clear decision-maker, etc. Sometimes it can be good - when skills and expertise are complementary, it can be a force multiplier. The value of collaboration, just like most other things, depends on implementation and circumstance.
• alvinveroy 11mo ago
  [dead]
  • gnabgib 11mo ago
    Another problem is people using AI to generate responses. Perhaps you could provide a real response next time
  • solatic 11mo ago
    > searchable archive Have fun with that. At the end of the day you run into the same problem as most wikis, where people just "threw stuff over the wall" into a big wiki database, and it gets to be really difficult to find relevant decisions. Eventually people add a new decision that contradicts an older decision that they didn't find, then later on someone with better search skills finds both contradicting decisions. It doesn't help anyone. All you did was increase the cost of making a decision by forcing a higher documentation cost, which slows down the business. Most companies looking at structured decision making are better off with a better approach to writing internal policy, which is a kind of technical documentation. You need someone to own the meta/framework surrounding policy (clean presentation, different ways for different questions to reach the same policy, handling the workings of how different owners have permissions to control their areas of policy, making sure stakeholders are notified of changes, etc.), and a culture of collaboration which encourages people to propose changes to outdated policy (and not just dismissing them out of hand). Good policy simplifies decision-making: either it's already allowed by policy and people are free to continue without bureaucracy, or a proposal to change policy results in a tangible artifact already in the relevant place, either the accepted proposal or an addendum to the policy explaining why alternatives were rejected.
  • manmademagic 11mo ago
    This may be true in some cases, but I’ve also seen issues with too many stamps, signatures, red-tape, tribunals/committees, and multi-stage approval chains. There’s a balance somewhere put there, but that balance is different for everyone. Personally I think problematic decision making is more to do with the “blame” side of ownership. It benefits the unsure more than the certain, and not many people are okay with making and admitting to mistakes.
• asterios33 11mo ago
  I believe the article misses the mark because it's one sided. unsurprising, since it seems written from the perspective of someone who sees the main unit of value as a pull request. Collaboration is useless in deterministic predictable environment with a single source of truth. When you deal with lot of ambiguity,constant changes and need to adapt then you have no choice that collaborating and getting a feedback loop. You can win alone, but you can’t lose alone.
• cadamsdotcom 11mo ago
  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
• mmarvin 11mo ago
  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“.
• tarcon 11mo ago
  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.
• tarcon 11mo ago
  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.
• nrawe 11mo ago
  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.
• hastily3114 11mo ago
  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.
• austin-cheney 11mo ago
  Like with everything else this is provable with numbers. What this is really about is having at least the appropriate amount of social intelligence for people who are otherwise individually productive. That’s it: productive people who know when to engage. The way to solve for that is force additional business ownership onto the developers. When there is increased liability and increased risk of failure the developers will know exactly the right amount of feedback to provide, especially to each other, because are operating conditions are dictated by velocity and code quality baselines. I am saying this as a software manager of people.
• __bax 11mo ago
  Having an AI destroy human collaboration
• constantcrying 11mo ago
  What the article calls "collaboration" is not collaboration, but performative work, in other words wasting time. People love to invent reasons why they can not do something. "I need help", "I don't know", "I don't want to decide this", then they use these reasons to do performative work, meetings, pair programming, etc. Collaboration happens when multiple people want to achieve a goal together. What the article calls "collaboration" is multiple people not wanting to achieve a goal, while pretending to want the opposite. These shouldn't be conflated, as actual collaboration is enormously powerful.
• duxup 11mo ago
  In email, instant messaging, and really most communication / collaboration I wish there was a setting: "If you're not at least at a 7 out of 10 in terms of paying attention / understand the topic ... please refrain from participating." I know it can't be done, but I think it would help if you COULD do that.
• NoGravitas 11mo ago
  I always laugh when I see the name of this company. Impossible to take seriously (because I'm 12).