Live data from Hacker News

“Collaboration” is bullshit

joanwestenberg.com

141–150 of 193 posts

Re: “Collaboration” is bullshit

#141
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.

Re: “Collaboration” is bullshit

#142

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 natural extension to Spolsky’s quote is: Unless someone else is paying for the jeans.

I think the smaller the organization, the more likely that a software projects has real stakeholders. In bigger, more mature organizations, the experienced players have arranged their affairs so that their career progress doesn’t depend on delivery of software: Late, early, or ever. For instance I work on the “hardware” side of technology development, and I tailor my annual performance review goals so that a deliverable is satisfied when I can demo it with code that I’ve written myself.

Re: “Collaboration” is bullshit

#143
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.

Hours of PTO?

Sure, you did a great job on that last project, we've added 8 hours of PTO for you. No, you can't take it any time soon, we're far too busy for you to take any time off

Re: “Collaboration” is bullshit

#144
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…

> but don't look "reproducible" or "repeatable".

IMO, "ish". You can reliably and repeatedly produce good teams _if_ you reliably and repeatedly invest in your people.

IMO, what's really happening is that small, effective teams aren't _fungible_ - you can't just swap people around without breaking the magic in a team, and you can't just move a team around an organization without similarly breaking the magic (although the latter _is_ way more possible).

IMO, it's sort of an organizational version of "context switching". It takes time for a team to get up to gel and get up to speed. If you're swapping out team members, you break that cohesion. If you move around teams, you (somewhat) reset that "getting ramped up" process.

Re: “Collaboration” is bullshit

#145

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.

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 i…

I feel like everyone in this reply chain is looking at this from a different angle of Fast, Good, Cheap. Pick two.

Re: “Collaboration” is bullshit

#146
post #98

Earlier quoted context omitted.

Do you mean standups as part of Scrum? Scrum dictates several other meetings.

I will allow one more meeting to start a new sprint and end the previous one. Everyone should have prepared ahead of time to report on all their sprint items and whether they were completed, if not why not, and to present the work they will be doing in the next sprint. If the Scrum Master or whatever their title schedules any other repeating process meetings, fire them.

But what about that meeting that starts with "how do you feel today?" and "if you were a car, what car would you be? And why?".

Re: “Collaboration” is bullshit

#147

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.

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 of hardware, we just requested it and it materialized. Often I didn't even know the per-customer unit price of the software. The only constraint that ever made it down through the huge tree of managers was the due date. Someone five managers above me was probably sweating the budget but to us low level developers, budget was never even a concept.

Re: “Collaboration” is bullshit

#148
post #2

Strong words. I wonder if the author has PTSD from poorly managed teams and has never had the fortune to work in a high performance well managed collaborative environment. I agree these are rare compared to the other kind, but they exist. Groups of people can produce more than lone wolves. One person didn't build the pyramids, the Linux kernel, or Amazon Web services. Even when responsibility for a top level domain r…

Yeah, the sheer joy I've gotten from being part of a few collaborative teams in my career was amazing. It was like we all got smarter by working together.

Especially fun when you all have a good time being with each other and still have a super high performance bar.

I’ve come to think those magic teams where the chemistry is just right are rare in a career.

I’ve been a part of two out of my dozen or so teams.

Re: “Collaboration” is bullshit

#150

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…

>trying to get visibility They could review PRs and commits and specs to get visibility and reduce comms overhead, if they had the skills and time . The non-technical manager also takes great conveniences in making technical people spend their time translating things. But no one ever asks the manager to learn new skills as much as they make developers do it.

This is a really interesting point that too often goes unexamined.

I don’t know how to design and integrate systems and products, and write code, because I was born that way. I had to learn.

Likewise, later on, I had to learn project management, and product management, and the language of business so I could communicate effectively with those lacking a background in technology. Again, wasn’t born that way: had to learn.

But in a quarter of a century, the number of people on the commercial side who’ve bothered to learn enough about the technology side to have an informed conversation? Very few. Probably count them on one hand (the naive way: not using binary).

And bear in mind we’re talking about businesses that were heavily if not totally reliant on technology and the delivery of technology solutions for their continued existence.

You’d think a few more of these people would want to take a bit more responsibility for those outcomes, and maybe be a bit less disruptive to productivity, given their livelihoods have often depended on the success of said outcomes.

Like I say: interesting, isn’t it?

Post reply on HN