Live data from Hacker News

“Collaboration” is bullshit

joanwestenberg.com

121–130 of 193 posts

Re: “Collaboration” is bullshit

#121
> The average knowledge worker maintains accounts across system after system, switching between applications hundreds of times per day. And they produce, in aggregate, a staggering amount of coordinated and collaborative activity that never actually becomes anything resembling ~output.

The problem with this is conflating *output* for *impact*. A team of lone wolves writing 1k LOC by the hour is good output but not necessarily good impact.

A team with higher coordination overhead and "structural support" will probably have lower output, but if it focuses on significantly higher leverage activities might just have a better impact. The key question is whether that impact is visible and understood (often not) and lots of businesses are bad at understanding leverage.

I see this lone wolf BS from lots of founder types who mistake their own grind for real performance, often missing their own blind spots. I don't disagree that the 80-20% rule comes up and that some people have an outsized contribution overall compared to others, but to say that collaboration is dead as a result is throwing the baby out with the bath water.

Re: “Collaboration” is bullshit

#122

Earlier quoted context omitted.

I would be pleased with the standup if it eliminated other meetings, but that has definitely not been my experience.

there should be only 3 regular meetings in an agile engineering team - weekly iteration planning (1-2 hours max) - daily standup (15 mins max) - weekly demo & retro (1-2 hours max) literally everything else is work off the kanban board or backlog. in my teams everyone was told to decline all meetings unless it explicitly led to the completion of a weekly planned story/task. this way all meetings for the team have a c…

Is that three kinds of regular meetings? Because I count 8 meetings (and four kinds, as I don't think I've ever had demo and retro combined due to different groups of people being in both).

Re: “Collaboration” is bullshit

#123
post #46

This article is so true. "Collaboration" is how nothing ever gets done; we have this expression: "designed by committee"; we should also have "made by collaboration". What's depressing is that it's like Fred Books' book never happened: most managers think the way to solve IT problems is just to trow more people / more money at it until it gets solved; and they're all surprised when it doesn't work, but try again the…

Lets compare two projects that are collaborations:

Linux and Wayland.

Both are collaborative efforts, one has fairly effective and tyrannical leadership with the best interests of the community in mind. The other is lead by committee with competing interests and goals where they all have veto power.

Those same collaborators are reflected in the distro situation... Here is a group that also has some rather tyrannical leadership but they have dependencies (see the software they run) and some of those folks are sick of the distro's maintainers nonsense, and went to things like flat packs (see Bottles for an example).

> most managers think the way to solve IT problems is just to trow more people / more money

Leadership vs Management, a tale as old as time.

Re: “Collaboration” is bullshit

#124

Earlier quoted context omitted.

One of the features of my work, these days, is that I work alone. I worked in [pretty high-functioning] teams, for most of my career. Teams are how you do big stuff. I’m really good at what I do, but I’ve been forced to reduce my scope, working alone. I do much smaller projects, than our team used to do. But the killer in teams, is communication overhead, and much of that, is imposed by management, trying to get visi…

Communication overhead is a quadratic function. In teams with n people it takes n^2 time to keep everyone informed. That's why the most effective teams are wolf packs - roughly 6-10 highly performant members where communication overhead is still low enough that it barely matters, but have enough people to be way more productive than an individual. Obviously there's a minimum level of competence you need to have for t…

In my opinion, 4 is the best size. 7-10 is horrible - meetings and conversations use up so much time.

You want to break a team of 10 in half if you can. Not always easy. But if you can manage it, do it.

Re: “Collaboration” is bullshit

#125
Perhaps, but during the initial design stages it is the core job function to figure out how to improve the current workflow quality.

If folks don't clearly define the finish line, than a project will run out of budget eventually as scope creep turns it back into the same useless mess.

Proper restructuring usually means firing people that do not recognize they are in a business setting. The Big Brain fallacy is a common bias with people too blind to recognize what other professions bring to the table, and ultimately are unproductive in a large project.

Every manager should read Moneyball before building operational teams with HR, and avoid the trap of the costly Big Brain =3

"Moneyball: The Art of Winning an Unfair Game" (2003, Michael Lewis)

https://www.amazon.com/Moneyball-Art-Winning-Unfair-Game/dp/...

Re: “Collaboration” is bullshit

#126
post #67

Individual responsibility can just become a blame culture. I remember sitting near a team that worked like this - meetings with everyone trying to prove that some screw-up was actually due to someone else. In such scenarios nobody wants to stick their neck out at all, everyone hates everyone else. At a higher level the usual problem is with incentives being different from one team to another. If you want something do…

If ownership is clearly defined the person who screwed up should be clear.

You can own something but still be blocked by other people who should in theory enable you but have other priorities.

Another example: bugs that are not found by testers - whose fault is that - development or test?

Clarity is just another way in which one person or group try to lay blame.

Re: “Collaboration” is bullshit

#127

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…

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.

Re: “Collaboration” is bullshit

#128

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…

I love that LLMs are already copying humans when it comes to estimates. When asked for estimate they provide a very padded estimate of weeks. Then they proceed to implement the solution in 30”.

That's because LLMs don't actually think, they pattern-match. Since all the existing estimations out there are made assuming that a human is going to perform the task, the estimation that the LLM provides has the same inherent assumption. The LLM doesn't have a corpus of LLM-led estimations so it cannot take that into account.

Re: “Collaboration” is bullshit

#129

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…

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.

To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always inherent, or that this functionality actually is not really needed because the problem can be fixed in an operational way, or that the requirements have changed, or that it was just a nice-to-have... but money/time don't have this grey areas.

Re: “Collaboration” is bullshit

#130

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…

My technique was to always schedule the important (not difficult) things first.

That meant, that as the inevitable schedule crunch arrived, the things that were tossed in the skip were not important.

I call it "Front of the Box/Back of the Box." I basically got the idea from The Simplicity Shift[0].

[0] https://jenson.org/The-Simplicity-Shift.pdf

Post reply on HN