Hacker News Reader

Comment by awjr | Hacker News Reader

"When it gets cancelled because a certain person is not there, you are doing the meeting for that person"

This rang true with my current team. It isn't that the meeting doesn't happen but it is extremely fast. No round robin, just a simple 'has anyone got any issues'. Nope, ok carry on. We still get high value from those discussions.

My personal observation is that when this senior person is there, they are using the stand-up as a project management meeting. This should really be 'taken offline' and this person should be working with team leads away from the stand-up.

Luckily I'm working closely with one of the team leads in an isolated area and I excuse myself from the meeting and let him talk on my behalf but I shouldn't be at that point where I'm trying to avoid them.

The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.

View on HN

The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.

It's not necessarily a loss of time though.

The mindset "any time spent doing things other than writing code is a waste" rarely produces great products - you need to talk about things. No one knows everything about a project once it gets to a even moderately large size. Working in isolation from the rest of your team means you're not influencing, or being influenced by, the knowledge and discoveries that other people are making as they work. That means you're very likely to be working with an out-of-date model of the problem you're trying to solve.

Clearly a meeting where nothing happens is a waste of time, but the solution to that problem shouldn't be "no more meetings", but "better meetings with real outcomes".

Unless those eight people work on very closely related problems, there is little value in having all of them in the same room talking for half an hour. Communication doesn't have to happen with the whole team if different parts of the team work on different parts of the software.

If their work is that independent then the fact they're all on the same team seems problematic.

It's entirely possible to be on the same team as someone and not need to know the details of what they are working on.

What do you mean by "details"? The level of detail is highly context dependent. I'd argue that if there isn't a level of detail that all members of the team agree they should be interested in, then either the team is not composed properly or there is a misconception about the level of detail that is appropriate.

It's problematic because current business organisation fads seem to mean that anybody doing hands on work has to be "on a team".

Recognising the existence of one-person teams might help a bit.

It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.

If the discussion can add more value than those costs, then go for it.

We did stand-ups at my previous employer and for some reason they happened early in the morning. That's my most productive time. I always thought we should move them to after lunch or maybe later in the day. In that office, productivity and energy definitely dropped as the day wore on and it seemed foolish to spend some of the best time in discussions.

I had the opposite problem, but it was a morning problem also. First thing in the morning, I am very foggy, and remember very little from yesterday. It is not until I've worked for an hour or two that everything comes back. Paged in from disk, so to speak.

So I often had to make things up on the spot to sound busy when I had no idea what happened yesterday at the crack of dawn. What a waste of energy.

That can be mitigated somewhat by having the stand up meeting first thing before people have started other tasks, but really that rarely works if people are interested in their work enough to get to the office early. You just have to take the hit, and readily accept that people will skip the meeting if they're deep in to something else.

The other time to hold it is just before lunchtime. This has the dual benefit of encouraging people to be brief (hunger is a powerful motivator ;-) and breaking at a time when people would have to break anyways. I also like holding it midday rather than the very start or end of the day because those times encourage staying late or coming in early to resolve an issue before standup. Lunchtime is also usually a time when everyone (apart from remote team members) is in the office no matter what schedule they keep.

>It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.

Sorry - same thing. When GP is talking about "loss of time", he's not referring to "Oh, I lost X minutes of my life I'll never get back!" He's talking about lost productivity, just as you are.

And if a simple 5-15 minute meeting once a day saps your productivity so much, then what the GP is saying does apply to you: That you feel your job is just to sit on the computer and do software development.

And if you can't organize your work around that 5-15 minute meeting, you have other problems. You never take breaks during the day? This is just another "break", except it has a prescribed time. Plan around it! This isn't a "surprise interrupt" that occurs while you are working. It's not an interrupt, any more than your sleep is, or eating lunch is. It's a predefined part of your job.

Sorry, I'm not even saying standups are good. I'm not an advocate for them. But this attitude is silly.

If you are not getting value from the standup, improve the standup! Don't complain about context switching.

Context switching isn't free, so you shouldn't pretend like it is. You mention lunch, but that's a facile comparison: humans need calories, and if a person is in a flow they can take lunch solo and continue the thought process.

We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.

>and if a person is in a flow they can take lunch solo and continue the thought process.

And my question is: If you know there is a scheduled meeting at a given time, why are you trying to get in flow around that time? Sorry, that's just poor planning.

>We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.

No one's disagreeing with you there. No one is saying you should randomly take up lots and lots of meetings.

But I'd be worried if a developer - whether a colleague or one under me - said that a 15 minute meeting at a predefined time once a day is significantly impacting his productivity. That's usually a sign of him trying to solve the wrong problem - or a sign that he is not thinking the problem through.

