[adenverd]

Engineering manager here. I think a lot of people miss the point of standup, or abuse it to somehow micromanage engineers.

Standup is for the team, not the manager or PM. It serves multiple functions, but the most important is the last bit: "are you blocked by something?". Most of the time, someone else on the team knows how to unblock you. Other times, your manager is better positioned to get you what you need than you are. Most of us don't care when you work, or how much progress you made today, or whatever. Our job is to keep the ball rolling, not manage your time.

The status update portion exists so that your manager doesn't randomize you in the middle of the day asking about that thing you're working on. Not because s/he thinks you're slacking, but because your work ties into a bunch of other work that's going on, and it's the manager's job to coordinate. While you may be more effective working as an information silo, your team and org are hindered by it.

[kelnos]

> the most important is the last bit: "are you blocked by something?"

If you've waited until the next standup to raise a blocker, you've potentially wasted as much as a day of your time.

If I have a blocker that I need unblocked to get my work done, I'll immediately get in touch with the person or team that can help unblock me. If I don't know who that is, or need help coordinating, I'll go to my manager, again, immediately.

> The status update portion exists so that your manager doesn't randomize you in the middle of the day asking about that thing you're working on.

That's what the issue tracker / scrum board / kanban board / whatever you use is for. Certainly some people and teams are better and worse about keeping it up to date, but a solid incentive of "if you keep this up to date we won't have to do standups" will motivate most people. As much as I hate Jira, if you eliminate a meeting from my day that I consider a waste of time, in exchange for keeping it updated, I will definitely keep it updated.

For special cases, the manager can asynchronously ask their report on Slack (or whatever) what they're up to, and the report can answer when they're at a natural break point.

This whole "we all need to be face to face in the same place at the same time" nonsense needs to go. People are remote, people are in different time zones, and they still need to be able to participate naturally and asynchronously.

[hinkley]

Yes, and.

If you figured that out yesterday then yes, you should absolutely go get help immediately.

Mentioning blockers in standup is about admitting you need help. Lots of developers have trouble figuring out when they're wrapped around the axle.

And it can be a little passive aggressive, but it's also a chance to point out that you've been asking for help and getting nothing. Basically you're warning the master/manager that your story is gonna slip if they don't start managing.

[badtuple]

> Basically you're warning the master/manager that your story is gonna slip if they don't start managing.

This. But it doesn't have to be accusatory like that. It's a way to have opportunity for feedback without having to be pressed for feedback.

The best manager I ever had was great because he totally trusted his people. Standups were a non-intrusive way to keep the overall pulse and make himself available if he was needed...that way he didn't need to vulture around to make sure he could insert himself if needed.

I'll take planned and well used 5 minutes of direct management over compulsive and nervous micromanaging anyday.

[kelnos]

You don't need standup to have a quick private chat with your manager to tell them you've been trying to get help on something for a while but no one is giving you the time of day. Again: communication is a part of any job. If you aren't communicating, and need a daily meeting to force you to do so, you are not doing your job and need better training.

[neves]

It isn't so simple. We are developers, we are used to solve problems on our own. A lot of times I spend a lot of time solving a problem that a coworker already knows. And I don't know that he already knows.

[machinelearning]

IME standups are not even effective in unblocking most people.

Why would someone want to admit they're blocked by something in front of everyone? Someone else will inevitably proclaim that they have the solution, however simple it may be, and make the asker look stupid while elevating themselves.

Most people know who to ask to be unblocked or can ask their manager.

1:1s are the time to sync with regards to status on projects not in the middle of the day.

Weekly roundtable meetings are the time to sync up with the rest of the team and learn what everyone is working on.

The only purpose of standups is to slavedrive people into "productivity", which inevitably ends up with them thinking of how to hyperbolize whatever they're working on minutes before standup begins. Its useless.

[vvanders]

I really hope you aren't using 1:1s as status meetings, that's the worst possible use of your time[1].

As a developer I've found stand-ups to be useful to know what's going on within the team and if feature A with collide with feature B.

[1] https://randsinrepose.com/archives/the-update-the-vent-and-t...

[machinelearning]

I disagree with your reading of the article. It does not say that providing status updates in 1:1s are the "worst possible use of time" anywhere.

