Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

    > everyone meeting

This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup)

I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't trust their teams because they need to have daily all-hands status updates, 3) they're not connected to their teams' work; there is no visibility into what's getting shipped, 4) there's a strong correlation with micromanagement.

Learned this through a few mistakes joining teams where the founder/lead insisted on frequent all-hands standups (sometimes lasting 45-60 minutes to get through all of the teams reporting in).

View on HN

> Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup)

It was even worse than this: The Scrum operators wanted an engineer from every team they interacted with to also join their meetings.

So if a project made an API request to another project, they'd insist on pulling an engineer from that team into their weekly or daily meetings.

I had daily meetings with 10 people, half of whom might be engineers from other teams who didn't need to be there.

Meetings became so useless that everyone stopped listening until their name was called so they could work through meetings. Then every time someone's name was called, we had to spend 5 minutes recovering the last 5 minutes of the meeting to bring them up to speed.

The inefficiency was out of control, but the worst part was that some people thrived on this level of inefficiency: Lack of progress meant the empire builders could argue for more headcount, too many meetings meant the Program Management department could hire more program managers. It was like a case study in adverse incentives.

sounds like my (big co) meetings. also in the "scrums" everyone gets stuck on one topic and it turns into an hour long debate that could have been resolved by 30 mins of coding.

I work I infrastructure and the daily meeting in the morning is the most important part of our day. It last 15 minutes, first we review and dispatch the active alerts, then we check escalated demands, then we check if someone needs help. We not do to solve issues during that meeting, this is done in smaller groups after the daily. That meeting keeps us aligned.

Also no managers are allowed during our daily meetings. This is something important that enables more candid communication.

> Big red flag is there is a daily all hands standup

Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls are only scheduled twice a week anyway.

Much better than the 20 person in-person daily standups in the conference room, better get there early if you want to have a chair, at 8:15am every day, like a previous job.

We do that where I work and we did it at the last place.

I found it stressful to write the summary of what I did yesterday in the morning because I’d been thinking about other things in the interim. I discovered the “life hack” of filling out my report in the afternoon at quitting time which makes me, from the viewpoint of everyone else, the first to report. I find it really easy to do and when I get in the morning I have a plan in front of me which helps me carry forward my momentum from the previous day.

I run this meeting often with teams.

It should be a literal standing meeting. You dont get to sit and drone on. There is one in every bunch and when they make their peers stand for 10 mins. The team will self correct the person into not being that way.

That meeting is a check point. What is every one up to, and everyone else gets to hear. It's a way to get a team to gel (and many aren't)... If someone surfaces a problem in there (and they should be) then there should be some other team member offering to help out - there should be dialog if some dependency is going to get bumped by others being distracted.

These meetings are effective up to about 10 people. They work well with cross functional teams, or teams where the members have varying levels of experience.

Time spent with the team ebbs and flows depending on complexity of projects, where in the roadmap you are, seniority of the dev team, and more.

The agile manifesto was too abstract in it's original state, and folks who needed a rigid framework created capital A agile in order to adapt it to their cog in the machine role.

For my team of 6 in a ~20-25 person (remote) startup, we have a 30 minute dev meeting in the morning, and a 15 minute full team meeting where the agenda rotates daily around departments. I quite like it honestly, remote can be lonely and isolating otherwise.

Generally I think it's important to structure team responsibility around who ultimately needs to make the decision (although they need to consult others and get team buy-in). And hire people you trust to make the decisions. Then the meetings become about problem solving and getting through the work, rather than performance art and politics.

As a counterpoint: back in the day (around 2010) at JetBrains we had a daily all-hands stand-up for several teams, about 15 people in total.

It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes.

It was pretty efficient: you almost instantly knew who are you going to talk to later in the day, if need be, or what changes to look at.

Sounds good. 15 people seems too big, but if you're keeping it under 10 minutes then all power to you.

Very few people care about "what did you do yesterday?". It's already over, by that point. There's a lot of benefit to removing that one.

In my team we do it like this:

- how are the nightly tests? (we've actually dropped this in recent months)

- what's in the Test column, and does it still need manual testing? (we have automated unit and integration tests but also, sometimes, do manual testing just so a 2nd pair of eyes has seen a thing work. We're not strict about it)

