> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).
Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively request your report to go back and make changes. This is a great way to lose employees.
One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.
Yep. There are many, many teams at Apple. Your manager makes all the difference in the world. Hated working on the Photos team at Apple, loved all the other teams I worked on. (So I left the Photos team to go work on a team where the manager was cool. I was able to stay at Apple, just move about.)
I normally move within a company when I want to quit a manager. It's much easier than getting an entirely new job usually. And you have a lot more information about the potential role.
It's also a good way to get into areas you have no experience of.
There are worse outcomes than that. Software devs are clever people. Not all of us can be confrontational, and confrontation is not the only tool available to those who can.
If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them.
They’re letting you choke to death on your own arrogance and control issues.
We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average.
It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both.
But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that.
Developers may be hired for cleverness, but cleverness in code and technical matters does not necessarily carry over into cleverness with respect to office politics or good management.
Cleverness in code actually correlates with cleverness in social aspects. People come up with this artificial dichotomy of the awkward nerd with high iq but zero social skill but the reality is both of the two correlate slightly.
At the very least we know there isn’t an inverse correlation meaning the stereotype isn’t really true.
It’s not clever to brag about how smart you are or imply you and your entire cohort are smarter than other occupations. It’s a sign of how much you are the opposite of clever.
Additionally the average IQ of software developers is measured to be 110-113. That’s barely above one std of the average so you’re actually wrong. Software devs aren’t particularly clever but a disproportionate number likes to think they are smarter than normal.
So bragging about something that you’re completely wrong about… is that clever? No.
"Delivering this feature goes against everything I know to be right and true. And I will sooner lay you into this barren earth, than entertain your folly for a moment longer."
I once worked at a place where one of the partners consistently claimed the engineering team over-built and over-thought everything (reality: almost everything was under-engineered and hanging on by a thread.)
His catch phrase was "all you gotta do is [insert dumb idea here.]"
It was anxiety inducing for a while, then it turned into a big joke amongst the engineering staff, where we would compete to come up with the most ridiculous "all you gotta do is ..." idea.
I'm there right now at my current job. It's always the same engineer, and they always get a pass because (for some reason) they don't have to do design reviews for anything they do, but they go concern-troll everyone else's designs.
Last week, after 3 near-misses that would have brought down our service for hours if not days from a corner this engineer cut, I chaired a meeting to decide how we were going to improve this particular component. This engineer got invited, and spent thr entire allocated meeting time spreading FUD about all the options we gathered. Management decided on inaction.
Similar to my experience doing low-level systems work, being prodded by a "manager" with a fifth of my experience. No, I'm not going to implement something you heard about from a candidate in an interview, an individual whom we passed on within the first 30 minutes. No, you reading out the AI overview of a google search to me for a problem that I've thought about for days ain't gonna work, nor will it get us closer to a solution. Get the fuck out of the way.
Exactly, these two sentences seem at first related,
> No deadlines, minimal coordination, and no managers telling you what to do.
> In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself.
but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.
I think the real problem here is "decision making" as opposed to "collaboration"
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
This is the key insight for me about this post, and I fully agree with you.
No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth.
Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all relevant parties. As long as they trust that they're being listened to, they don't get a say in the actual decision making process themselves.
I also agree about taking reversible decisions faster.
Another point I deeply disagree with is
> collaboration forces the driver to slow down and explain stuff (background, context, their thinking).
Yeah, and that's a good thing. It forces them to properly think through their thoughts, if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.
> 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.
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.
One of the things that good managers/leaders do is not "make decisions", ie do it this way, but increase the number of decisions that can be made autonomously.
THat could be giving guidance; The product is aimed at x, which means that feature y will need to happen before feature z
Or a framework; We choose to prioritise small throwaway prototypes vs ground up intensive planning
or just taking away decision dimensions: buy this software in and concentrate on this other thing
The thing is: once you have feedback, you have to act on it. Ignoring the feedback is dangerous unless sanctioned by higher leadership.
This is our nature, and the blog does hit this point where we default to collaborate.
There is of course a better way. A senior employee should be more intentional about feedback e.g. whether can be done later, put it on a backlog, or must address right now. A junior employee should be intentional about what specific feedback they need.
While I don't agree with Charles' (clearly nuts) distaste for sparkling water, I'm happy to see people finally talking about this issue publicly.
I've suffered through this at several companies, down to the level of sometimes spending like 3x the time it took to implement the actual feature on answering and 'fixing' pedantic stylistic nitpicks during code reviews. While having a homogenous style is important, I'm solidly in the camp of "if you want to give me style nitpicks, just change them yourself, tell me, and save us both some time". This extends to like 80% of feedback I see in code reviews.
Have a formatter. There are plently out there that can be part of the compile/build/commit flow, to the point of failing pipelines if the files you changed not match the style.
Let people know if you have a requirement on layout and enforce it. Code review is far too late.
Where I work the formatter is the final arbiter of formatting code. If you don't like it, good luck justifying a change and you had better have really thought about it and why your change is good, because thousands of engineers have tried and been defeated for one reason or another :)
Other commenter point at auto-formating, but I think companies not using any are pretty rare, hitting that very issue in several companies is highly improbable.
We're probably down to function/variable naming, ternal operators, return types, this kind of thing ?
Someone who can't bother looking around and adapt their style to the surrounding code sounds like a problem to me. What is seen as pendantic and nitpicky can have pretty large impact on readability and go against others' assumptions.
This has no relation with collaboration. Being nitpicky about a PR is wrong, you should have a linter or enforce the culture of not being nitpicky about code.
This is not a "culture of collaboration" by any means.
Every delivered feature is a liability not an asset.
If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.
So if I deliver a feature all by myself quickly and move on to something else, I’m digging a bigger hole and faster than the wisdom arrives to change directions.
But most importantly, none of the rest of you fuckers know what I built or why, except what you gleaned from standup or whatever docs I wrote in place of collaboration. And docs written without collaboration are usually hot garbage.
So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.
> Every delivered feature is a liability not an asset.
> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.
You're mixing up the feature and the moving parts.
A feature is an asset. Moving parts (or code) are the liability. They are not the same.
Sometimes you can even improve the product by removing code, or refactoring things so you have less or clearer code while at the same time improving the product. Maybe you unify some UI, so more functionality is available in more places, while also cleaning up the code, maybe reducing line count.
> So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.
It's a fair point, but depends on the scale I would say. Some smaller things can be easily understood (but maybe that's not the stuff that causes the cluster to be on fire). Also, IMO at least one person should have reviewed the stuff, and therefore be at least a little bit knowledgeable about what's going on.
> You're mixing up the feature and the moving parts.
No, you are, and this is why so many of us are shit at UX.
The ability to accomplish a task with software is an asset. Not every application takes the same number of interactions to finish a task, and each interaction is a feature.
Features in neither waterfall, scrum, nor Kanban directly correlate with the ability of the user to accomplish something meaningful. They are units of measure of the developer accomplishing something meaningful, but the meaning is assumed, not real.
> Every delivered feature is a liability not an asset.
> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain?
Wrong analogy, use the word feature in both emphasized terms. Consider two products and one has half as many features, which is more profitable to maintain? Well, it depends whether people are paying for the other half of the feature set or not, as oftentimes people will pay for more features than fewer.
It’s a perfectly fine analogy if you can get over your own ego enough to realize your customers don’t want to hear about how very clever you are, they just want to get shit done and move on to four other tasks.
They don’t care about us. They don’t. They just want to do what their boss asked them to do or kill the bad guy to get the treasure, and we are often enough as much in the way as we are facilitating that.
The author talks about having a clear bias for action (a great thing!) but in the process throws the baby out with the bathwater. Without collaboration you'll end up with silos, overconfident decision-makers, and all sorts of preventable production issues, all in the name of avoiding the dirty C word. How about following the approach of pragmatism and finding a solid middle ground that achieves the best results longterm? I suppose that doesn't tell a great story in company all-hands and corporate blog posts.
On the bias for action front, one trick a previous company implemented that worked wonders was stating (in Slack, meeting, whatever): "I'm planning to do X, any strong objections?". The strong objection part generally dissuaded most lazy bike shedding, especially if paired with "do you really feel strongly about it". Of course if people do, then you have a discussion, but most of the time it's a thumbs up and off you go.
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really smart collaboration and not in progress collaboration.
Getting things done is an important metric.
Getting the right things done is much harder to measure and I think the hive mind helps a lot with this.
If you have good writing skills and can communicate well about what you are working on, feedback and collaboration can be fast and effective. And, is the only barrier to tunnel vision. You cannot be a good engineer without some kind of self absorbed focus on a problem, and you can easily lose sight of the forest in the trees when doing that. Without collaboration it is unlikely you can pull yourself at the optimal time.
"Perseverance bias" or "sunk cost fallacy" and "cognitive entrenchment" are not mentioned in the article, but they should have been.
We've lost focus on the importance of good writing skills and good communication skills. AI is going to make that so much worse. If you can effectively communicate in progress tasks, many of the collaboration problems described here can be avoided.
I worked on a team that did something like that for important stuff. (We didn't bother for the relatively routine or uncontroversial changes.) Although in our case we did it in a team meeting rather than asynchronously.
It really was horrendously valuable. Many, many times someone would save a their teammate an ungodly amount of time by pointing out an easier way to do something. It was a big complex system so naturally none of us could be expected to know every nook and cranny.
> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?
That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.
"Unfortunately for me, not all collaboration can be rooted out, and even I will admit that some collaboration is useful. Ian and Andy edited this newsletter after all."
So "good" collaboration does work. It is just that the post is talking about things that are not really true collaboration and those should be avoided. Title is click bait but posthog is famous for these.
Framing obvious/old ideas in a novel way can be helpful. "Collaboration" is a meme that makes it easy to view all collaboration-shaped exchanges as helpful and the opposite as harmful. A memorable counter-narrative can help people think more critically when faced with an applicable situation.
This is simply an awful thought piece and is wrongheaded.
The problem is not collaboration nor feedback. It is the lack of a decider. Deciding by committee is a bad way to run as an org grows. Collaboration is still key.
One person needs to be the person who decides. Decides what? That is the trick. The further down you push decision making, the faster things go. But someone is the decider, not a group.
Yes, exactly. In many cases you don't exactly need to involve the whole group but without a decider things stall out. And suddenly getting a decision about something looks like "collaboration", and gets struck down by the great confusion which is this authors take. It's a lack of decision making, simply put.
Articles like this are quite poisonous, because they take language and mutate it for purposes that aren't quite sincere, and then next thing you know something necessary and good is worthless.
If I don’t like my coworkers, I’m out. I like people who give a shit about the work I do (a.k.a “collaboration”). “Whatever, you own it” is just lazy for “I can’t be bothered to understand what you are working on”.
The problem is not the collaboration, it’s the ineffective collaboration. Maybe the author should fix that instead of pitching magic anti-collaboration click-bait pills.
Also, the problems you solve must be pretty straightforward and unambiguous (or you have a small codebase) if you have the luxury of being able to just make a pull request for it.
It's obviously written in a "hot take" fashion, to be deliberately provocative. Taking it literally would be foolish but there is certainly some degree of truth in there.
Any meeting with more than 3-4 people (and maybe even less) is probably a waste of time.
Creating a PR doesn't mean everyone just accepts whatever change you've made. But it certainly gives something unambiguous and tangible for people to form their objections around. Rather than objecting to some misinterpretation of the idea in their own head.
Taking the article's analogy of the "collaboration while driving", the F1 sport is quite insanely collaborative. For example, the drivers literally do have someone in their ear by radio being their coach and spotter for the entire trip. I've never heard of the equivalent in software. Does anyone know of anything like this?
I feel like collaboration can work great with a group of exactly two people. It's not terribly hard for two people to partition work and actively help each other. With two people working on a project, both people can realistically understand most of the codebase, and can competently review each other's pull requests.
I feel collaboration suffers from combinatorial complexity though, and I feel any number bigger than two ends up doing more harm than good. Once you have more than two people, the codebase starts becoming more segmented, it becomes really difficult to agree on decisions, and the project becomes a lot harder than it needs to be.
If I ever get into management, I think I will try and keep this in mind and try and design projects around two-people teams.
“If you want to go fast, go alone; if you want to go far, go together”
I've often noticed that this is a favourite phrase of those whose preferred motion is narrating other people's work rather than doing it themselves. Teams do go further together. But only when everyone is rowing.
In the original article the author says "ultimately leads us to ship less." as one of the drawbacks to collaboration. Says a lot really, if quantity of features shipped is a priority. Great way to build a feature factory, everyone shipping without feedback and having others question what you are doing.
This sometimes leads to valuable insights, but always slows the driver down.
In cases where the insight is genuinely useful that's better than going fast mostly because you were probably going fast in the wrong direction. Ideally you would optimise collaboration to increase the likelihood of valuable feedback (because that saves more time and money) rather than optimizing for speed.
That said, I've lost track of the number of meetings I've been in so that someone can cover their ass by making something a 'collaborative decision' instead of taking responsibility, so I can totally see where the author is coming from.
Elon Elias Musk saw right through this as he silently stared at each and every one of Twitter's dream-team that was expecting the ride to go on. He saw right through the cracks, the Staceys, the Mikes. He had the final tweet and blew most of the crew. He would agree with you Charles, he would agree to the point of saving screenshots of your website so you can collaborate with his memes.
One reason for collaboration is to raise the bus factor.
For small to medium-sized applications, it's not hard to get a single good developer to crank out feature after feature... but they're the only one that understands any of it. Then that single developer is hit by the proverbial bus (or Corona, or retires, or resigns, or whatever...) and you have important software without any maintainer.
That might be OK for some startups where the expectation is that the code will be thrown away and replaced by something better pretty quickly, but for slower organizations, that's often a nightmare scenario.
Collaboration slows things down but going fast at all cost leads to tech fragmentation, tech debt, and product debt.
fwiw I'm not in the camp of "we must have everything done in one consistent way" but there are places, for example a public API, where having 4 different names for the same concept, 3 different response format/url path styles, etc. starts to look really sloppy.
In my company we have the best of both worlds - things are slow as hell and there's shitload of tech debt. This is direct result of "collaboration" aka "nobody actually owns anything". I put forward a proposal to standardize various things across our software, and in response my manager called a meeting of 10 people. No proposal can survive a meeting of 10 people at once.
IMO the best way is to split your organization into units that nicely map with technological/business boundaries, and then give each unit the responsibility to own something tanglible. The problem is, if the organization is full of idiots, everyone tries to do the opposite, in order to diffuse the responsibility.
For relatively straightforward groups whose tasks are self explanatory and/or isolated, sure. For any kind of invention, however, I don't think this line of thought works. Alan Kay has said in a number of places that Xerox PARC (likely) couldn't have worked if they had been remote, nor could it have worked if they hadn't had the time they did to goof off, argue, share hypotheticals, etc. Developing a shared intuition and connection with others in your group is an immeasurable quality that doesn't get enough love.
In other words, if your organization is made up of a bunch of geese that lay golden eggs, by all means let them lay eggs, but don't ignore the fact that your organization could itself be a goose that lays golden eggs together.
I don't think this is good advice for building, programming, or operating spacecraft.
Edit to add detail: a spacecraft tends to have lot of subsystems that need to work together well, each requires a specialist lead, and there's a high return on investment for things like improving efficiency, sharing resources between subsystems, etc. leading to reduced power, data, and mass requirements. They tend to be bespoke and high value so it's critical that detail knowledge is spread among multiple people, edge cases are carefully considered, and lessons learned get learned by everybody. Collaboration is key in that kind of endeavour. If you're slapping together a CRUD app that can't hurt anyone, sure, go hog wild.
>>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
Don't confuse this with "Don't test and don't do code reviews"
The line you quote is oddly one of my strongest arguments against Scrum.
Agile in general and Scrum in particular don’t want to declare things as done when they aren’t and if you haven’t yet given feedback, is it really Done? I don’t think it is.
With Scrum the pressure to put away the done thing and start something else is very high. The moment you start thinking about your next story, unless it’s very closely related to the previous, your ability to accept feedback becomes quickly curtailed.
This is half of the point of Continuous Integration. Fast feedback is often the only feedback that causes behavioral changes. Things that happened a while ago become abstract. Think about a conversation you’ve seen where someone describes how another person hurt their feelings yesterday, versus five years ago. The reactions are very different.
So if you enjoy talking, I suppose it “works” for you but if you hate having to give the same correction over and over, you need to make the person stop and go back until they learn how not to get stopped. Anything else loses the war.
I interpreted it as a joke, although I couldn't help but agree with a lot of what I think was meant to be ironic.
The problem I always run into is that the potential usefulness of collaboration breaks the insistence on predictability: nothing can be done unless it can be put to, and measured against, a date and a timeline. Collaboration is inherently unpredictable and worse, spreads blame around, so there's always this insistence that collaboration take place in very constrained ways (usually in the form of pointless meetings to review line items in a text document that doesn't end up being very useful).
This is an example of why collaboration and feedback before launch are mostly useless.
Posthog is obviously successful. The design is good enough. But is it perfect? nah. would a better design make it more successful? highly doubt it.
If we were to take this feedback seriously, then we would've halted the launch and redesign the site. Now imagine having 10+ feedback like this. This would significantly delay the launch which would impact the success in a significant way.
>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
This works for software dev. Would be more difficult in anything else, where you're not constantly updating an existing product on a weekly basis.
> others feel obliged to give feedback because we have a culture of feedback.
See also "bikeshedding". Made famous by FreeBSD core developer Poul-Henning Kamp (phk). I see there is now a website dedicated to his email: https://www.bikeshed.org
In short: people give feedback and quibble because they can, to demonstrate that they're participating, that they can contribute.
Being aware of this habit and inhibiting it is something I teach to every new employee in my team. (If you know how to avoid it always, teach me)
This is a fun piece, though I definitely don't agree with it for the teams I have been in.
OP seems to assume that code is better than no code. Often this has not been true, and collaboration has either pointed out that a feature already existed, or was a bad idea. So in this metaphor, it stopped the driver...from driving to a bad place.
> A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.
Well, if the product roadmap doesn't hold up to scrutiny, it _should_ be reevaluated. Too often people commit to something, and then continue building it, despite the market realities having shifted underneath them. I see most teams not asking themselves often enough "should we still be doing what we're doing", than the opposite. The sunk cost fallacy is real.
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.
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".
There's no one size fits all - what they're saying would absolutely fail at the company I'm currently at, but sounds like it works for them. The key thing is to have a process that works well for the people who are there, and hire people who work well under those conditions. The people who do well at our company would not do well at their company, and vice versa. I don't like how this article makes a claim about what works well for them is actually a universal truth. It really depends on the people there.
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?
I'm a little disappointed at the amount of me tooism in this thread. I think a lot of people here have maybe had really bad collaborative experiences. Maybe that's the default? most orgs are going to be bad at most things (tm).
I can't help but think about this paper I ran across over a decade ago, that found a very high correlation between team diversity and paper citations.
This one always stuck with me, partially because of personal biases, but also because it just seems so powerful to have access to different perspectives when trying to build something. I know from personal experience, that when someone on my team has something unusual about them, when we build a thing with them in mind, the final product is just better. It might be related to the old advice of making sure that everyone's computer is different to make it more likely to run into bugs. Or make sure the devs don't have the fastest computers so they notice performance issues. But I also see it a lot in gaming too. If you tell me a game has color blind settings, that immediately gives me a big hint as to the quality of the rest of the game.
So this begs the question to me. What is it about building with someone in mind that is different than the collaboration that the author is talking about? Like, we expect committees to produce spheres. And we expect bike shedding to derail meetings. But what is different? is it agency? is it a single vision for the design? There is definitely something to be said for having one person who really understands the problem being the one to arbitrate all decisions about the thing. Is it how criticism is offered, or maybe whether a criticism can be ignored without social backlash? Is collaboration really that different than customer feedback which is generally seen as healthy for a product?
I would argue the opposite. If your collaboration sucks IMHO you haven’t done enough. It’s a skill. Imagine you’re playing a team sport and you recommended people play together less to win more games. Now look up Globetrotters vs Lakers.
I think the sports analogy would be passing the ball back and forth in front of the goal instead of shooting. Nearly every time, an athlete with the ball in front of an open goal will take the shot themselves instead of passing. Even in a 2v1 situation, passing is a huge risk and taking the shot has a high likelihood of scoring, so you only want to pass if the defender is leaving your teammate open (usually they split the difference, so it's complicated). Too many passes in a 2v1 guarantees that more defenders will show up and you lose your advantage.
it's funny because the facile sportsball analogy actually fails horribly here. "playing together more" is the absolute last thing that the undifferentiated mass of hundreds of people hitting the like button on a random nonsensical comment need to do more of. the only situation where collaboration of this sort is productive is when you cannot reasonably expect any other participants to have some sort of proprietary knowledge over their domain. think contestants on Survivor trying to put a puzzle together faster than the other team to get an immunity idol, not "i'm gonna mansplain Calculus to Terence Tao".
and man i wish i could go back in time to when i merely thought the "Globetrotters vs Lakers" thing was just a ham-fisted phrasing some sentiment along the lines of "the Lakers are better than the Globetrotters"...
but, unfortunately, i "took one for the team" (read: "collaborated with the team"), and am now dumbstruck as to what could possibly have been meant by this metaphor. for those of you who have yet on this fine day to regret the dual, magical gifts of sight and literacy: apparently the Globetrotters and Lakers played an exhibition match of some sort in 1948. the Globetrotters won 61-59. and it was apparently some sort of watershed moment in America's collective realization that Black people are actually also good at basketball. i wish this was merely my being grouchy, glib, and reductive. but just read the Wikipedia article: that is literally what happened and what it meant. in historical context. that, and nothing more, is the object lesson so signified.
so, now that i have made peace with my dual inabilities to magically unread and unlearn, pray tell: who are the metaphorical Black athletes being discriminated against, metaphorically, in this... metaphor? is the implication that Tammy from HR or Chad the BizDev Bro are better designers than Klaus from the Bauhaus? is it that the Lakers "played together less" than the Globetrotters? surely it can't be that there was a giant societal misapprehension (read: racism) that caused people to systematically misevaluate talent and, as sports experts as you say, pass the wrong people the ball? if only the Lakers had collaborated more, they could have overcome their systematic racism that blinded them to the 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.
Instead of the "Collaboration Sucks" approach, we need to apply Gravitational Pull. For every key project, the Driver defines three essential stakeholders (e.g., Tech Lead, Business Owner, Target User) who form the "Quantum Sync Circle."
Everyone else is noise. This prevents endless discussions and focuses accountability right where it belongs.
"Instead of the "Collaboration Sucks" approach, we need to apply Gravitational Pull. For every key project, the Driver defines three essential stakeholders (e.g., Tech Lead, Business Owner, Target User) who form the "Quantum Sync Circle." - this sentence had me so freaked out with all of its buzz words, but man I think I really strongly agree with it. I love the inclusion of target user!
I’m shocked this title is coming from a PostHog employee but more shocked that is seems to be relating not his experiences but a shared one. But as I read I quickly noticed a problem.
Charles isn’t describing Collaboration.
He’s describing people being voluntold to seek validation from other people. That is politicking and blame diffusion and has fuck-all to do with collaboration.
Collaboration is a small number of people reaching a consensus on a thing, understanding how and why the decisions were made, and executing on those decisions. All of these things are necessities in a 24/7 operation. You need a bus number on everything and how are you going to get a bus number without collaboration? It can be done but it’s slow. Often painfully so.
I think the car analogy is great and also even shows that some degree of collaboration is great! IMO it's about the scale.
Like someone giving you directions while driving, IMO it's great to have input from 1 to 2 people on a PR, and also while planning a feature. For me this has helped me avoid some basic mistakes and helped me not to overlook some pitfalls early on. Same for reviews.
But the screenshot from a PR with ~10 people reviewing it is where it gets crazy, I've never seen that.
Personally I usually just don't add to discussions like that, seems pointless. IMO it's also about trusting your colleagues: probably they have already said all there is to say.
The benefits expected of modular programming are: (1) managerial--development time should be shortened because separate groups would work on each module with little need for communication: ...
Marketers ship code, salespeople answer technical questions without backup...
...and you dentist cuts you hair and your hairdresser pulls your teeth. Because everything is a trade what can and should be learned, except if it's related to writing and selling software.
To be fair, you did not say that marketers ship working and maintainable code, salespeople answer technical questions without backup the correct way. Therefore you might be right, thought.
Take a look at their codebase (posthog is open source) and then tell me again that collaboration sucks, because i feel like the lack of collab is why their codebase is in such terrible condition.
If you know how to get stuff done yourself, start your own company, get stuff done, and enjoy the profits (or losses, depending on how good you are). It's your risk and your reward.
If you are working for someone else, the unwritten rule #1 is that a single employee should not amass too much influence within the company to start dictating their own conditions. So, the management culture averages decisions across multiple people, to make sure the loss of one-two team players won't be noticed.
It can be extremely demotivating if you are smart and capable, but these are the rules of the game. Be nice, get paid, accumulate some savings, make connections with other smart people, learn the market, and eventually start your own game on your own rules. Until then, trying to stand out will get you labelled as a troublemaker, and will hamper your progress in the long run.
good advice, someone should have told me this years ago, when you start, you need to know that this is not your game, work, watch and learn. Don't even think about "this is wrong" "they should do this instead" "they have no idea" "I would do it much better"
My girlfriend enter a new job and she told me about some scenario related to IT, kind of asking for my input. At one point she told the IT guy, who was discussing through emails or chat, that they should hop on a call. I told her that the IT guy probably hated that, but she couldn't understand why.
I think speaking to people is a stressor, it's an activity that drains energy, like running or literally doing anything, but IT people can go for weeks without talking to people, so they have that muscle atrophied and even the slightest of real life interactions feels like excessive to them.
This article is just peak IT. Collaboration is normal man, you probably didn't invent a "it's your call" solution to the "problem" of collaborating in companies. I wish you the best of luck in building your social skills.
I’ve used both approaches and I can’t disagree more. Writing code first might feel faster but it isn’t. It’s great for surface level issues but just muddies the waters for any consequential feature.
IMO this is very dependent on the risk of cutting once, so to speak. I'd imagine that at PostHog, the idea is there's little risk of cutting many times - iterating - and more damage is done by the measuring taking far too long.
This is true but there is another cost. If you carelessly write you can end up with a system which is a mountain of bandaid fixes; an incoherent and unmaintainable mess.
We don't collaborate, we iterate. I'm the lead of my department, so I sst the initial direction of the new feature, discuss it with my team, assign it, and let someone build the basic functionality. Then I'll review it, and I will pick up the code and move things around, refine the UX, refine the code, and then maybe pass it back to the developer for more changes, until we arrive at something really good. It doesn't make anyone unhappy or slow us down, and we often don't know where we're going to end up when we start a new feature. Things are fluid, but we have a goal of making things easy to use. Iteration among the team members also ensures more of the team knows how the code works, and we often learn from each other. Maybe this is "collaboration" but we call it iteration.
You seem to view them as opposites because you expect ownership to mean that all employees are motivated to have a sense of ownership over the whole process. There’s some benefit to that, sure.
The meaning the article is using is that there’s an owner, and they own the project without dilution. There’s not death by committee. One person or one team is given something to do, and they go do it without interference from the rest of the company. Whether what’s delivered at the end is fit for purpose is open to other people’s opinions and input. How it gets implemented and reaches delivery is the exclusive concern of one person or a very small group.
not at all. me, owner of a new feature: hey boss wanted to get your thoughts on this. Boss: "let's schedule a review for next week, and pull in x and y who are familiar with the space"
> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a great way to make friends btw).
Corollary for managers: Do not say "it's your call", then once the decision has been made (and you skipped all the meetings pertaining to that decision), comment about how you would have done it differently and then retroactively request your report to go back and make changes. This is a great way to lose employees.
One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.
One of the many reasons I'm still at Apple. My manager honors my decisions (sometimes, let's be honest, with gritted teeth).
("People don't leave jobs, they leave managers")
Yep. There are many, many teams at Apple. Your manager makes all the difference in the world. Hated working on the Photos team at Apple, loved all the other teams I worked on. (So I left the Photos team to go work on a team where the manager was cool. I was able to stay at Apple, just move about.)
one tactic is forming a group which bullies a manager out of their job. it's depressingly effective and rife within the professional public sector
I normally move within a company when I want to quit a manager. It's much easier than getting an entirely new job usually. And you have a lot more information about the potential role.
It's also a good way to get into areas you have no experience of.
There are worse outcomes than that. Software devs are clever people. Not all of us can be confrontational, and confrontation is not the only tool available to those who can.
If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them.
They’re letting you choke to death on your own arrogance and control issues.
Software devs also all think they're smart and they talk that way and take pride in it. The reality is many software devs are dumb af.
We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average.
It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both.
But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that.
Developers may be hired for cleverness, but cleverness in code and technical matters does not necessarily carry over into cleverness with respect to office politics or good management.
Management often spends less time with the users than we do.
Cleverness in code actually correlates with cleverness in social aspects. People come up with this artificial dichotomy of the awkward nerd with high iq but zero social skill but the reality is both of the two correlate slightly.
At the very least we know there isn’t an inverse correlation meaning the stereotype isn’t really true.
It’s not clever to brag about how smart you are or imply you and your entire cohort are smarter than other occupations. It’s a sign of how much you are the opposite of clever.
Additionally the average IQ of software developers is measured to be 110-113. That’s barely above one std of the average so you’re actually wrong. Software devs aren’t particularly clever but a disproportionate number likes to think they are smarter than normal.
So bragging about something that you’re completely wrong about… is that clever? No.
“trust nobody, not even yourself” applies here for sure.
At my previous job, "what about..." slowly became a trigger word for me
EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework
Closely followed by “This should be an easy lift”
"Delivering this feature goes against everything I know to be right and true. And I will sooner lay you into this barren earth, than entertain your folly for a moment longer."
-- Krazam, "Microservices", https://www.youtube.com/watch?v=y8OnoxKotPQ
I mutter this a lot. Except when I do 95% of the time I perform the easy lift right after.
I once worked at a place where one of the partners consistently claimed the engineering team over-built and over-thought everything (reality: almost everything was under-engineered and hanging on by a thread.)
His catch phrase was "all you gotta do is [insert dumb idea here.]"
It was anxiety inducing for a while, then it turned into a big joke amongst the engineering staff, where we would compete to come up with the most ridiculous "all you gotta do is ..." idea.
Have WE tried using caching?
I'm there right now at my current job. It's always the same engineer, and they always get a pass because (for some reason) they don't have to do design reviews for anything they do, but they go concern-troll everyone else's designs.
Last week, after 3 near-misses that would have brought down our service for hours if not days from a corner this engineer cut, I chaired a meeting to decide how we were going to improve this particular component. This engineer got invited, and spent thr entire allocated meeting time spreading FUD about all the options we gathered. Management decided on inaction.
Similar to my experience doing low-level systems work, being prodded by a "manager" with a fifth of my experience. No, I'm not going to implement something you heard about from a candidate in an interview, an individual whom we passed on within the first 30 minutes. No, you reading out the AI overview of a google search to me for a problem that I've thought about for days ain't gonna work, nor will it get us closer to a solution. Get the fuck out of the way.
"Can't we just..."
> This is a great way to lose employees.
A great way, you say. Taking notes!
I just gave this feedback to my boss today
Exactly, these two sentences seem at first related,
> No deadlines, minimal coordination, and no managers telling you what to do.
> In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself.
but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.
The equivalent of "I told you so". Yeah, you should never do that in any situation.
I think the real problem here is "decision making" as opposed to "collaboration"
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
This is the key insight for me about this post, and I fully agree with you.
No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth.
Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all relevant parties. As long as they trust that they're being listened to, they don't get a say in the actual decision making process themselves. I also agree about taking reversible decisions faster.
Another point I deeply disagree with is
> collaboration forces the driver to slow down and explain stuff (background, context, their thinking).
Yeah, and that's a good thing. It forces them to properly think through their thoughts, if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.
> 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.
For me there are two things about collaboration.
Decision making is one, which you emphasized.
The other is knowing what the collaboration brings to the table and shaping the rules of engagement to fit that expectation. Sometimes you collaborate with SMEs; they bring the domain knowledge - you don't, but you understand the goal better than them. Sometimes you are creating or refining the corporate strategy based on the actions from individual projects or partners; you are learning ground realities from them. Sometimes you need help from others to improve your take on a subject.
In each of these cases, you have to be clear about what you expect from the collaborators (and motivate them to contribute). Without being clear on what the collaboration is about and what they get in return is the number one killer of collaborative projects even though there is no ill-intent anywhere.
One of the things that good managers/leaders do is not "make decisions", ie do it this way, but increase the number of decisions that can be made autonomously.
THat could be giving guidance; The product is aimed at x, which means that feature y will need to happen before feature z
Or a framework; We choose to prioritise small throwaway prototypes vs ground up intensive planning
or just taking away decision dimensions: buy this software in and concentrate on this other thing
The thing is: once you have feedback, you have to act on it. Ignoring the feedback is dangerous unless sanctioned by higher leadership.
This is our nature, and the blog does hit this point where we default to collaborate.
There is of course a better way. A senior employee should be more intentional about feedback e.g. whether can be done later, put it on a backlog, or must address right now. A junior employee should be intentional about what specific feedback they need.
With PRs we prefix comments with issue/question/nitpick. Not everything must be fixed, but it's still useful to at least read the comments.
While I don't agree with Charles' (clearly nuts) distaste for sparkling water, I'm happy to see people finally talking about this issue publicly.
I've suffered through this at several companies, down to the level of sometimes spending like 3x the time it took to implement the actual feature on answering and 'fixing' pedantic stylistic nitpicks during code reviews. While having a homogenous style is important, I'm solidly in the camp of "if you want to give me style nitpicks, just change them yourself, tell me, and save us both some time". This extends to like 80% of feedback I see in code reviews.
Be weird and do stuff. https://www.youtube.com/shorts/DjvVN4Vp_r0
Have a formatter. There are plently out there that can be part of the compile/build/commit flow, to the point of failing pipelines if the files you changed not match the style.
Let people know if you have a requirement on layout and enforce it. Code review is far too late.
Where I work the formatter is the final arbiter of formatting code. If you don't like it, good luck justifying a change and you had better have really thought about it and why your change is good, because thousands of engineers have tried and been defeated for one reason or another :)
> style nitpicks
Other commenter point at auto-formating, but I think companies not using any are pretty rare, hitting that very issue in several companies is highly improbable.
We're probably down to function/variable naming, ternal operators, return types, this kind of thing ?
Someone who can't bother looking around and adapt their style to the surrounding code sounds like a problem to me. What is seen as pendantic and nitpicky can have pretty large impact on readability and go against others' assumptions.
Even more than that, it means the developer has spent no time understanding the surrounding code, and thus is likely adding debt/CRUFT/risk.
This has no relation with collaboration. Being nitpicky about a PR is wrong, you should have a linter or enforce the culture of not being nitpicky about code.
This is not a "culture of collaboration" by any means.
Can't help but think this is human nature.
Ask anyone in a relationship if their partner complains about unimportant stuff. With experience and practice you can get past this stuff.
so... experienced reviewers.
Every delivered feature is a liability not an asset.
If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.
So if I deliver a feature all by myself quickly and move on to something else, I’m digging a bigger hole and faster than the wisdom arrives to change directions.
But most importantly, none of the rest of you fuckers know what I built or why, except what you gleaned from standup or whatever docs I wrote in place of collaboration. And docs written without collaboration are usually hot garbage.
So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.
> Every delivered feature is a liability not an asset.
> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.
You're mixing up the feature and the moving parts.
A feature is an asset. Moving parts (or code) are the liability. They are not the same.
Sometimes you can even improve the product by removing code, or refactoring things so you have less or clearer code while at the same time improving the product. Maybe you unify some UI, so more functionality is available in more places, while also cleaning up the code, maybe reducing line count.
> So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.
It's a fair point, but depends on the scale I would say. Some smaller things can be easily understood (but maybe that's not the stuff that causes the cluster to be on fire). Also, IMO at least one person should have reviewed the stuff, and therefore be at least a little bit knowledgeable about what's going on.
> You're mixing up the feature and the moving parts.
No, you are, and this is why so many of us are shit at UX.
The ability to accomplish a task with software is an asset. Not every application takes the same number of interactions to finish a task, and each interaction is a feature.
Features in neither waterfall, scrum, nor Kanban directly correlate with the ability of the user to accomplish something meaningful. They are units of measure of the developer accomplishing something meaningful, but the meaning is assumed, not real.
> Every delivered feature is a liability not an asset.
> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain?
Wrong analogy, use the word feature in both emphasized terms. Consider two products and one has half as many features, which is more profitable to maintain? Well, it depends whether people are paying for the other half of the feature set or not, as oftentimes people will pay for more features than fewer.
It’s a perfectly fine analogy if you can get over your own ego enough to realize your customers don’t want to hear about how very clever you are, they just want to get shit done and move on to four other tasks.
They don’t care about us. They don’t. They just want to do what their boss asked them to do or kill the bad guy to get the treasure, and we are often enough as much in the way as we are facilitating that.
amen. i don't really care about style/format. my opinion is that if you care you should automate it.
The author talks about having a clear bias for action (a great thing!) but in the process throws the baby out with the bathwater. Without collaboration you'll end up with silos, overconfident decision-makers, and all sorts of preventable production issues, all in the name of avoiding the dirty C word. How about following the approach of pragmatism and finding a solid middle ground that achieves the best results longterm? I suppose that doesn't tell a great story in company all-hands and corporate blog posts.
On the bias for action front, one trick a previous company implemented that worked wonders was stating (in Slack, meeting, whatever): "I'm planning to do X, any strong objections?". The strong objection part generally dissuaded most lazy bike shedding, especially if paired with "do you really feel strongly about it". Of course if people do, then you have a discussion, but most of the time it's a thumbs up and off you go.
I wrote a book about GitHub a while back. I interviewed a bunch of GitHub engineers. One comment was really fascinating: at least some teams required the engineer to write up an empty PR (with zero code) about how they were going to do things before writing any code. The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration? But, that's really smart collaboration and not in progress collaboration.
Getting things done is an important metric.
Getting the right things done is much harder to measure and I think the hive mind helps a lot with this.
If you have good writing skills and can communicate well about what you are working on, feedback and collaboration can be fast and effective. And, is the only barrier to tunnel vision. You cannot be a good engineer without some kind of self absorbed focus on a problem, and you can easily lose sight of the forest in the trees when doing that. Without collaboration it is unlikely you can pull yourself at the optimal time.
"Perseverance bias" or "sunk cost fallacy" and "cognitive entrenchment" are not mentioned in the article, but they should have been.
We've lost focus on the importance of good writing skills and good communication skills. AI is going to make that so much worse. If you can effectively communicate in progress tasks, many of the collaboration problems described here can be avoided.
I worked on a team that did something like that for important stuff. (We didn't bother for the relatively routine or uncontroversial changes.) Although in our case we did it in a team meeting rather than asynchronously.
It really was horrendously valuable. Many, many times someone would save a their teammate an ungodly amount of time by pointing out an easier way to do something. It was a big complex system so naturally none of us could be expected to know every nook and cranny.
> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?
That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.
scrum planning doesnt usually get too nitty gritty on implementation details in my experience if you dont want the meeting to last 4 hours.
"Unfortunately for me, not all collaboration can be rooted out, and even I will admit that some collaboration is useful. Ian and Andy edited this newsletter after all."
So "good" collaboration does work. It is just that the post is talking about things that are not really true collaboration and those should be avoided. Title is click bait but posthog is famous for these.
But the click bait was conceived and written super fast by a daring driver!
Framing obvious/old ideas in a novel way can be helpful. "Collaboration" is a meme that makes it easy to view all collaboration-shaped exchanges as helpful and the opposite as harmful. A memorable counter-narrative can help people think more critically when faced with an applicable situation.
The problem is design by committee.
This is simply an awful thought piece and is wrongheaded.
The problem is not collaboration nor feedback. It is the lack of a decider. Deciding by committee is a bad way to run as an org grows. Collaboration is still key.
One person needs to be the person who decides. Decides what? That is the trick. The further down you push decision making, the faster things go. But someone is the decider, not a group.
Yes, exactly. In many cases you don't exactly need to involve the whole group but without a decider things stall out. And suddenly getting a decision about something looks like "collaboration", and gets struck down by the great confusion which is this authors take. It's a lack of decision making, simply put.
Articles like this are quite poisonous, because they take language and mutate it for purposes that aren't quite sincere, and then next thing you know something necessary and good is worthless.
If I don’t like my coworkers, I’m out. I like people who give a shit about the work I do (a.k.a “collaboration”). “Whatever, you own it” is just lazy for “I can’t be bothered to understand what you are working on”.
The problem is not the collaboration, it’s the ineffective collaboration. Maybe the author should fix that instead of pitching magic anti-collaboration click-bait pills.
Also, the problems you solve must be pretty straightforward and unambiguous (or you have a small codebase) if you have the luxury of being able to just make a pull request for it.
It's obviously written in a "hot take" fashion, to be deliberately provocative. Taking it literally would be foolish but there is certainly some degree of truth in there.
Any meeting with more than 3-4 people (and maybe even less) is probably a waste of time.
Creating a PR doesn't mean everyone just accepts whatever change you've made. But it certainly gives something unambiguous and tangible for people to form their objections around. Rather than objecting to some misinterpretation of the idea in their own head.
Taking the article's analogy of the "collaboration while driving", the F1 sport is quite insanely collaborative. For example, the drivers literally do have someone in their ear by radio being their coach and spotter for the entire trip. I've never heard of the equivalent in software. Does anyone know of anything like this?
Pair programming.
That was too easy.
Github Copilot
This is like playing both sides of the board in chess and claiming you had an opponent.
I feel like collaboration can work great with a group of exactly two people. It's not terribly hard for two people to partition work and actively help each other. With two people working on a project, both people can realistically understand most of the codebase, and can competently review each other's pull requests.
I feel collaboration suffers from combinatorial complexity though, and I feel any number bigger than two ends up doing more harm than good. Once you have more than two people, the codebase starts becoming more segmented, it becomes really difficult to agree on decisions, and the project becomes a lot harder than it needs to be.
If I ever get into management, I think I will try and keep this in mind and try and design projects around two-people teams.
If each person can eat half a pizza, you've reinvented the Amazon approach: https://martinfowler.com/bliki/TwoPizzaTeam.html
“If you want to go fast, go alone; if you want to go far, go together”
I've often noticed that this is a favourite phrase of those whose preferred motion is narrating other people's work rather than doing it themselves. Teams do go further together. But only when everyone is rowing.
> But only when everyone is rowing.
Only if everyone is toward the same direction.
Not when one tries to redesign a new boat and the other person tries to row forward.
The popular "Thinking from the first principle" often leads to redesign a new boat. This is where it gets problematic.
In the original article the author says "ultimately leads us to ship less." as one of the drawbacks to collaboration. Says a lot really, if quantity of features shipped is a priority. Great way to build a feature factory, everyone shipping without feedback and having others question what you are doing.
This sometimes leads to valuable insights, but always slows the driver down.
In cases where the insight is genuinely useful that's better than going fast mostly because you were probably going fast in the wrong direction. Ideally you would optimise collaboration to increase the likelihood of valuable feedback (because that saves more time and money) rather than optimizing for speed.
That said, I've lost track of the number of meetings I've been in so that someone can cover their ass by making something a 'collaborative decision' instead of taking responsibility, so I can totally see where the author is coming from.
Elon Elias Musk saw right through this as he silently stared at each and every one of Twitter's dream-team that was expecting the ride to go on. He saw right through the cracks, the Staceys, the Mikes. He had the final tweet and blew most of the crew. He would agree with you Charles, he would agree to the point of saving screenshots of your website so you can collaborate with his memes.
One reason for collaboration is to raise the bus factor.
For small to medium-sized applications, it's not hard to get a single good developer to crank out feature after feature... but they're the only one that understands any of it. Then that single developer is hit by the proverbial bus (or Corona, or retires, or resigns, or whatever...) and you have important software without any maintainer.
That might be OK for some startups where the expectation is that the code will be thrown away and replaced by something better pretty quickly, but for slower organizations, that's often a nightmare scenario.
Collaboration slows things down but going fast at all cost leads to tech fragmentation, tech debt, and product debt.
fwiw I'm not in the camp of "we must have everything done in one consistent way" but there are places, for example a public API, where having 4 different names for the same concept, 3 different response format/url path styles, etc. starts to look really sloppy.
In my company we have the best of both worlds - things are slow as hell and there's shitload of tech debt. This is direct result of "collaboration" aka "nobody actually owns anything". I put forward a proposal to standardize various things across our software, and in response my manager called a meeting of 10 people. No proposal can survive a meeting of 10 people at once.
IMO the best way is to split your organization into units that nicely map with technological/business boundaries, and then give each unit the responsibility to own something tanglible. The problem is, if the organization is full of idiots, everyone tries to do the opposite, in order to diffuse the responsibility.
For relatively straightforward groups whose tasks are self explanatory and/or isolated, sure. For any kind of invention, however, I don't think this line of thought works. Alan Kay has said in a number of places that Xerox PARC (likely) couldn't have worked if they had been remote, nor could it have worked if they hadn't had the time they did to goof off, argue, share hypotheticals, etc. Developing a shared intuition and connection with others in your group is an immeasurable quality that doesn't get enough love.
In other words, if your organization is made up of a bunch of geese that lay golden eggs, by all means let them lay eggs, but don't ignore the fact that your organization could itself be a goose that lays golden eggs together.
I don't think this is good advice for building, programming, or operating spacecraft.
Edit to add detail: a spacecraft tends to have lot of subsystems that need to work together well, each requires a specialist lead, and there's a high return on investment for things like improving efficiency, sharing resources between subsystems, etc. leading to reduced power, data, and mass requirements. They tend to be bespoke and high value so it's critical that detail knowledge is spread among multiple people, edge cases are carefully considered, and lessons learned get learned by everybody. Collaboration is key in that kind of endeavour. If you're slapping together a CRUD app that can't hurt anyone, sure, go hog wild.
Or medical software. It's great advice for people building products which don't need to work correctly up into the high 9s.
>>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
Don't confuse this with "Don't test and don't do code reviews"
The line you quote is oddly one of my strongest arguments against Scrum.
Agile in general and Scrum in particular don’t want to declare things as done when they aren’t and if you haven’t yet given feedback, is it really Done? I don’t think it is.
With Scrum the pressure to put away the done thing and start something else is very high. The moment you start thinking about your next story, unless it’s very closely related to the previous, your ability to accept feedback becomes quickly curtailed.
This is half of the point of Continuous Integration. Fast feedback is often the only feedback that causes behavioral changes. Things that happened a while ago become abstract. Think about a conversation you’ve seen where someone describes how another person hurt their feelings yesterday, versus five years ago. The reactions are very different.
So if you enjoy talking, I suppose it “works” for you but if you hate having to give the same correction over and over, you need to make the person stop and go back until they learn how not to get stopped. Anything else loses the war.
I interpreted it as a joke, although I couldn't help but agree with a lot of what I think was meant to be ironic.
The problem I always run into is that the potential usefulness of collaboration breaks the insistence on predictability: nothing can be done unless it can be put to, and measured against, a date and a timeline. Collaboration is inherently unpredictable and worse, spreads blame around, so there's always this insistence that collaboration take place in very constrained ways (usually in the form of pointless meetings to review line items in a text document that doesn't end up being very useful).
I can see how the lack of collaboration lead to the posthog.com website design.
This is an example of why collaboration and feedback before launch are mostly useless.
Posthog is obviously successful. The design is good enough. But is it perfect? nah. would a better design make it more successful? highly doubt it.
If we were to take this feedback seriously, then we would've halted the launch and redesign the site. Now imagine having 10+ feedback like this. This would significantly delay the launch which would impact the success in a significant way.
I think it’s one of the best marketing websites for a SaaS I know, if not the best. Taste is clearly subjective
>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
This works for software dev. Would be more difficult in anything else, where you're not constantly updating an existing product on a weekly basis.
I'm just going to say it's not a coincidence that this individualistic stuff is full of driving metaphors.
Driving is one way to get around; it's not the only means of transportation.
> others feel obliged to give feedback because we have a culture of feedback.
See also "bikeshedding". Made famous by FreeBSD core developer Poul-Henning Kamp (phk). I see there is now a website dedicated to his email: https://www.bikeshed.org
In short: people give feedback and quibble because they can, to demonstrate that they're participating, that they can contribute.
Being aware of this habit and inhibiting it is something I teach to every new employee in my team. (If you know how to avoid it always, teach me)
You don't really need to explain bike shedding to HN.
This is a fun piece, though I definitely don't agree with it for the teams I have been in.
OP seems to assume that code is better than no code. Often this has not been true, and collaboration has either pointed out that a feature already existed, or was a bad idea. So in this metaphor, it stopped the driver...from driving to a bad place.
> A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.
Well, if the product roadmap doesn't hold up to scrutiny, it _should_ be reevaluated. Too often people commit to something, and then continue building it, despite the market realities having shifted underneath them. I see most teams not asking themselves often enough "should we still be doing what we're doing", than the opposite. The sunk cost fallacy is real.
It's called "thinking from the principle" for a reason.
You will have to re-invent the whole product from the start...
> Imagine you are driving a car.
Rally races sometimes have two people, a navigator and a driver. The dynamic between them is absolutely fascinating. I recommend watching some videos because, before I saw it, I would not have imagined that driving a car like that would have been possible much less effective.
> I disagree on some of that, but it's your call.
This sucks. I can't believe they used this as an example to follow. "I think it's bad, but I'm not going to tell you why, I'm just going to say that and then tell you it's on you".
There's no one size fits all - what they're saying would absolutely fail at the company I'm currently at, but sounds like it works for them. The key thing is to have a process that works well for the people who are there, and hire people who work well under those conditions. The people who do well at our company would not do well at their company, and vice versa. I don't like how this article makes a claim about what works well for them is actually a universal truth. It really depends on the people there.
Reminds me of Casey Muratori‘s talk on Conway‘s Law: „I always know what I am thinking…“
https://youtu.be/5IUj1EZwpJY?si=b7rG7_vemkiOL8Bp
Everyone reading this article: Don't fall for it.
There're scientific evidence that collaboration > individualism. Please, just search online about it. If it wasn't the case, do you really think every company in the world would just work in collaboration without any particular reason?
https://atlas.northwestern.edu/wp-content/uploads/2017/03/De... https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/... https://journals.sagepub.com/doi/10.1518/001872008X375009
I suppose if your primary goal is to write code and ship, you might like this advice.
Some of us like quality products. Maybe I am just old fashioned.
I'm a little disappointed at the amount of me tooism in this thread. I think a lot of people here have maybe had really bad collaborative experiences. Maybe that's the default? most orgs are going to be bad at most things (tm).
I can't help but think about this paper I ran across over a decade ago, that found a very high correlation between team diversity and paper citations.
https://arxiv.org/abs/1803.02282
This one always stuck with me, partially because of personal biases, but also because it just seems so powerful to have access to different perspectives when trying to build something. I know from personal experience, that when someone on my team has something unusual about them, when we build a thing with them in mind, the final product is just better. It might be related to the old advice of making sure that everyone's computer is different to make it more likely to run into bugs. Or make sure the devs don't have the fastest computers so they notice performance issues. But I also see it a lot in gaming too. If you tell me a game has color blind settings, that immediately gives me a big hint as to the quality of the rest of the game.
So this begs the question to me. What is it about building with someone in mind that is different than the collaboration that the author is talking about? Like, we expect committees to produce spheres. And we expect bike shedding to derail meetings. But what is different? is it agency? is it a single vision for the design? There is definitely something to be said for having one person who really understands the problem being the one to arbitrate all decisions about the thing. Is it how criticism is offered, or maybe whether a criticism can be ignored without social backlash? Is collaboration really that different than customer feedback which is generally seen as healthy for a product?
You can collaborate with smart and driven people. For the rest, you can "collaborate", which means doing it yourself and sharing the credit.
I would argue the opposite. If your collaboration sucks IMHO you haven’t done enough. It’s a skill. Imagine you’re playing a team sport and you recommended people play together less to win more games. Now look up Globetrotters vs Lakers.
I think the sports analogy would be passing the ball back and forth in front of the goal instead of shooting. Nearly every time, an athlete with the ball in front of an open goal will take the shot themselves instead of passing. Even in a 2v1 situation, passing is a huge risk and taking the shot has a high likelihood of scoring, so you only want to pass if the defender is leaving your teammate open (usually they split the difference, so it's complicated). Too many passes in a 2v1 guarantees that more defenders will show up and you lose your advantage.
Programming isn't a sport.
I didn't say it was.
it's funny because the facile sportsball analogy actually fails horribly here. "playing together more" is the absolute last thing that the undifferentiated mass of hundreds of people hitting the like button on a random nonsensical comment need to do more of. the only situation where collaboration of this sort is productive is when you cannot reasonably expect any other participants to have some sort of proprietary knowledge over their domain. think contestants on Survivor trying to put a puzzle together faster than the other team to get an immunity idol, not "i'm gonna mansplain Calculus to Terence Tao".
and man i wish i could go back in time to when i merely thought the "Globetrotters vs Lakers" thing was just a ham-fisted phrasing some sentiment along the lines of "the Lakers are better than the Globetrotters"...
but, unfortunately, i "took one for the team" (read: "collaborated with the team"), and am now dumbstruck as to what could possibly have been meant by this metaphor. for those of you who have yet on this fine day to regret the dual, magical gifts of sight and literacy: apparently the Globetrotters and Lakers played an exhibition match of some sort in 1948. the Globetrotters won 61-59. and it was apparently some sort of watershed moment in America's collective realization that Black people are actually also good at basketball. i wish this was merely my being grouchy, glib, and reductive. but just read the Wikipedia article: that is literally what happened and what it meant. in historical context. that, and nothing more, is the object lesson so signified.
so, now that i have made peace with my dual inabilities to magically unread and unlearn, pray tell: who are the metaphorical Black athletes being discriminated against, metaphorically, in this... metaphor? is the implication that Tammy from HR or Chad the BizDev Bro are better designers than Klaus from the Bauhaus? is it that the Lakers "played together less" than the Globetrotters? surely it can't be that there was a giant societal misapprehension (read: racism) that caused people to systematically misevaluate talent and, as sports experts as you say, pass the wrong people the ball? if only the Lakers had collaborated more, they could have overcome their systematic racism that blinded them to the 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.
No so much about why collaboration sucks as and argument for how important direct ownership / responsibility is. Good post.
Gravitational Pull" is the solution!
Instead of the "Collaboration Sucks" approach, we need to apply Gravitational Pull. For every key project, the Driver defines three essential stakeholders (e.g., Tech Lead, Business Owner, Target User) who form the "Quantum Sync Circle."
Everyone else is noise. This prevents endless discussions and focuses accountability right where it belongs.
"Instead of the "Collaboration Sucks" approach, we need to apply Gravitational Pull. For every key project, the Driver defines three essential stakeholders (e.g., Tech Lead, Business Owner, Target User) who form the "Quantum Sync Circle." - this sentence had me so freaked out with all of its buzz words, but man I think I really strongly agree with it. I love the inclusion of target user!
If this takes off, I think you've coined a new term there with "Quantum Sync Circle."
The Conjoined Triangles of Success
It's quality isn't your main metric then ya, knock yourself out.
I’m shocked this title is coming from a PostHog employee but more shocked that is seems to be relating not his experiences but a shared one. But as I read I quickly noticed a problem.
Charles isn’t describing Collaboration.
He’s describing people being voluntold to seek validation from other people. That is politicking and blame diffusion and has fuck-all to do with collaboration.
Collaboration is a small number of people reaching a consensus on a thing, understanding how and why the decisions were made, and executing on those decisions. All of these things are necessities in a 24/7 operation. You need a bus number on everything and how are you going to get a bus number without collaboration? It can be done but it’s slow. Often painfully so.
I think the car analogy is great and also even shows that some degree of collaboration is great! IMO it's about the scale.
Like someone giving you directions while driving, IMO it's great to have input from 1 to 2 people on a PR, and also while planning a feature. For me this has helped me avoid some basic mistakes and helped me not to overlook some pitfalls early on. Same for reviews.
But the screenshot from a PR with ~10 people reviewing it is where it gets crazy, I've never seen that.
Personally I usually just don't add to discussions like that, seems pointless. IMO it's also about trusting your colleagues: probably they have already said all there is to say.
You guys need to work on harder problems.
For real. The only collaboration that is super fast is between yourself and Claude Code.
I love this, thank you posthog for being great
It helps to go to the classics.
...
Expected Benefits of Modular Programming
The benefits expected of modular programming are: (1) managerial--development time should be shortened because separate groups would work on each module with little need for communication: ...
On the criteria to be used in decomposing systems into modules, D. L. Parnas, 1972, https://dl.acm.org/doi/10.1145/361598.361623
Marketers ship code, salespeople answer technical questions without backup...
...and you dentist cuts you hair and your hairdresser pulls your teeth. Because everything is a trade what can and should be learned, except if it's related to writing and selling software.
To be fair, you did not say that marketers ship working and maintainable code, salespeople answer technical questions without backup the correct way. Therefore you might be right, thought.
Take a look at their codebase (posthog is open source) and then tell me again that collaboration sucks, because i feel like the lack of collab is why their codebase is in such terrible condition.
The dose makes the poison.
This feels silly. I think this is just "ask for forgiveness, not permission" but made more clickbaity.
It also borders on a kind of edgelord attitude that I've seen from people who I wish not to work with again.
damn. super cool that posthog is acknowledging the pains of growing even at their scale.
If you know how to get stuff done yourself, start your own company, get stuff done, and enjoy the profits (or losses, depending on how good you are). It's your risk and your reward.
If you are working for someone else, the unwritten rule #1 is that a single employee should not amass too much influence within the company to start dictating their own conditions. So, the management culture averages decisions across multiple people, to make sure the loss of one-two team players won't be noticed.
It can be extremely demotivating if you are smart and capable, but these are the rules of the game. Be nice, get paid, accumulate some savings, make connections with other smart people, learn the market, and eventually start your own game on your own rules. Until then, trying to stand out will get you labelled as a troublemaker, and will hamper your progress in the long run.
good advice, someone should have told me this years ago, when you start, you need to know that this is not your game, work, watch and learn. Don't even think about "this is wrong" "they should do this instead" "they have no idea" "I would do it much better"
My girlfriend enter a new job and she told me about some scenario related to IT, kind of asking for my input. At one point she told the IT guy, who was discussing through emails or chat, that they should hop on a call. I told her that the IT guy probably hated that, but she couldn't understand why.
I think speaking to people is a stressor, it's an activity that drains energy, like running or literally doing anything, but IT people can go for weeks without talking to people, so they have that muscle atrophied and even the slightest of real life interactions feels like excessive to them.
This article is just peak IT. Collaboration is normal man, you probably didn't invent a "it's your call" solution to the "problem" of collaborating in companies. I wish you the best of luck in building your social skills.
I'm not sure where you work in IT, but if I went weeks without talking to someone, I would be out of a job.
wow add Posthog to Places Id Never Work
"you asked someone what they thought of your approach? BAD! that's not our culture!"
I’ve used both approaches and I can’t disagree more. Writing code first might feel faster but it isn’t. It’s great for surface level issues but just muddies the waters for any consequential feature.
Measure(communicate) twice, cut(build) once.
IMO this is very dependent on the risk of cutting once, so to speak. I'd imagine that at PostHog, the idea is there's little risk of cutting many times - iterating - and more damage is done by the measuring taking far too long.
This is true but there is another cost. If you carelessly write you can end up with a system which is a mountain of bandaid fixes; an incoherent and unmaintainable mess.
This kills the product manager, though.
That's why it still persists.
We don't collaborate, we iterate. I'm the lead of my department, so I sst the initial direction of the new feature, discuss it with my team, assign it, and let someone build the basic functionality. Then I'll review it, and I will pick up the code and move things around, refine the UX, refine the code, and then maybe pass it back to the developer for more changes, until we arrive at something really good. It doesn't make anyone unhappy or slow us down, and we often don't know where we're going to end up when we start a new feature. Things are fluid, but we have a goal of making things easy to use. Iteration among the team members also ensures more of the team knows how the code works, and we often learn from each other. Maybe this is "collaboration" but we call it iteration.
This is so dumb, its how you end up with 37 versions of the same thing.
Praising people for saying "it's your call" and in the same article boasting about "extraordinarily high ownership" is simply laughable.
The two are literal polar opposite.
You seem to view them as opposites because you expect ownership to mean that all employees are motivated to have a sense of ownership over the whole process. There’s some benefit to that, sure.
The meaning the article is using is that there’s an owner, and they own the project without dilution. There’s not death by committee. One person or one team is given something to do, and they go do it without interference from the rest of the company. Whether what’s delivered at the end is fit for purpose is open to other people’s opinions and input. How it gets implemented and reaches delivery is the exclusive concern of one person or a very small group.
not at all. me, owner of a new feature: hey boss wanted to get your thoughts on this. Boss: "let's schedule a review for next week, and pull in x and y who are familiar with the space"
Vs Boss: "your call"