Quoted from the article: "The point of this discussion is not to solve my Disaster, the point is that we’re going to have a conversation where one of us is going to learn something more than just project status."

Status updates are a conducive part of 1:1s and its the perfect time to get unblocked as the quote above duly points out.

As for learning about whether "feature A will collide with feature B", weekly/biweekly roundtables are the perfect time to learn about such things. The weekly cadence allows people to find time to collaborate on the possible overlap.

Lastly, I don't think the article is even that good. It seems to make up for its lack of interesting-ness by feigning conviction and edginess. The central point of the article is highly unusual in that it lauds novelty over pragmatism.

A 1:1 should be an environment where all of what the article talks about CAN take place. But that doesn't mean it SHOULD during every meeting.

[nitely]

Does your team communicate outside of the stand-up?

I usually know what everyone is working on (because of ticket assignments, code reviews, some occasional side meeting, etc), as I usually work with teams of 5 (or less) people.

[philipov]

yeah, for a lot of people, being blocked isn't a bug, it's a feature.

[mnm1]

> Standup is for the team, not the manager or PM.

Nope. Never once in my career have I been at a standup that was useful to me (a contributing or leading member of the team) and that wasn't simply for the manager. Your second paragraph also contradicts the first. Is it for the manager or not? Cause it sure as hell is not for the team members who are bored out of their minds listening to the other people on their team speak about their work that 99.9% of the time is completely irrelevant to one's own. This is the reality form the IC side. Maybe managers should wise up to it and stop wasting our time.

[machinelearning]

Standups are an extreme lack of parsimony. IMO, weekly 1:1s and biweekly roundtable meetings are the right quanta to compress work into so that its relevant to the respective audiences. Most people learn to bullshit and zone out during standups. Daily standups don't make sense in anything but a rare and specific tight deadline.

[nemothekid]

>It serves multiple functions, but the most important is the last bit: "are you blocked by something?". Most of the time, someone else on the team knows how to unblock you

To preface, I'm assuming you are talking about daily standups. How often do you see this actually working for you? In most cases, if someone is blocked, then they would communicate that, either to a manager or a coworker. If someone is blocked for days at a time and doesn't communicate anything, thats a problem in and of itself.

I'd like to get more value from them, but most times the devolve into "status updates" and then all engineers end up blocked by the standup.

[mobjack]

Blockers are not always obvious.

People don't always realize that their tasks is blocking someone else.

Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.

Spending 10 minutes every day resolving the communication and prioritization mismatches early helps deliver software faster.

With just weekly meetings, these issues could go unresolved for days.

[nitely]

This assumes people don't communicate when they get blocked, but wait 24hs to announce it in a meeting.

[ansible]

Yes, exactly. A lot of people don't do a good job communicating this sort of thing. It helps to have someone else ask you what's blocking your progress.

[kelnos]

I mean, c'mon. We're not children. We're professional developers. If anyone I worked with waited even a day to raise a blocker on an urgent task, I'd think much less of their abilities.

[ansible]

I don't disagree.

But sometimes you have to do what you have to do to keep the organization moving forward.

[nitely]

Sure, adding meetings that affect the whole team instead of addressing someone's lack of communication is the way to go.

[em-bee]

that meeting is supposed to only take 5 minutes, and it is only to discover the issue, not to address it. addressing the issue happens after the meeting with only the people who are actually involved.

[kelnos]

> Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.

Not in my experience. Most developers I work with will raise issues in Slack as they come up. That's part of what being an owner of your tasks is about: communicating issues early and often.

[mobjack]

Senior developers can work like that, but junior engineers need more managing.

[kelnos]

In this case I think it's the opposite: most junior developers I know are much quick (sometimes a little too quick) to ask for help when they're stuck, while a senior developer's ego might get in the way of raising a flag.

[crsv]

The comments in relation to the view of process and management from the general HN audience makes me feel for the challenges of being an effective engineering manager.

[kelnos]

Perhaps you should also feel for the engineers, who constantly have to put up with managers who don't understand what motivates them, and yet has power over them with regard to firing, compensation, work assignments, etc.

My most effective managers have mostly left me alone, and have genuinely interacted me to learn what motivates me and helps me get my work done most effectively, and then has put me in the best position possible for me to be successful. An effective manager needs to do that, individually, with each member of their team.