How We Run Standup Meetings (It's Not a Daily Scrum)

No boards were updated in the making of this meeting.

We don't like working with Agile Frameworks™ like Scrum. We know how to do it. We've led teams working with Scrum and similar methodologies. There's a use case, it can work fine. It's just not what we find the most efficient and pleasant day to day.

That said, we love the concept of a daily standup. It's usually the first thing we set up when joining a new client team that doesn't have one. But we don't run standups like daily scrums, so we figured it'd be worth sharing how we actually do it, both internally at Norveon and with the teams we work with.

How We'd Set This Up Today

Here's how we'd explain it to a new team:

The objective is to share interesting things relevant to your team and raise blockers. What counts as "interesting" will vary depending on context. Use your best judgment and don't hesitate to ask the group if something is interesting to them.

We meet daily at 12:03 before lunch for roughly 15 minutes. Some days it's 10, others might be 20. Someone keeps time if needed, but we count on everyone to keep things brief.

This is ephemeral. No boards, no notes. If something critical gets shared, it has to be repeated in writing asynchronously. Email, Slack, whatever.

This is not a reporting meeting. It's completely fine to share nothing some days. It's even encouraged. You most likely don't do something worth sharing every single day. Yes, we mean it. You'll see us do it.

You will hear updates that don't directly impact you. Maybe things you don't fully understand. That's normal and by design. Your goal is to pay attention, stay curious, and try to follow what everyone is sharing. Ask questions after.

Every few months, we challenge this format. That includes cancelling it. What we're proposing is the result of years of small iterations. We like it a lot, but it's not one size fits all. We have to start somewhere.

What Counts as "Interesting"

This part is intentionally vague. What's worth sharing depends on the team and the context.

To make it more concrete, here's what we commonly see shared:

• Discoveries. New tech, new part of the stack, new business opportunity.
• Feature progress. Something started, a significant milestone, a release, feedback from data.
• Upcoming projects. Discovery results, research findings, business or legal requirements.
• Reliability problems. Bugs, outages, post mortems, performance changes.
• Org changes. New hire, new team.
• Personal events. Babies, moving apartments.
• Blockers. Need a review, communication issue, lack of clarity.
• Office news. New policies, upcoming team building events.

What This Meeting Is Not

It's worth being explicit about what this meeting is not for:

Updating a board. That's better done asynchronously.

Reporting or tracking tasks. Same. Especially since not everyone will share an update each day.

Holding people accountable. People here are professionals and shouldn't need a daily meeting to prove they're making progress. If someone is struggling with that, it needs to be identified and handled elsewhere.

Planning the day. Do that in smaller, focused groups. Not every day, and team members should be empowered to manage their projects as autonomously as possible.

Forcing people to be present early in the morning. Yes, we've seen that happen.

Reaching a specific goal. Since this isn't Scrum, there might not be a sprint or a sprint goal. Reaching goals will be a byproduct of having a cohesive, efficient team.

Why We Think This Works

The main benefits of meeting quickly once a day:

Building empathy. Before you get a big PR to review, you'll have heard the engineer talk about it. You'll have context on the technical choices, the struggles, the tradeoffs. You'll also know something about their mindset. Are they late? Stressed? You can adjust your communication. Same thing if the PM shares pressure from the business.

Discovering what others are doing. Over the years we've learned so much about the work of engineers in fields we knew less about, just by listening to them explain daily what they were going through. It's even better when designers and PMs are present and sharing too.

Creating opportunities for discussion. If you stay locked on your tasks and tickets, you might be more productive short term, but you'll have a very narrow focus. That limits your capacity for impact.

Getting a pulse on the team. Are people feeling good, productive, positive? Or is everyone struggling? This is especially important for us as a distributed team where you can't count on discussions at the coffee machine.

Building intuition about who works on what. Hearing someone talk about a topic for months sticks with you. You'll know who to redirect questions to when the time comes.

Improving team dynamics. Just like regular 1:1s with your manager build a working relationship, regular interaction with teammates is far more effective than a once a quarter workshop.

And a small bonus for on site teams: doing it before lunch is a natural way to end the morning and get people eating together. Cheap team building. Surprisingly effective.

Questions We Always Get

We've set this up in many teams over the years. The overall result has been positive. Not 100% of the people got 100% of the value, but the ROI was good enough for us to keep doing it. Here are the questions and pushback that always come up.

"This is disruptive. I'm better off focused on my code."

Since it's every day, you can plan your day around it. We agree it's disruptive. But like regular 1:1s, it's an investment. Might not feel worth it today, but the value becomes visible with regular practice.

You might think your role is purely writing code, creating Figma designs, or setting up PRDs. It goes further. Understanding your team is more important than you'd expect. This time will smooth future interactions and save you headaches down the line.

"We should do this asynchronously."

Since the goal is building empathy and connection, doing it in writing feels unproductive. We're not yet convinced that reading a Slack message has the same impact as seeing someone share the same thing verbally.

Also, written updates leave a trace and will eventually start feeling like reporting. That's exactly what we're trying to avoid.

"No one will understand what I'm working on."

Sometimes you'll work on something tricky that only you perfectly understand. That's fine. Spend a bit more time explaining the context. You might need to repeat it more often, which is extra work.

But it has a double benefit: more people get onboarded onto your topic, and you get better at making deep technical work understandable. Both are worth it.

"I'm a designer, I don't care what developers are doing."

We think this is the wrong way to look at it. Understanding engineers, and having them understand you, is key to your success if you're building software. If you see development as just implementation details, you'll limit what designs you can actually get in front of users. Unless your job is only producing mockups and static assets, you probably don't want that.

"I'm an engineer, I don't care about non engineering work."

Also the wrong approach. It's incredibly helpful to understand more than just tech when building products. It might not be your cup of tea, but hearing about design a couple of minutes a day will help you identify shortcuts, make design debates smoother, and give you tools to challenge solutions that are too complex.

We'd encourage you to see your job as more than writing code. Opening up to other fields is a good way to get there, and here you have the chance to learn just by paying attention a few minutes every day. Good deal.

"We already have too many meetings."

If you have many other meetings, we'd rather review and cancel those. The daily standup helps reduce the total number of meetings by preventing problems and misunderstandings. Removing it frees up 15 minutes but will cost many more hours down the line.

"This isn't Scrum compliant."

Correct. It's not a daily scrum and it doesn't have the same objectives.

"You say it's not reporting, but it really is."

We get why it can feel that way. But we don't track what's shared, we don't export it outside the team. You're encouraged to share what's interesting, and that won't always be direct progress on your tasks, which makes this a terrible reporting tool. We'd much rather use our normal ticket tracker to see what's going on.

"I don't feel confident sharing nothing."

If you're new to the team, that's normal. Don't worry. You'll see others do it and it should feel less intimidating over time.

"Can you really share nothing?"

Yes. "Nothing really interesting since last time" works. "Still on the same task, nothing new to share" also works.

If someone has nothing to share for several days running, it might signal something. From experience, the reasons are usually one of three:

• They don't think their topics are interesting. Worth taking a minute to highlight why people might want to hear about a specific part of their work.
• They have a deeper problem. With the process, the work, the team, the company, or life in general. This needs case by case attention and is usually visible outside the standup too.
• They're stuck and don't feel safe sharing it. This usually resolves itself once they see others openly sharing blockers.

No framework was harmed in the making of this standup format. Your results may vary.