The core problem with collaboration isn't the people - it's the absence of documented decisions.
Most organizations suffer from *Decision Debt*: decisions get made in meetings, Slack chats, or hallway conversations, then never get written down. Result:
- People rework decisions that were already made
- New team members don't know the reasoning
- Previous context is lost when people leave
- The same arguments happen again 6 months later
The pattern I've seen in well-functioning teams:
1. *Asynchronous Decision Records* - Every meaningful decision gets written (not a 2-page manifesto, just: What, Why, by whom, when)
2. *Immutable Decisions* - Once recorded and approved, they don't get rehashed in every meeting
3. *Clear Reasoning* - Document not just what was decided, but why (constraints, alternatives considered, tradeoffs)
4. *Searchable Archive* - You can find "why did we choose X over Y" without asking someone who might have left
This eliminates most "collaboration sucks" friction because people spend less time in meetings debating things already decided, and more time actually building.
The problem isn't too many cooks - it's that nobody wrote down the recipe.
> 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.
"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)
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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."
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.
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.
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.
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.
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."
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.
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.
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.
> 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.
> 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.
> 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.
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
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.
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.
> 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.
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.
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.
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.
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 :)
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.
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.
> 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.
> 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.
> 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.
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.
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.
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.
First of all, just because you (or the author) call collaboration a bad thing doesn't make it so. Secondly, you seem to have misunderstood the process. The steps are: I will be shipping shortly, here is the direction I decided on because XYZ, if you want to react there is some limited amount of time to do so but those objections better be nontrivial. There is no waiting for permission, the path is set - yes, barring strong objections. Apparently you think it's best to leave those for after the fact, well, good luck with that.
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.
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.
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.
The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.
If you just get things done, the effort won't be perceived or understood. .
If you just have meeting about what you did, they'll be forgotten the next day, because it's some complicated detail that can't be bothered with.
If you have periodic meetings of what you plan to do, and allow people to comment/participate, they'll see themselves as contributing in a small way, which helps them remember, which helps them understand the effort.
Worst, if you plan well and prevent future problems, nobody can know your good decisions. So, the optimal route seems to be, have periodic meetings that high ups can participate in, to some extent, and let "unforeseen problems" happen, so you can be in meetings with higher ups, fix the problems, and be the hero. This isn't even really my jaded opinion. In the org I'm in now, it was such as widely understood phenomenon that a special reward package, and recognition, had to be put together for people who prevented problems from happening.
>The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.
Well we can divide it in 4 ways:
- the "sales engineer" (not a literal sales enginer, but one who wants to sell themself) wants to maximize visibility.
- the startup engieer wants to pitch just enough, but mostly wants to ship
- the craftman engineer (or the researcher) wants to get things done "right"
- the blue collar engineer wants to check off tickets.
Your metrics of success will vary, and some engineers are more punished in some spaces than others.you'll need different skills to navigate depending on your environment
You are very right to call out that in a corporate environment getting things done is judged by the eye of the beholder. This, imho, makes this article even more naive because posthog is pretending they don't do that, and no organization is immune to it.
Ironically, GitHub started having lots of problems when they enbraced the holocracy, i.e. flat management. No one was in charge and no amount of "empty PRs" as I described above could mitigate the vacuum of leadership.
That this article made it past posthog's leadership means they might be having a leadership crisis.
> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?
That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.
> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks.
So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?
i get preplanning big picture architecture or strategy, but i CANNOT plan out the actual code i write. i'm not sure if i just develop deficient mental models of the codebase, but my process for figuring out what to build is to just sit down and build it. my process is very iterative. lots of stubbing things out and working backwards (if i need this function to return an X, it needs args A and B which means it might be better as a method for this class over here...)
the only way i could come up with a precise plan for how the code needs to change is to just build the thing.
Consider this: you could, given enough time. You probably haven't had management that gave you that time. Or demanded you take the time.
Writing things down takes a lot more time than you think. It is hard work. You get better with practice.
You would find, if you were given the time, or permitted yourself to have that time, that you would find all the skills you have accumulated up to this point would converge into that plan. There is a very exciting zen you get into writing things down and you can think about the architecture and the people and the teams involved, and it's a very different thing to create. And very satisfying.
"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.
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.
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.
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.
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
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.
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.
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.
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 (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?
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?
“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.
“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".
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.
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.
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.
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.
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.
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.
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.
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.
>>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"
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.
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.
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.
> others feel obliged to give feedback because we have a culture of feedback.
See also "bikeshedding". Made famous by FreeBSD core developer Poul-Henning Kamp (phk). I see there is now a website dedicated to his email: https://www.bikeshed.org
In short: people give feedback and quibble because they can, to demonstrate that they're participating, that they can contribute.
Being aware of this habit and inhibiting it is something I teach to every new employee in my team. (If you know how to avoid it always, teach me)
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.
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.
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?
>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 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.
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".
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.
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).
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).
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.
> 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.
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.
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.
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
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".
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.
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 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.
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.
This is such a great response. It leaves me wishing I could delete my comment. A.I. told me there was a 2020 match between Lakers and Globetrotters which the Lakers won. Turns out it was a fictional match. I've had great success with mob programming so that's where my brain was at.
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.
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.
"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!
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.
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.
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?
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.
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
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.
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.
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: ...
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.
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.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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"
The core problem with collaboration isn't the people - it's the absence of documented decisions.
Most organizations suffer from *Decision Debt*: decisions get made in meetings, Slack chats, or hallway conversations, then never get written down. Result:
- People rework decisions that were already made - New team members don't know the reasoning - Previous context is lost when people leave - The same arguments happen again 6 months later
The pattern I've seen in well-functioning teams:
1. *Asynchronous Decision Records* - Every meaningful decision gets written (not a 2-page manifesto, just: What, Why, by whom, when) 2. *Immutable Decisions* - Once recorded and approved, they don't get rehashed in every meeting 3. *Clear Reasoning* - Document not just what was decided, but why (constraints, alternatives considered, tradeoffs) 4. *Searchable Archive* - You can find "why did we choose X over Y" without asking someone who might have left
This eliminates most "collaboration sucks" friction because people spend less time in meetings debating things already decided, and more time actually building.
The problem isn't too many cooks - it's that nobody wrote down the recipe.
> 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.
"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)
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.)
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
I'm in public service, teach me you ways XD
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.
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.
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.
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.
> 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.
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.
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.
Management often spends less time with the users than we do.
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.
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.
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.
https://brght.org/iq/study/software-engineering/
“trust nobody, not even yourself” applies here for sure.
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
Closely followed by “This should be an easy lift”
"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.
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.
Have WE tried using caching?
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.
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.
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 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."
> This is a great way to lose employees.
A great way, you say. Taking notes!
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.
Iterating on what has shipped inherently involves review of what has shipped.
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.
I just gave this feedback to my boss today
The equivalent of "I told you so". Yeah, you should never do that in any situation.
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.
> 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.
> 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.
> 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.
GAF score sounds like a great idea!
> 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.
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
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.
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.
> 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.
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.
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.
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
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.
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 :)
> 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.
Even more than that, it means the developer has spent no time understanding the surrounding code, and thus is likely adding debt/CRUFT/risk.
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.
> 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.
> 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.
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.
> 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.
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"
:)
Who decides what is a nitpick and what is essential to keeping code clean enough that others can do their job?
amen. i don't really care about style/format. my opinion is that if you care you should automate it.
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.
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.
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.
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.
First of all, just because you (or the author) call collaboration a bad thing doesn't make it so. Secondly, you seem to have misunderstood the process. The steps are: I will be shipping shortly, here is the direction I decided on because XYZ, if you want to react there is some limited amount of time to do so but those objections better be nontrivial. There is no waiting for permission, the path is set - yes, barring strong objections. Apparently you think it's best to leave those for after the fact, well, good luck with that.
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.
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.
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.
> Getting things done is an important metric.
The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.
If you just get things done, the effort won't be perceived or understood. .
If you just have meeting about what you did, they'll be forgotten the next day, because it's some complicated detail that can't be bothered with.
If you have periodic meetings of what you plan to do, and allow people to comment/participate, they'll see themselves as contributing in a small way, which helps them remember, which helps them understand the effort.
Worst, if you plan well and prevent future problems, nobody can know your good decisions. So, the optimal route seems to be, have periodic meetings that high ups can participate in, to some extent, and let "unforeseen problems" happen, so you can be in meetings with higher ups, fix the problems, and be the hero. This isn't even really my jaded opinion. In the org I'm in now, it was such as widely understood phenomenon that a special reward package, and recognition, had to be put together for people who prevented problems from happening.
>The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.
Well we can divide it in 4 ways:
- the "sales engineer" (not a literal sales enginer, but one who wants to sell themself) wants to maximize visibility.
- the startup engieer wants to pitch just enough, but mostly wants to ship
- the craftman engineer (or the researcher) wants to get things done "right"
- the blue collar engineer wants to check off tickets.
Your metrics of success will vary, and some engineers are more punished in some spaces than others.you'll need different skills to navigate depending on your environment
Sadly, I can't disagree.
You are very right to call out that in a corporate environment getting things done is judged by the eye of the beholder. This, imho, makes this article even more naive because posthog is pretending they don't do that, and no organization is immune to it.
Ironically, GitHub started having lots of problems when they enbraced the holocracy, i.e. flat management. No one was in charge and no amount of "empty PRs" as I described above could mitigate the vacuum of leadership.
That this article made it past posthog's leadership means they might be having a leadership crisis.
As the old saying goes... if code was shipped but nobody heard it get shipped... did it really Provide Value?
And PostHog does that too with [RFCs](https://posthog.com/handbook/company/communication#requests-...) when you require some sort of smart collaboration. The way I read OP's post is not about isolation, but rather about trust.
> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?
That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.
> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks.
So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?
scrum planning doesnt usually get too nitty gritty on implementation details in my experience if you dont want the meeting to last 4 hours.
i get preplanning big picture architecture or strategy, but i CANNOT plan out the actual code i write. i'm not sure if i just develop deficient mental models of the codebase, but my process for figuring out what to build is to just sit down and build it. my process is very iterative. lots of stubbing things out and working backwards (if i need this function to return an X, it needs args A and B which means it might be better as a method for this class over here...)
the only way i could come up with a precise plan for how the code needs to change is to just build the thing.
Consider this: you could, given enough time. You probably haven't had management that gave you that time. Or demanded you take the time.
Writing things down takes a lot more time than you think. It is hard work. You get better with practice.
You would find, if you were given the time, or permitted yourself to have that time, that you would find all the skills you have accumulated up to this point would converge into that plan. There is a very exciting zen you get into writing things down and you can think about the architecture and the people and the teams involved, and it's a very different thing to create. And very satisfying.
Then you'll be a senior engineer.
So a design doc?
"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.
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.
But the click bait was conceived and written super fast by a daring driver!
The problem is design by committee.
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.
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.
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
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.
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.
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.
If each person can eat half a pizza, you've reinvented the Amazon approach: https://martinfowler.com/bliki/TwoPizzaTeam.html
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 (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.
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?
Pair programming.
That was too easy.
Cross-Functional Teams
Github Copilot
This is like playing both sides of the board in chess and claiming you had an opponent.
“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.
“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".
> 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.
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.
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.
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.
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.
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.
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.
I can see how the lack of collaboration lead to the posthog.com website design.
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.
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.
I think it’s one of the best marketing websites for a SaaS I know, if not the best. Taste is clearly subjective
>>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"
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.
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.
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.
Or medical software. It's great advice for people building products which don't need to work correctly up into the high 9s.
> others feel obliged to give feedback because we have a culture of feedback.
See also "bikeshedding". Made famous by FreeBSD core developer Poul-Henning Kamp (phk). I see there is now a website dedicated to his email: https://www.bikeshed.org
In short: people give feedback and quibble because they can, to demonstrate that they're participating, that they can contribute.
Being aware of this habit and inhibiting it is something I teach to every new employee in my team. (If you know how to avoid it always, teach me)
You don't really need to explain bike shedding to HN.
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.
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.
Everyone reading this article: Don't fall for it.
There're scientific evidence that collaboration > individualism. Please, just search online about it. If it wasn't the case, do you really think every company in the world would just work in collaboration without any particular reason?
https://atlas.northwestern.edu/wp-content/uploads/2017/03/De... https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/... https://journals.sagepub.com/doi/10.1518/001872008X375009
>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 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.
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".
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.
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).
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).
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.
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.
> 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.
Sometimes you can't get every staff engineer to agree to the plan, but you can't sit around forever unto someone caves.
It's called "thinking from the principle" for a reason.
You will have to re-invent the whole product from the start...
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.
> 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.
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
> 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".
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.
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
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 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.
Programming isn't a sport.
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.
This is such a great response. It leaves me wishing I could delete my comment. A.I. told me there was a 2020 match between Lakers and Globetrotters which the Lakers won. Turns out it was a fictional match. I've had great success with mob programming so that's where my brain was at.
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.
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.
"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!
Sounds much cooler than what my management likes to call it. RACI or RASCI for every key project.
If this takes off, I think you've coined a new term there with "Quantum Sync Circle."
The Conjoined Triangles of Success
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.
I'm a little disappointed at the amount of me tooism in this thread. I think a lot of people here have maybe had really bad collaborative experiences. Maybe that's the default? most orgs are going to be bad at most things (tm).
I can't help but think about this paper I ran across over a decade ago, that found a very high correlation between team diversity and paper citations.
https://arxiv.org/abs/1803.02282
This one always stuck with me, partially because of personal biases, but also because it just seems so powerful to have access to different perspectives when trying to build something. I know from personal experience, that when someone on my team has something unusual about them, when we build a thing with them in mind, the final product is just better. It might be related to the old advice of making sure that everyone's computer is different to make it more likely to run into bugs. Or make sure the devs don't have the fastest computers so they notice performance issues. But I also see it a lot in gaming too. If you tell me a game has color blind settings, that immediately gives me a big hint as to the quality of the rest of the game.
So this begs the question to me. What is it about building with someone in mind that is different than the collaboration that the author is talking about? Like, we expect committees to produce spheres. And we expect bike shedding to derail meetings. But what is different? is it agency? is it a single vision for the design? There is definitely something to be said for having one person who really understands the problem being the one to arbitrate all decisions about the thing. Is it how criticism is offered, or maybe whether a criticism can be ignored without social backlash? Is collaboration really that different than customer feedback which is generally seen as healthy for a product?
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.
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
You can collaborate with smart and driven people. For the rest, you can "collaborate", which means doing it yourself and sharing the credit.
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.
No so much about why collaboration sucks as and argument for how important direct ownership / responsibility is. Good post.
You guys need to work on harder problems.
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.
For real. The only collaboration that is super fast is between yourself and Claude Code.
It's quality isn't your main metric then ya, knock yourself out.
Ownership and trust
This spoke to me and hits hard
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.
I love this, thank you posthog for being great
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.
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.
damn. super cool that posthog is acknowledging the pains of growing even at their scale.
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
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.
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.
The dose makes the poison.
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.
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"
Related: https://www.sternberg-press.com/product/the-nightmare-of-par...
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.
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.
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.
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.
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.
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.
wow add Posthog to Places Id Never Work
"you asked someone what they thought of your approach? BAD! that's not our culture!"
This kills the product manager, though.
That's why it still persists.
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 is so dumb, its how you end up with 37 versions of the same thing.
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.
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.
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"