Live data from Hacker News

“Collaboration” is bullshit

joanwestenberg.com

151–160 of 193 posts

Re: “Collaboration” is bullshit

#151
This article really misses the point of Collaboration. In biology there is the concept of symbiogenesis (https://en.wikipedia.org/wiki/Symbiogenesis). We are writing and speaking on the web because of collaboration.

The point of collaboration is to put people together that when combined are greater than the sum of their parts. You take person A individually and they may to X, you take person B individually and they may do Y. But individually X and Y might not be that valuable, it's their combination and the glue that combines them that is valuable.

What the article misses is that yes, 20% do 80% of the work. However, you can't predict which 20% will do 80% of the work. Not only that but it's not always the same 20% that do 80% of the work for all tasks and projects.

Collaboration is the 'glue', that little bit of added information, that combines the work of individuals into truly something great.

The challenge is how do you combine the work of individuals and I can tell you what doesn't work, rigidly planning and executing.

Re: “Collaboration” is bullshit

#152

This is a frustrating (bullshit?) blog post because it starts out poorly, gets really good, and ends on a whimper. It has no advice to offer other than than "leave me alone, I'm doing things". High performing collaborative teams and teams-of-teams have the ownership culture that he is describing. But they also have a team level view of progress (kanban is one approach, and not a bad one, story backlogs are another, e…

It's almost like if you don't have dependencies and coupling, you really just end up with a toolbox with widgets that don't do anything special when put together.

Re: “Collaboration” is bullshit

#153
post #152

This is a frustrating (bullshit?) blog post because it starts out poorly, gets really good, and ends on a whimper. It has no advice to offer other than than "leave me alone, I'm doing things". High performing collaborative teams and teams-of-teams have the ownership culture that he is describing. But they also have a team level view of progress (kanban is one approach, and not a bad one, story backlogs are another, e…

It's almost like if you don't have dependencies and coupling, you really just end up with a toolbox with widgets that don't do anything special when put together.

You can build things with purpose with loose coupling but this requires deliberate organizational design and product architecture decisions...

Re: “Collaboration” is bullshit

#154

Earlier quoted context omitted.

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece…

It varies on company culture and business model. Your situation sounds like R&D shops and how they often manage things.

R&D usually is budget constrained at the company or division level (% of revenue) and you can only ask for it once a year. Next year's budget time determines if you get more or less. Time constraints come indirectly (proof of progress for budget expansion or more importantly declining revenue from existing products),

But the only way management knows how to hold R&D accountable to ship is with dates as a forcing function, and those dates are often invented or organized around industry events (conferences, press events, etc).

There are other ways to manage progress, dates are the most common lever. That can work but can be abused by bad management. I've usually preferred shops that say "it ships when it's ready", but they require special circumstances to maintain funding and measure progress. In general if what you build is more important than when it ships, "it ships when it's ready" is better than hitting a date with a dud. So long as there's value for the budget and a way to measure it.

Re: “Collaboration” is bullshit

#155

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper d…

> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get…

A startup I worked for twenty years ago used that approach: we shipped an update once a quarter, every quarter, no matter what. We'd begin with a week of planning, build as much of the plan as we could, then cut anything we hadn't finished and release whatever was left. Of course the trick was to build the high-priority items first.

I loved it and I think it was one of the more productive development methodologies I've ever seen. It made sense, it was honest, it required no heroics, and it improved our long-term design work by forcing us to break every grand plan down into a series of incremental deliverables.

Re: “Collaboration” is bullshit

#156

Earlier quoted context omitted.

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

The corollary is that it's only the budget that is tracked that anyone cares about. Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.

As someone who once spent two months reworking a system because a 4GB Oracle instance was okay, but 8GB was verboten, I agree.

Re: “Collaboration” is bullshit

#157
post #69

Earlier quoted context omitted.

What kind of incentives are possible in your average tech work environment? A raise? A bonus? Raises usually come with more responsibility. I'm not familiar with tech companies doing bonuses.

Starts with how you evaluate employees for bonuses and promotion. Do you evaluate people on the impact of what was delivered? How fast they delivered feature work? The quality level of what they delivered? How well they worked with others? The answers to basic questions like that already starts to shape behavior. If you pay zero attention to how people behave, and only look at impact of what was delivered you may pro…

From the article:

> You're part of a team, you're contributing, you're also (measurably) pulling less hard than you would if the rope were yours alone

There’s a perfectly rational reason for this. Success is collective, but failure is individual.

Rewards for the success accrue to the person who represents it to the right people (usually those with the shortest path to the organization root).

For all intents and purposes, the person who gives the presentation did the work.

Re: “Collaboration” is bullshit

#158
post #137

Read a super interesting paper by McEntire lately, “The Organizational Physics of Multi-Agent AI”. In short, he proved that even AI agents exhibit all the dysfunctions one would normally attribute to human shortcomings / politics / laziness etc. Either way, I think the point is strong: if the organization is bad, you end up doing mostly work about work which is exhausting. Small, effective teams with super high accou…

I feel a bit wacky even saying this, but I just started re-reading Team Topologies last week because it's starting to feel like the whole orchestration pattern only works reliably when roles and structure are clearly defined.

I love this insight, and it generalizes. Just swapping out humans with AIs won't just fix everything, because many of the biggest problems are structural or emergent.

I'm hopeful that we can use AI models to pressure test better options of social organization etc.

Re: “Collaboration” is bullshit

#159
post #140
post #44

Earlier quoted context omitted.

> A lot leaps from riflemen, who obviously didn’t want to die Yeah but you'd think not dying involves killing those who want to kill you, or at least shooting at them! Isn't it super interesting to learn that 80% of riflemen don't ever shoot?

In a gunfight, you usually have to expose yourself at least a little bit in order to aim and fire. And let's say that you know an enemy soldier is around some corner, unaware, and you can pop out and shoot them. If there is another soldier aiming at your position, unbeknownst to you, you are dead.

In WW2 most shooting was covering fire, not targeted shots. That means people where not aiming shots, but just firing in the general direction of the enemy. If the 80% would have done it, the positive would be the other 20% would have been much more effective with the only downside of increased ammo consumption.

Re: “Collaboration” is bullshit

#160

Earlier quoted context omitted.

That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece…

It varies on company culture and business model. Your situation sounds like R&D shops and how they often manage things. R&D usually is budget constrained at the company or division level (% of revenue) and you can only ask for it once a year. Next year's budget time determines if you get more or less. Time constraints come indirectly (proof of progress for budget expansion or more importantly declining revenue from e…

Hacker News discusses "deadlines" as one of many management strategies. How much depth is there really? Other industries use bonuses as a simple management strategy. The kinds of people writing blog posts like this do terribly boring work, which is the real problem.
Post reply on HN