- what's in the code review column? Are any of them stuck/unreviewed/etc? (to remind people to do reviews)

- what's in the progress column that needs help/pairing or some kind of management support?

- any other business

With these three rules:

- save the details for other, more focused meetings or Teams. Anyone call time on any discussion.

- strict max 15 minutes time-limit

- jokes are fine

Works well enough that the next time I work in a team that doesn't do it this way I'll do all I can to move them to this format.

> Very few people care about "what did you do yesterday?"

...except the people for whom what you have accomplished is a dependency in their work. It can be a direct code change you'd have to merge into your current branch, or something you might want to start using (or finally stop using). It may be even something you have to contemplate on, and it may affect your work much later.

Work of people in a team is inevitably interconnected, and so is work of people in sister teams.

This is a good point. I imagine in a more cross-functional team this would become more important.

My current team is essentially front-end only and it's rare that we divide work up such that one person is waiting on another in the same team. If that's a possibility, we tend to pair instead.

If you have deps, it’s better to have a direct meeting with both teams in order to resolve mishaps and have a channel of communication setup for that. Daily standup is a poor replacement for that.

Being relatively new to the SE game, I’m curious - why can’t this be done via Slack?

It absolutely can be, that's how my team does it.

I've also seen teams update wikis for their daily standup.

It did not exist back then %) It launched in 2013. IRC existed, but for some reason it wasn't popular enough.

Eventually we wrote a real-time web chat, just because it was a fun project for someone. But it did not replace the standup, until I left in 2011.

Couldn't this just be an email instead?

No. No-one will read it and it slows down "what collaboration do we need to set up today" aspect.

If no one will read it, then maybe it's not important, so you don't need the meeting either? ;-)

> then maybe it's not important

The main point of stand-up/daily scrum is to set up collaborations and coordination. It's where you invite pairs, inform POs of blockers and discoveries that will lead to longer timelines etc.

If you're doing all that anyway, keep going and don't worry about stand-up.

If I don't go to gym, does that mean exercise is not important?

Some things are not very enjoyable, but still necessary.

We know scientifically that exercise is important. I highly doubt the same level of evidence exists for the importance of these short meetings.

Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.

> Also, if your boss tells you to read the emails, and you don't, then you can get fired.

The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term.

In many countries, it's pretty much impossible to fire employees for forgetting to read an email.

> If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.

I'll try a proof in a similar style - if Scrum was so wildly inefficient, the companies practicing it would be a long time out of business since companies with no meetings would easily outcompete them by offering better products/services for lower costs. Yet Scrum (or similar methodologies) are used in many successful companies all over the world, that's a proof that Scrum works.

How do you like them now, these oversimplistic "proofs"?

> In many countries, it's pretty much impossible to fire employees for forgetting to read an email.

What about "forgetting" to attend a 10 minute meeting?

> I'll try a proof in a similar style

It wasn't a similar style.

> What about "forgetting" to attend a 10 minute meeting?

The instances of people not attending standups I've seen were just symptoms of a larger problem, and such people did not last long in the company.

You didn't answer my question. Can they be fired or not? And if yes, what makes it different from emails?

Also there are some things which are not enjoyable, and definitely not necessary.

Standups are one of these in my honest opionion.

oh god no

This is how it should be done. No filler, no smalltalk — straight to the point.

This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings.

I once mysteriously turned into "not a culture fit" after several rounds of interviews with excellent feedback up to that point and I'm fairly sure asking a couple of similar routine questions about their dev process was what got me tagged with that label. I do consider that one a bullet dodged - if your process is so bad that you're worried about a candidate asking about it or you think they're being awkward for doing so then that says everything really - and I still ask similar questions of anyone I might work directly with/for today. But if there's a place you really want to work it's worth keeping in mind that some people apparently get rubbed the wrong way by this kind of question.

Every meeting only has 1-5 people talking, regardless of how many people are in it. Especially if they're remote. Sometimes a large meeting with many listeners is ok, but the same 16 people meeting every day is a waste of time.

Reply on news.ycombinator.com