I wish I could find the quote, but there's a famous quote from a SW manager saying that it's often cheaper for him to pay people not to code than it is to let them code a lot. Someone who is coding all the time (unless it is boilerplate work) is creating a lot of technical debt. Unless it is a cutthroat market, he should not be doing that.

If I were a manager, I would rather my SW developers:

1. Spend more time talking to the customer and refining their requirements (yes, I advocate more meetings than most people like) (part of solving the "right" problem).

2. Spend more time improving the infrastructure (automated builds, whatever).

3. Spend more time writing documentation.

I could keep adding to the list. If they are spending the majority of their time in "flow" mode, they are doing too little of the above, and in the long run, creating headaches for many people.

Frankly, writing code is a last resort. Almost all our code is to solve a problem, and a lot of code is an attempt to solve a social problem using technology. If my developer can solve the original problem without writing code, he deserves a bonus - not the guy who came up with a fantastic algorithm to solve it.

I'll grant there are niche roles where it is really beneficial to be in flow mode most of the day. But over 90% of the folks who want to be in that mode are not occupying one of those niche roles.

If you see flow as being time when someone is hammering away on a keyboard you completely misunderstand the concept. Flow is how developers avoid writing code.

" That means you're very likely to be working with an out-of-date model of the problem you're trying to solve."

This is highly context sensitive. The models I deal with when I develop software change very seldom, if ever.

Different projects have different cadences for inputs and outputs, even within this wide domain we call "software engineering".

> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.

But the whole point of a stand-up meeting is to keep it short. If you're talking for more than 5 minutes, the scrum leader or whatever you're calling them needs to reign it in. If you hit 10 minutes you're doing it wrong.

Stand-up meetings are dispatch, not processing.

Half an hour meeting with 8 developers takes 4 developer hours. This is often enough to give manager a pause.

That's a drop in the ocean compared to hours wasted dicking around on Twitter, Facebook, Hacker News, Reddit, etc

SSSHHHHhhhhhhh !!!!!

But I'm more productive if I take a 15 minute break every hour, or so some article said so.

I agree with 'bad_user' here, to some extent. That is enough to give a manager a pause, but not to immediately dismiss it as a bad idea.

Most professionals will agree that it's unrealistic to believe that developer-typing-code-time has 100% efficiency. The time spent 'decompressing', which can sometimes manifest itself as spending time reading/doing unrelated stuff, does sometimes produce a solution faster than just banging away coding.

Management work is different from coding in that everything is hard and noisy to measure, so to some extent heuristics are relied upon, simply because it's the state of the art in this area.

So, even if half an hour meeting with 8 developers takes 4 developer-hours (which is a rather large number), it does not mean those hours are wasted. If one of those meetings a day stops someone spending one week chasing a dead-end known to others at least once in a while, on average the team moves faster, not slower.

BTW, I actually agree that 8 developers is too much, and that half an hour is too long for a daily. Just going off a tangent here.

The point is not that it is actually bad. Even 8 developers for half an hour could be justified.

The point is that it should give a manager sufficient pause to actually think through whether or not that cost is justified by what that meeting provides.

Surprisingly few teams account for the cost of the way they spend their time, and one outcome is that it's very easy for time sinks like meetings to go unchallenged because people don't think about how the costs multiply with the number of people involved. It's "only 30 minutes".

Costs which would require budget approval if it was scheduled as a project suddenly become ok because no single person spends much time on it per meeting and the time spent never gets recorded and reported on anywhere.

What I started doing after a couple of years of managing teams was to ask for average salaries per work function for my team, which has consistently surprised people when I ask (that this is surprising surprised and shocked me), and then send a weekly report to my boss - whether they wanted it or not - enumerating costs broken down by task.

Several times I've had managers that were confused why I'd send them this, or even insist it was a waste of time at first. Never once have I had a boss ask for this kind of breakdown themselves.

Then they'd see the result, and inevitably I'd get questions about how it could be right that e.g. (to take a number out of thin air) $5k worth of developer time every week was spent on meetings.

Or why that "tiny little change" that someone insisted on adding without proper scoping because it was so minor ended up costing $20k.

Pretty quickly those reports they initially didn't care about became mandatory, and it to some degree changed how people thought about resource allocation.

It doesn't need to be precise tracking either - you need to get the costs to about the right magnitude, and treat them accordingly depending on how you collect the data.

> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.

What i see here is a team that let it happen.

A 'scum master' (or whoever) that oversaw the conversation and carried on with it. Developers (or team members) who talked for that long, and other people who _let_ it go on for that long and didn't put their foot down.

Man, where I work if a standup started going for half that time, people would just start walking away from it.

When the person who calls the meeting is sufficiently senior, walking away isn't always an option, unless you're prepared to also walk away from the job.

Reply on news.ycombinator.com