Collaboration sucks
Be the driver
“If you want to go fast, go alone; if you want to go far, go together”
This phrase will slowly kill your company and I’m here to prove it.
Imagine you are driving a car. It’s often useful to have someone give you directions, point out gas stations, and recommend stops for snacks. This is a helpful amount of collaboration.
An unhelpful amount of collaboration is getting out of your car to ask pedestrians if they like your car, swapping drivers every 10 minutes, or having someone constantly commenting on your driving.
In the first scenario, you get the right amount of feedback to get to your destination as fast as possible. In the second, you get more feedback, but it slows you down. You run the risk of not making it to the place you want to go.
The second scenario is also the one most startups (or companies, really) end up in because of ✨ collaboration ✨.
Being good at feedback means knowing when not to give it
As PostHog grows, I’ve seen more and more collaboration that doesn’t add value or adds far too little value for the time lost collaborating. So much so we made “collaboration sucks” the topic of the week during a recent company all hands.
“You’re the driver” is a key value for us at PostHog. We aim to hire people who are great at their jobs and get out of their way. No deadlines, minimal coordination, and no managers telling you what to do.
In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself. Marketers ship code, salespeople answer technical questions without backup, and product engineers work across the stack.
This means there is almost always someone better at what you are doing than you are. It is tempting to get them, or anybody really, involved and ✨ collaborate ✨, but collaboration forces the driver to slow down and explain stuff (background, context, their thinking).
This tendency reveals itself in a few key phrases:
“Curious what X thinks”
“Would love to hear Y’s take on this”
“We should work with Z on this”
This sometimes leads to valuable insights, but always slows the driver down. It erodes their motivation, confidence, and effectiveness, and ultimately leads us to ship less.
If collaboration sucks, why do people do it?
Everyone is to blame.
People want to be helpful. For example, when someone posts their work-in-progress in Slack, others feel obliged to give feedback because we have a culture of feedback.
On the flip side, people don’t ask for feedback from specific people because it doesn’t feel inclusive, even though it would help.
People aren’t specific enough about what feedback they need. This creates more space for collaboration to sneak in. A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.
When someone has a good idea, the response often defaults to “let’s discuss” rather than “ok, do it.” As proof, we have 175 mentions of “let’s discuss” in Slack.
People just want to talk about stuff because they
are too busycan’t be bothered to act on it. We drift from our ideal of a pull request to an issue/RFC to Slack (we are mostly here) to “let’s discuss”.It’s not clear who the owner is (or no one wants to own what’s being discussed).
It is annoying, but sometimes a single person can’t ship certain things front to back to a high-enough quality and we can’t just ship and iterate. We can fix broken code, but we can’t resend a newsletter.
How to crush collaboration (and go farther, faster)
So if collaboration is your enemy, how do you defeat it? Here’s what we say:
Default to shipping. Pull requests > issues > Slack messages.
Every time you see ✨ collaboration ✨ happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).
Tag who you specifically want input from and what you want from them, not just throw things out there into the void.
Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
If you are a team lead, or leader of leads, who has been asked for feedback, consider being more you can just do stuff.
When it’s your thing, you are the “informed captain.” Listen to feedback, but know it’s ultimately up to you to decide what to do, not the people giving feedback.
Unfortunately for me, not all collaboration can be rooted out, and even I will admit that some collaboration is useful. Ian and Andy edited this newsletter after all.
The point is, if you aren’t actively attempting to collaborate less, you are probably collaborating too much by default and hurting your ability to go far, fast.
Words by Charles Cook, who also hates sparkling water, presumably because the bubbles are too collaborative.
👷 Jobs at PostHog
AI Product Engineer working on PostHog AI, LLM Analytics or Array teams.
Backend Engineer for Feature Flags and Ingestion teams
Influencer Wrangler on the Marketing team
YC Technical Onboarding Specialist on the Onboarding team (San Fran based)
ClickHouse Operations Engineer on the ClickHouse team
📖 More good reads
Workflows are now in Alpha and I already broke mine – Sara Miteva
Your data model is your destiny – Matt Brown
Spinning Plates – Dylan Martin
1000x: The Power of an Interface for Performance (video) – Joran Dirk Greef
PostHog dropping a bomb 💣
At first, I was apprehensive reading this. I had to work 3 years with a "cowboy coder" colleague who I often found difficult to work with, and who rarely seemed to listen to whatever little feedback he occasionally received. I, however, have tended towards the opposite extreme - frequently asking my colleagues, "should I do it this way?", or "lemme bounce this off you", often when it would have been simpler and more efficient to charge forward and execute, then get feedback later. This article is a good reminder that there _is_ such a thing as too much collaboration. :)