If you want to go fast, go alone; if you want to go far, go alone too. (mostly)
“If you want to go fast, go alone; if you want to go far, go together”
This phrase will slowly kill your company and I’m here to prove it.
Imagine you are driving a car. It’s often useful to have someone give you directions, point out gas stations, and recommend stops for snacks. This is a helpful amount of collaboration.
An unhelpful amount of collaboration is getting out of your car to ask pedestrians if they like your car, swapping drivers every 10 minutes, or having someone constantly commenting on your driving.
In the first scenario, you get the right amount of feedback to get to your destination as fast as possible. In the second, you get more feedback, but it slows you down. You run the risk of not making it to the place you want to go.
The second scenario is also the one most startups (or companies, really) end up in because of ✨ collaboration ✨.
As PostHog grows, I’ve seen more and more collaboration that doesn’t add value or adds far too little value for the time lost collaborating. So much so we made “collaboration sucks” the topic of the week during a recent company all hands.
“You’re the driver” is a key value for us at PostHog. We aim to hire people who are great at their jobs and get out of their way. 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. Marketers ship code, salespeople answer technical questions without backup, and product engineers work across the stack.
This means there is almost always someone better at what you are doing than you are. It is tempting to get them, or anybody really, involved and ✨ collaborate ✨, but collaboration forces the driver to slow down and explain stuff (background, context, their thinking).
This tendency reveals itself in a few key phrases:
“Curious what X thinks”
“Would love to hear Y’s take on this”
“We should work with Z on this”
This sometimes leads to valuable insights, but always slows the driver down. It erodes their motivation, confidence, and effectiveness, and ultimately leads us to ship less.
Everyone is to blame.
People want to be helpful. For example, when someone posts their work-in-progress in Slack, others feel obliged to give feedback because we have a culture of feedback.
On the flip side, people don’t ask for feedback from specific people because it doesn’t feel inclusive, even though it would help.
People aren’t specific enough about what feedback they need. This creates more space for collaboration to sneak in. A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.
When someone has a good idea, the response often defaults to “let’s discuss” rather than “ok, do it.” As proof, we have 175 mentions of “let’s discuss” in Slack.
People just want to talk about stuff because they
are too busycan’t be bothered to act on it. We drift from our ideal of a pull request to an issue/RFC to Slack (we are mostly here) to “let’s discuss”.It’s not clear who the owner is (or no one wants to own what’s being discussed).
It is annoying, but sometimes a single person can’t ship certain things front to back to a high-enough quality and we can’t just ship and iterate. We can fix broken code, but we can’t resend a newsletter.
So if collaboration is your enemy, how do you defeat it? Here’s what we say:
Default to shipping. Pull requests > issues > Slack messages.
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).
Tag who you specifically want input from and what you want from them, not just throw things out there into the void.
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.
If you are a team lead, or leader of leads, who has been asked for feedback, consider being more you can just do stuff.
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.
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.
The point is, if you aren’t actively attempting to collaborate less, you are probably collaborating too much by default and hurting your ability to go far, fast.
Words by Charles Cook, who also hates sparkling water, presumably because the bubbles are too collaborative.
Read the original article
Comments
By throwaway713 2025-11-1120:5311 reply > 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.
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.
By Arubis 2025-11-120:01 "Second-guessing works by forcing someone to reverse acts of destruction. If I delegate a decision to you, you quickly spin up a set of relevant mental models, work to get a lot of momentum into them, pay the cost of killing many possible worlds, and experience the relief of a lightened load to carry. Then, by second guessing, I suddenly demand that you resurrect dead models, so I can validate or override your decision. Next time, you won’t put so much momentum in to begin with." (Venkatesh Rao, Tempo: timing, tactics and strategy in narrative-driven decision-making)
By AceJohnny2 2025-11-1121:203 reply 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")
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.)
By tombert 2025-11-121:32 I don't dispute that. I wish I had been on a better team. My team had a famously high turnover rate, so it wasn't just me. I liked my direct manager just fine, he's a decent dude, but I thought his manager, who I had to deal with a lot, was kind of a dumbass and I did not enjoy working with him at all.
I tried joining other teams but without going into elaborate detail it didn't pan out.
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
By qwertytyyuu 2025-11-120:051 reply I'm in public service, teach me you ways XD
By rightbyte 2025-11-1210:47 It only works versus good managers.
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.
By tombert 2025-11-121:29 I tried that, multiple times actually. My options were already pretty limited because I didn't want to move to California, and without going into elaborate detail I the interviews for other teams just didn't work out.
Yuck.
The attitude I like to have is that the author can choose to do the design (doc + approval, or live discussion, some kind of buy in) first or go straight to the PR.
If the design is agreed on first, reviewers would need a really good reason to make the author go back and rethink the design—it happens, sometimes a whole team misses something, but it should be very rare. Usually, there's just implementation things, and ones that are objective improvements or optional. (For project style preferences, there should be a guide to avoid surprises.)
If the author goes straight to a PR, it's an experiment, so they should be willing to throw it away if someone says "did you think about this completely different design (that might be simpler/more robust/whatever)".
This is not the approach suggested by this article, and I'm okay with that. I tend to work on high reliability infrastructure, so quality over velocity, within reason.
I like this - and I think it’s a natural reality. When trust is low (for many reasons, including joining a new team), it may reduce risk to start with a design doc.
By scottlamb 2025-11-1217:02 There are a lot of reasons anyway I like to have the design doc around. A few:
* I think the designs are often better when people write down their goals, non-goals, assumptions, and alternatives rather than just writing code.
* Reading previous designs helps new people (or even LLMs I guess) understand the system and team design philosophy.
* It helps everyone evaluate if the design still makes sense after goals change.
* It helps explain to upper management (or promotion committee in a large company) the work the author is doing. They're not gonna dig into the code!
...so it's usually worth writing up even if not as a stage before implementation starts. It can be a quick thing. If people start using a LLM for the writing, your format is too heavy-weight or focused on style over substance.
There's definitely a negative side to approval stages before shipping, as this article points out, but when quality (reliability, privacy/security, ...) is the system's most important attribute, I can't justify having zero. And while getting the design approved before starting implementation isn't necessary, it should avoid the bad experience tombert had of having to redo everything.
By oumua_don17 2025-11-1211:361 reply Any chance you were in one of that infamous orgs?
By tombert 2025-11-132:16 Yeah, my org had a pretty high turnover rate. I didn't enjoy it, I wish my transfer had gone through because I suspect I would have enjoyed the team I was applying for considerably more. Not how it worked out though, and after a certain point I couldn't take it anymore.
By wink 2025-11-128:12 "Just decide for yourself and be self-reliant... no, not like that!"
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.
By ninetyninenine 2025-11-1121:272 reply 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.
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.
By marcosdumay 2025-11-120:011 reply > You can blame Taylor for that.
No, you can't. Taylor was a huge advocate for standardizing people's work so it could be studied and improved. He was also an advocate for well-studied people to go and teach workers how to do their jobs, and a not intense advocate for thinking ill of workers based on everything you can expect from a rich 19 century guy.
What he advocate a lot against was doing power games against workers or automatically dismissing everything they say.
Standardizing people’s work turned them into automatons to be studied and improved by a management elite.
Which all came crashing down when Deming had to go to Japan to get people to listen to his ideas and triggered a massive recession in the US.
Deming and (to a lesser extent) Goldratt pull the employees back into the conversation. Tether are closest to the problem and even if they can’t solve it, they can help you shape the answer. Taylor was neofeudalism and he can rot.
By marcosdumay 2025-11-1213:341 reply The one thing people are complaining upthread is not Taylor's fault. He actively fought against it.
The stuff you are complaining on the first line is. But also, Taylor was an advocate for listening what the workers had to say too. You can't really blame Taylorism on him, he invented only the mildest parts of it.
And that said, Deming advocated standardizing work too. You just can't run a factory without doing that.
By hinkley 2025-11-1216:49 I can’t blame Taylorism on Taylor?
Collaboration is between peers. Taylor was top-down. That’s dictatorial, not collaboration. When you take collab out of the mix it’s a product manager and one dev and that’s a power imbalance.
By appreciatorBus 2025-11-1122:263 reply 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.
By InexSquirrel 2025-11-1122:51 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.
By hinkley 2025-11-1122:34 Management often spends less time with the users than we do.
By ninetyninenine 2025-11-1122:45 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.
By ninetyninenine 2025-11-1122:413 reply 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.
While I mostly agree with your original post (egos in this field are huge), it’s hard to interpret that IQ stat without more data. Kinda low IQ to present it like that without additional info cause it’s impossible to really evaluate.
By ninetyninenine 2025-11-121:09 Only because while you don’t brag about it you truly do believe you’re smarter. It’s not even about acting humble. The ego is real because despite me saying software engineers have roughly above average intelligence you couldn’t take it.
By tptacek 2025-11-1221:20 I'll ask you too, given your 110-113 stat: when was the cross-sectional survey of IQ that would be required to generate this stat been done?
By tonyedgecombe 2025-11-1212:562 reply Meanwhile the average IQ of computer science graduates is 130. Draw what conclusion you want from that.
By tptacek 2025-11-1221:19 This stat seems far-fetched. When has a cross-sectional IQ survey of CS graduates ever been taken?
By ninetyninenine 2025-11-1214:05 Did you deep dive into this? Given the amount of downvotes I have I’m sure you weren’t the only one if you did.
About 30 percent of developers have no degree. Which means… if the average graduate of CS is 130, how low does the average swe without it a degree have to be in order to bring it down to 110?
I mean I spelled out the math. Dear readers, Draw what conclusion you want from that while asking yourself: “Do I have a degree?”
I will say that iq varies heavily across schools as well.
By binary132 2025-11-1121:39 “trust nobody, not even yourself” applies here for sure.
By petralithic 2025-11-1121:501 reply 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.
By wordpad 2025-11-1221:19 I think if you are empowered to make decisions as an employee it's YOUR responsibility to know the limitations of your scope and when to seek feedback and approvals from architecture, management, business or whoever.
So if your decisions are getting turned over, you are either making decisions outside of your scope or your management is genuinely micromanaging you.
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
The four worst words on a software project are: “Why can’t you just…”By fullofideas 2025-11-1121:572 reply Closely followed by “This should be an easy lift”
By neilv 2025-11-1122:30 "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
I mutter this a lot. Except when I do 95% of the time I perform the easy lift right after.
By rdtsc 2025-11-121:18 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.
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.
By 0x457 2025-11-1122:43 Have WE tried using caching?
By theideaofcoffee 2025-11-1122:07 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..."
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.
By asa400 2025-11-1123:08 People think management sucks at hiring good talent (which is sometimes true, but I have worked with some truly incredible people), but one of the most consistent and costly mistakes I’ve observed over my career has been management's poor ability to identify and fire nuisance employees.
I don’t mean people who “aren't rockstars” or people for whom some things take too long, or people who get things wrong occasionally (we all do).
I mean people who, like you describe, systemically undermine the rest of the team’s work.
I’ve been on teams where a single person managed to derail an entire team’s delivery for the better part of a year, despite the rest of the team screaming at management that this person was taking huge shortcuts, trying to undermine other people’s designs in bad faith, bypassing agreed-upon practices and rules and then lying about it, pushing stuff to production without understanding it, etc.
Management continued to deflect and defer until the team lead and another senior engineer ragequit over management’s inaction and we missed multiple deadlines at which point they started to realize we weren’t just making this up for fun.
By tossandthrow 2025-11-129:171 reply "it's your call" does not mean there are no requirements.
On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing.
If a manager, denotationally, can call out that there is something missing, then it was not implemented right.
By enraged_camel 2025-11-129:221 reply “It’s your call” specifically means all the decisions on the table are valid and fit the requirements and the employee is being granted permission to make a judgment call. Questioning that judgment call afterwards is shitty and leads to an erosion of trust because the employee will thereon second guess themselves and also try to avoid making any decisions (because they expect them to be overridden).
By jsiepkes 2025-11-1210:35 > and fit the requirements
And that is where the friction is. A lot of these requirements are implicit.
For example; If an application is built around Protobuf / gRPC and you suddenly start doing JSON / REST you are going to need a really, really good reason for that. Since you are introducing a new technology, with all it's glory and all it's horror. So your judgment is going to be questioned on that and most likely the reaction will be; We are not going to do that.
By 6510 2025-11-1212:02 If you know they are going to be like that you could try getting the information out of them as early as possible. Ask a bit to much about every detail, find the point where it annoys them then try not to cross it. When you inevitably do remind him of the previous rewrites and the time it consumed. It is our job to perfect this system. It gets considerably harder to request changes after you've asked not to be bothered with every detail.
That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.
By jstummbillig 2025-11-1121:16 > This is a great way to lose employees.
A great way, you say. Taking notes!
By dragonwriter 2025-11-121:44 I'm not sure that's a corollary, it seems to have tension with "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."
Though I guess it is in tune with "no managers telling you what to do."
If you don’t collaborate before it’s shipped and don’t retroactively review after it’s shipped, how do you provide input?
You iterate on what’s shipped. It’s not a one-and-done kind of deal.
By dragonwriter 2025-11-121:47 Iterating on what has shipped inherently involves review of what has shipped.
By bfkwlfkjf 2025-11-1121:05 I just gave this feedback to my boss today
By ergocoder 2025-11-1121:27 The equivalent of "I told you so". Yeah, you should never do that in any situation.
By brendanfalk 2025-11-1121:0710 reply 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)
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.
> 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.
By criemen 2025-11-1217:25 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.
By methyl 2025-11-126:10 > Quality goes up by slowing down.
Not necessarily. You get biggest insights about quality after you ship, not before. Slowing down means you ship later, which means the insights are delayed. Unless you work in a rocket industry et all, slowing down will be detrimental to the quality.
> Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
I'll add one more to this - not knowing how set in stone any decision is. I'm a PM, and I'm often the one charged with making the final call on many things. One thing I've often seen go wrong is a PM or an exec will say something like, "we should do x" in some review, and the team moves heaven and earth to achieve x, only to find out later it was just a drive by comment from said person, not something they deeply cared about.
One thing I've started doing is adding a GAF score (Give A Fuck score) to many of my decisions that have engineering ramifications, especially for anything that affects platform or architectural aspects. IE I might say something like, "this needs to have less than a 200ms round trip, this is a GAF-10" if something is direly important, and if we should commit significant engineering effort to making the decision happen. Or I might say, "I think we should go with approach A instead of B, but this is a GAF-2, so come back to me if you feel like A becomes untennable".
This way the team can move forward, but wont overindex on decisions that become bad decisions.
By anssip 2025-11-125:49 GAF score sounds like a great idea!
By actsasbuffoon 2025-11-121:121 reply > I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing
I have ample examples, unfortunately. I had a coworker whom I liked as a person, but had a nasty habit of using PRs as a way to hijack all decision making. He’d leave PR feedback for his personal preferences and mark them as “changes requested.”
Everyone feels like an asshole giving an approval when someone has requested changes, so you had to comply with all of his preferences if you wanted to merge your code.
I’ve had several companies where I submitted a PR and had someone say, “You’re guarding against an edge case that won’t happen. This is over engineered. Remove it.”
And it made it less than a week in production before we hit the edge case that I’d been forced to neglect.
I had a team come to me with a request, so I built it. They were thrilled. Then another engineer was like, “I don’t like (some technical detail). You need to change (major architectural decision).”
I gave the re-architected version to the team who requested it and they said, “Wait, I loved what you built before. What is this? I don’t want this!”
This post resonated with me pretty hard. Hire good people and deputize them to make decisions. You’ll end up with something good more often than not. I’ve never seen design-by-committee produce a great product.
I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
By thw_9a83c 2025-11-1211:01 > I’ve had too many experiences with seeing decent contributions get worse and worse as they go through successive rounds of feedback.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
By thoughtlede 2025-11-1122:23 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.
By KaiserPro 2025-11-1122:22 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
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.
By forgotusername6 2025-11-1122:11 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.
By gregw2 2025-11-121:05 I agree with your comment that getting feedback is different to making the final decision.
But I'm not sure the real problem fits solely in your two buckets.
I've been in recent situations where there is a less-technical person charged with making the "final decision" and a lot of other senior people in the room who don't all /have/ to agree. But the degree of "why not do it this way?" questioning+discussion will grow with the number of meeting participants (and/or worse, the # of meetings before a decision is made if it is not settled in one meeting and then new stakeholders arrive and have their own thrashing out to do.) And even with one final decider, you can end up a bit still with "Design By Committee" decisions when the final decider goes along with the group consensus or doesn't have a strong point of view on an issue.
By Aurornis 2025-11-122:06 > 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.
Getting measured feedback is good when it’s coming from a place of genuine helpfulness.
I’ve been in multiple companies where, for various reasons, feedback rounds turned into a game of being maximally contrarian. It didn’t matter what you proposed, a few people would make it their mission to fabricate some objections and come up with reasons to rewrite it into something else. It was a way of exerting control and stealing ownership/credit by replacing others’ ideas with your own.
The most frustrating situations were when you’d rewrite something to accommodate some staff engineer or manager, then at the feedback session for the review they would complain and propose your original version, seemingly forgetting that they had rejected it once previously.
By solatic 2025-11-127:11 100%. Three decision-making styles are dictators (make decisions without feedback), arbitrators (listen to feedback, then the arbitrator makes the call), and mediators (mediators guide discussion until consensus is reached). Arbitrators are far and away the most successful and best liked. The key insight is that a culture of arbitration is not natural and must be intentionally built.
By danielmarkbruce 2025-11-1123:33 Collaborate has a reasonably well defined definition, approximately:
"To collaborate means to work jointly with one or more people toward a shared goal or project, especially by contributing ideas, skills, or effort"
What you are talking about isn't collaboration, it's feedback. You have the goal, it's your thing to do.
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
By happymellon 2025-11-1121:241 reply 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.
By bitexploder 2025-11-1121:311 reply 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 :)
By happymellon 2025-11-1211:251 reply > 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.
By bitexploder 2025-11-1216:52 I like it too. It is reliable, predictable. Removes a common source of opinionated friction.
By makeitdouble 2025-11-1122:191 reply > 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.
By lionkor 2025-11-1122:21 Even more than that, it means the developer has spent no time understanding the surrounding code, and thus is likely adding debt/CRUFT/risk.
By joaohkfaria 2025-11-1121:30 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.
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.
> 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.
By hinkley 2025-11-1122:01 > 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.
By petralithic 2025-11-1121:531 reply > 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.
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.
By petralithic 2025-11-127:44 This sounds like a non sequitur to me, when did I ever say I disagreed with the fact that "they just want to get shit done?" I am not sure what your comment has to do with the part about misconstruing features for moving parts, for those are two independent things, and still more generally, like I said, people do pay for software that has more features than fewer.
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.
By makeitdouble 2025-11-120:191 reply > their partner complains about unimportant stuff.
I can't know how you meant it, but if your partner if complaining about something 5 times a day, you might want to rethink if it's really unimportant, and understand why they care instead of "get past this stuff".
That reminds me of the guys getting dumped after 10 years of marriage complaining they genuinely have no idea why their partner left them.
By m463 2025-11-122:23 unimportant stuff = syntax errors
communication = both parties learning to communicate in effective ways
"tab stops might seem unimportant, but I can read and review your code easier"
"Ok I see your concern and will set up my editor"
"toilet seat seems unimportant, but if I fall in in the middle of the night, it will disturb both of us"
:)
By harimau777 2025-11-121:35 Who decides what is a nitpick and what is essential to keeping code clean enough that others can do their job?
By thisrobot 2025-11-1121:29 amen. i don't really care about style/format. my opinion is that if you care you should automate it.
