4 ms·

That's a good summary, I agree with basically everything. I think a lot of it boils down to strong engineering, which is not getting mauled into submission by

That's a good summary, I agree with basically everything. I think a lot of it boils down to strong engineering, which is not getting mauled into submission by product / business. Strong engineering will naturally gravitate to optimizing long processes. The other big factor which has many consequences is the overall organization culture - are people encouraged to be helpful, reach out to other teams without organizing meetings in the calendar? Is there a blaming/finger pointing happening? Are many disputes largely about ego, dominance, politics? The "Meetings" section might be controversial, but I agree as well. There's just no getting away from lots of communication/alignment in large organizations, and synchronous/low latency communication should be encouraged. Yes, that means disruptions, but being on the same page/unblocking others is usually more important. The amount of lines of code produced is not the largest cause of productivity loss in the large organizations.

VBprogrammer 3y ago
> The "Meetings" section might be controversial I can't really say I found it all that controversial. If I wanted to be controversial I'd say that most recurring meetings and any meeting with more than 5 people are a waste of time. I quite often ask someone who messages me out of the blue with a problem to book time in my calendar (which is usually at least 50% free). Because having a specific time to look at something is usually much better than me either dropping what I'm doing to think about something else or forgetting about their message and getting chased by them 3 days later.
- The_Colonel 3y ago
  > Because having a specific time to look at something is usually much better than me either dropping what I'm doing to think about something else There's no hard and fast rule, but if you can help them out in 10 minutes, then it's much healthier for the culture/organization to unblock them immediately (within let's say 30 minutes) than ask them to organize a meeting.
- Silhouette 3y ago
  If I wanted to be controversial I'd say that most recurring meetings and any meeting with more than 5 people are a waste of time. You're probably right but it's sad that this is regarded as controversial rather than self-evident. Maybe any meeting with more than 5 people being a waste of time is a stretch and most again would have been a more defensible claim? But the spirit is right. Good meetings happen when there is a good reason to have a meeting. Recurring meetings are often symptoms of other management problems that have better solutions available.
Silhouette 3y ago
Yes, that means disruptions, but being on the same page/unblocking others is usually more important. The real problem is often that people are getting blocked so easily in the first place. I'm sure I've seen every excuse imaginable for why organisations need a constant stream of pings via Slack or Teams or whatever they use. There is usually some underlying claim that everyone should respond to those pings quickly and accept the endless random interruptions that cripple their individual productivity because it's somehow better for the team as a whole. But if you make the effort to plan things and coordinate properly to begin with and you allow your people to concentrate and get on with their work then sudden, completely blocking problems should be unusual and your processes can be chosen accordingly.
- The_Colonel 3y ago
  > But if you make the effort to plan things and coordinate properly to begin with That assumes something like this is even possible, won't be completely wrong immediately after the plan is finished, and won't take weeks / months to finish. This is what we used to do in waterfall - architects created a detailed specification which was obsolete / wrong / pipe dreams the moment they hit the Send/Publish button.
  - Silhouette 3y ago
    That's true, it does assume that. I have never seen a project where this common hypothetical actually became reality so until proven otherwise I'm OK with assuming that Bigfoot is a myth. I have however seen many projects where management did understand their product and their market well enough to plan strategy more than 24 hours in advance. Their developers could then be reasonably confident about what they'd be working on for a while and act accordingly. If your organisation is functional on this basic level then getting the right people together early to gather information and consider alternatives and sketch out a design is useful for the same reasons that getting peer review when the code is done is useful or that having more than one person writing tests or doing QA is useful. It's far more efficient to identify and correct problems early in software development. If you skip the up-front discussions and planning entirely then you miss several useful opportunities to do that. Typically in that scenario the problems are either identified and corrected during code review at the earliest or - worse - they are not identified and corrected at that stage either because the right people didn't have the right information to see the problem or because they did see it but it was judged too expensive to fix by then - and so the resulting bugs and tech debt make it through.

VBprogrammer 3y ago

> The "Meetings" section might be controversial I can't really say I found it all that controversial. If I wanted to be controversial I'd say that most recurring meetings and any meeting with more than 5 people are a waste of time. I quite often ask someone who messages me out of the blue with a problem to book time in my calendar (which is usually at least 50% free). Because having a specific time to look at something is usually much better than me either dropping what I'm doing to think about something else or forgetting about their message and getting chased by them 3 days later.

The_Colonel 3y ago
> Because having a specific time to look at something is usually much better than me either dropping what I'm doing to think about something else There's no hard and fast rule, but if you can help them out in 10 minutes, then it's much healthier for the culture/organization to unblock them immediately (within let's say 30 minutes) than ask them to organize a meeting.
Silhouette 3y ago
If I wanted to be controversial I'd say that most recurring meetings and any meeting with more than 5 people are a waste of time. You're probably right but it's sad that this is regarded as controversial rather than self-evident. Maybe any meeting with more than 5 people being a waste of time is a stretch and most again would have been a more defensible claim? But the spirit is right. Good meetings happen when there is a good reason to have a meeting. Recurring meetings are often symptoms of other management problems that have better solutions available.

Silhouette 3y ago

Yes, that means disruptions, but being on the same page/unblocking others is usually more important. The real problem is often that people are getting blocked so easily in the first place. I'm sure I've seen every excuse imaginable for why organisations need a constant stream of pings via Slack or Teams or whatever they use. There is usually some underlying claim that everyone should respond to those pings quickly and accept the endless random interruptions that cripple their individual productivity because it's somehow better for the team as a whole. But if you make the effort to plan things and coordinate properly to begin with and you allow your people to concentrate and get on with their work then sudden, completely blocking problems should be unusual and your processes can be chosen accordingly.

The_Colonel 3y ago
> But if you make the effort to plan things and coordinate properly to begin with That assumes something like this is even possible, won't be completely wrong immediately after the plan is finished, and won't take weeks / months to finish. This is what we used to do in waterfall - architects created a detailed specification which was obsolete / wrong / pipe dreams the moment they hit the Send/Publish button.
- Silhouette 3y ago
  That's true, it does assume that. I have never seen a project where this common hypothetical actually became reality so until proven otherwise I'm OK with assuming that Bigfoot is a myth. I have however seen many projects where management did understand their product and their market well enough to plan strategy more than 24 hours in advance. Their developers could then be reasonably confident about what they'd be working on for a while and act accordingly. If your organisation is functional on this basic level then getting the right people together early to gather information and consider alternatives and sketch out a design is useful for the same reasons that getting peer review when the code is done is useful or that having more than one person writing tests or doing QA is useful. It's far more efficient to identify and correct problems early in software development. If you skip the up-front discussions and planning entirely then you miss several useful opportunities to do that. Typically in that scenario the problems are either identified and corrected during code review at the earliest or - worse - they are not identified and corrected at that stage either because the right people didn't have the right information to see the problem or because they did see it but it was judged too expensive to fix by then - and so the resulting bugs and tech debt make it through.