Collaboration sucks
newsletter.posthog.com
newsletter.posthog.com
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.
("People don't leave jobs, they leave managers")
I tried joining other teams but without going into elaborate detail it didn't pan out.
It's also a good way to get into areas you have no experience of.
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 think the designs are often better when people write down their goals, non-goals, assumptions, and alternatives rather than just writing code.
* Reading previous designs helps new people (or even LLMs I guess) understand the system and team design philosophy.
* It helps everyone evaluate if the design still makes sense after goals change.
* It helps explain to upper management (or promotion committee in a large company) the work the author is doing. They're not gonna dig into the code!
...so it's usually worth writing up even if not as a stage before implementation starts. It can be a quick thing. If people start using a LLM for the writing, your format is too heavy-weight or focused on style over substance.
There's definitely a negative side to approval stages before shipping, as this article points out, but when quality (reliability, privacy/security, ...) is the system's most important attribute, I can't justify having zero. And while getting the design approved before starting implementation isn't necessary, it should avoid the bad experience tombert had of having to redo everything.
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.
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.
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.
The stuff you are complaining on the first line is. But also, Taylor was an advocate for listening what the workers had to say too. You can't really blame Taylorism on him, he invented only the mildest parts of it.
And that said, Deming advocated standardizing work too. You just can't run a factory without doing that.
Collaboration is between peers. Taylor was top-down. That’s dictatorial, not collaboration. When you take collab out of the mix it’s a product manager and one dev and that’s a power imbalance.
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.
At the very least we know there isn’t an inverse correlation meaning the stereotype isn’t really true.
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.
About 30 percent of developers have no degree. Which means… if the average graduate of CS is 130, how low does the average swe without it a degree have to be in order to bring it down to 110?
I mean I spelled out the math. Dear readers, Draw what conclusion you want from that while asking yourself: “Do I have a degree?”
I will say that iq varies heavily across schools as well.
> 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.
So if your decisions are getting turned over, you are either making decisions outside of your scope or your management is genuinely micromanaging you.
EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework
The four worst words on a software project are:
“Why can’t you just…”-- Krazam, "Microservices", https://www.youtube.com/watch?v=y8OnoxKotPQ
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.
"Can't we just..."
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.
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.
On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing.
If a manager, denotationally, can call out that there is something missing, then it was not implemented right.
And that is where the friction is. A lot of these requirements are implicit.
For example; If an application is built around Protobuf / gRPC and you suddenly start doing JSON / REST you are going to need a really, really good reason for that. Since you are introducing a new technology, with all it's glory and all it's horror. So your judgment is going to be questioned on that and most likely the reaction will be; We are not going to do that.
That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.
A great way, you say. Taking notes!
Though I guess it is in tune with "no managers telling you what to do."
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)
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.
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.
In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.
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.
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 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.
This is a great observation. Having a PR feedback process that involves everyone commenting on every tiny decision is a guaranteed way to end up with "design by committee" syndrome. Everyone feels obligated to push their little agenda, no matter how insignificant it may be. The end result is what the original article tries to explain: When everyone is responsible for every PR, no one is really responsible for any PR. The quality and suitability of the code are not proportional to the volume of feedback the pull request receives. There is a sweet spot, and beyond that, quality and development velocity deteriorate quickly
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.
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
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.
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.
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.
"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.
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
Let people know if you have a requirement on layout and enforce it. Code review is far too late.
And I'm fine with that.
Consistency is key for readability, code is read more than written, legacy code is code that people can't read anymore and want to start again, and most of the changes people want to make aren't standard making it harder for new team members to read the code.
Install Black, Prettier, Spotless, and move on.
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 is not a "culture of collaboration" by any means.
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.
> 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.
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.
> 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.
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.
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.
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.
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"
:)
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.
This is how things get done.
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.
Why not just: ship it, get feedback from actual usage, iterate.
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.
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.
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.
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
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.
the only way i could come up with a precise plan for how the code needs to change is to just build the thing.
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.
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.
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?
And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins..
It's not perfect, but if you're gonna do planning, just do it properly.
How? Even if you decide you need everyone to look at it, letting everyone check it off asynchronously is more respectful of people's time and concentration. Maybe occasionally there's a big difference in people's assessment and you need to have a synchronous discussion, but there's no need to pessimize the common case for the sake of the rare case.
> It's not perfect, but if you're gonna do planning, just do it properly.
What's "properly"? Doing your planning in a more difficult, time-consuming way might feel virtuous, but it's not actually beneficial.
On some level this is just basic project planning, which in my view is an underdeveloped skill in most modern engineering teams. In the case of the ‘empty ticket’, it’s project planning but at a lower level. Not every bit of work needs this, but many would benefit, especially when the taskee is at a more junior level.
I wholeheartedly support this approach. Nearly every major project requires a team, not an individual, and coordinating and collaborating are basic functions of getting things done.
- Winston Royce, "Managing the development of large software systems"
That said I've also seen over-collaboration lead to a similar situation. In that case everybody ends up with their own personal model of what the plan is, based on their own interpretation of all the endless talking around in circles. Maybe there is also a design document that purports to be the source of truth, but nobody is actually paying attention to it. Possibly because all the bickering and confusion turns maintaining it into an impossible task.
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.
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.
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
The problem is that deciders are almost always picked for their ability to kiss management's ass as opposed to their technical savvy.
I would agree with you if companies started embracing workplace democracy and electing the decision makers.
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.
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.
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 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.
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.
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".
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.
By the time a race engineer is communicating with a driver all of that has been shaken out. Specific concrete options are given to the driver, and usually only one.
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.
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.
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.
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.
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.
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.
I've seen the opposite problem many times. Someone has confidently implemented something terrible, and I'm just thinking, why didn't you ask anyone about this!
Posthogs solution seems to be to "only hire very good people". Which is kind of funny to me. That might be possible in a hip company working with exiting new tech. But for many companies such as "boring" companies with old outdated stacks or start ups with no money, that just does not seem to be possible, at least in my experience.
Don't confuse this with "Don't test and don't do code reviews"
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.
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.
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.
The way to solve for that is force additional business ownership onto the developers. When there is increased liability and increased risk of failure the developers will know exactly the right amount of feedback to provide, especially to each other, because are operating conditions are dictated by velocity and code quality baselines.
I am saying this as a software manager of people.
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.
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)
Agree with: people are employed to do a job, they should be empowered to get on and do it with minimal supervision, escalation, and distraction (particularly from "PR Theatre"). Also agree that sometimes unity of vision and focus time can yield exceptional results.
However, this doesn't work unless you can work every part of a system with a high-level of alignment with vision and commercial context to make good decisions and you test mercilessly. I know, have worked with, and still work with, an "entrepreneurial developer" type who can do that, but over time their "isolationist" approach leads to misaligned features that are usually anathema to good by the end of the startup phase.
Additionally, the ability to work with that level of alignment and autonomy simply doesn't describe the majority of the developers on the market and who really just want to be given tasks in their area of skill. Are they acceptable for a startup? Probably not. But in the SME context that's fine because collaboration fills the gap.
Also, while there is a lot to be said for T- and V-Shaped engineers, I-Shaped engineers are much more common and that's not a bad thing because – if one can get a designer, fe, be, and operator collaborating _effectively_ – you can still get good results.
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
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.
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.
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.
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.
People love to invent reasons why they can not do something. "I need help", "I don't know", "I don't want to decide this", then they use these reasons to do performative work, meetings, pair programming, etc.
Collaboration happens when multiple people want to achieve a goal together. What the article calls "collaboration" is multiple people not wanting to achieve a goal, while pretending to want the opposite. These shouldn't be conflated, as actual collaboration is enormously powerful.
The author addresses issues that I would not relate to the concept of collaboration as a specific type of groupwork.
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).
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.
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.
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.
You will have to re-invent the whole product from the start...
Driving is one way to get around; it's not the only means of transportation.
Collaboration is useless in deterministic predictable environment with a single source of truth. When you deal with lot of ambiguity,constant changes and need to adapt then you have no choice that collaborating and getting a feedback loop.
You can win alone, but you can’t lose alone.
The value of collaboration, just like most other things, depends on implementation and circumstance.
"If you're not at least at a 7 out of 10 in terms of paying attention / understand the topic ... please refrain from participating."
I know it can't be done, but I think it would help if you COULD do that.
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).
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".
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.
And it's beautiful when that happens.
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 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?
Some of us like quality products. Maybe I am just old fashioned.
"you asked someone what they thought of your approach? BAD! that's not our culture!"
It also borders on a kind of edgelord attitude that I've seen from people who I wish not to work with again.
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.
> 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.
That's why it still persists.
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.
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.
...
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
...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.
Measure(communicate) twice, cut(build) once.
The two are literal polar opposite.
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.
Vs Boss: "your call"
And all collaboration that will be needed is perfectly anticipated then shifted to compile time by being designed into the system on day one. Everyone just does their bit and the whole thing functions perfectly, because the designers anticipated everything.
So yeah, no need for collaboration
/s