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 XXXX 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-XXXinsidious?XXX-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 the world into which XXXXXX contemporaneous octogenarian XXXXX-- XXXX subtractive colors XX tastes-worse-than-even-its-shitly-pallor-would-suggest goulash XXXX
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.
Measure(communicate) twice, cut(build) once.
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.
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.
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.
("People don't leave jobs, they leave managers")
It's also a good way to get into areas you have no experience of.
A great way, you say. Taking notes!
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.
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.
> 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 "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.
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.
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.
It also borders on a kind of edgelord attitude that I've seen from people who I wish not to work with again.
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.
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.
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.
The two are literal polar opposite.
Vs Boss: "your call"
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.
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.
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.
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.
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
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's why it still persists.
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 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.
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.
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.
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.
"you asked someone what they thought of your approach? BAD! that's not our culture!"
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.
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.
...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.
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.
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...
...
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
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)
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?
Driving is one way to get around; it's not the only means of transportation.
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.
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).
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 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".
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.
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.
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.
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.
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.
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.
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.
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.
Some of us like quality products. Maybe I am just old fashioned.
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.
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.
ssalmon74•1h ago
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.
kevinob11•1h ago
kingforaday•1h ago
agildehaus•1h ago