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.
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.
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.
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.
> 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.
"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.
“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.
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.
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.
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?
We literally followed his “bad” analogy for driving by doing software teaming aka mob pair programming. You switch drivers every 10m or so. It can be great. Everyone learns a lot about the feature and the codebase fast. But it can feel slow. And it tires some more than others. Most people liked it.
Except, they have one person in the ear. Not 4-5, not people giving opposite opinions, not drive by takes.
By the time a race engineer is communicating with a driver all of that has been shaken out. Specific concrete options are given to the driver, and usually only one.
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.
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.
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)
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.
>>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"
>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.
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.
95 comments
[ 2.5 ms ] story [ 66.3 ms ] threadInstead 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.
Measure(communicate) twice, cut(build) once.
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.
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.
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.
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.
It also borders on a kind of edgelord attitude that I've seen from people who I wish not to work with again.
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
The two are literal polar opposite.
By the time a race engineer is communicating with a driver all of that has been shaken out. Specific concrete options are given to the driver, and usually only one.
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.
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)
That's why it still persists.
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.
Don't confuse this with "Don't test and don't do code reviews"
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.
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.