101–110 of 262 posts
"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.
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.
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 sol…
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…
> 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.
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.
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.
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.
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 can see how the lack of collaboration lead to the posthog.com website design.
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.