This is a highly opinionated view on best practices for running stand-up meetings. It’s based on the approach I’ve developed and refined through working with probably nearing a hundred product teams over the past 25 years.

Across all of them, one thing has held true: a good stand-up acts as the beating heart of a high-performing team.

Done well, they give the team focus, momentum, visibility, and a shared sense of purpose. Done badly – and sadly, that’s more common – it becomes a daily chore. A box-ticking exercise. Status update theatre. Or worse, a passive, rambling, soul-draining ritual no one looks forward to.

In this article, I’ll share the practices I’ve seen consistently work – and explain why they matter, not just what to do.

Focus on the work, not the people

I have a strong personal dislike for the classic Scrum-style format of “yesterday, today, blockers.” It reinforces the idea that the stand-up is about checking that everyone is doing something, rather than focusing on what truly matters: are we delivering? It encourages individual updates over team progress, and often results in only talking about the work people are actively doing – which means anything not being worked on, including stuck or neglected items, gets ignored.

Everything from here on is with the assumption that you are taking this approach.

Walk the board from right to left

The work closest to being in production is the most valuable because it’s closest to delivering impact. Until something is released, it delivers zero value – no customer benefit, no feedback, no outcome. It’s also where the most effort has already been invested, so leaving it unfinished carries the highest cost. By focusing on what’s nearly done first, you prioritise finishing over starting, reduce waste, and increase the chances of delivering real value sooner.

• Start from the right hand side of the board
• Focus on the work, ensure all work in progress has been discussed
• Conclude the stand up by asking
  • If there’s anyone that hasn’t spoken?
  • “Are we on track?” – A final call as an opportunity for anyone to raise any issues

Bias for action, delivery, and results

Stand-ups work best when they reinforce a culture of delivery. It’s not just about sharing what you’re doing – it’s about driving action, finishing work, and holding each other to a high standard. These behaviours help teams stay focused, accountable, and outcome-oriented.

• Focus on completion – what will it take to get this done?
• Use commitment language
• Take ownership
• Challenge one another to uphold best practices

Visible, present and engaged

Whether remote or in person, being visibly present and engaged is a basic sign of respect – especially for the person facilitating. It’s frustrating and disruptive when people appear distracted or disinterested, particularly in a short, focused meeting like a stand-up. Cameras off might be fine for a long company all-hands, but not for a 10-minute team check-in. The stand-up only works if everyone is paying attention and showing up fully.

• Bring your whole self, pay attention.
• Be on time
• Cameras on when remote
• Do not multi-task
• Gather together in person on office days, don’t stay at desks

Efficient and focused

Stand-ups are a tool for focus and momentum, not a catch-all meeting. When they drag or lose direction, they quickly become a waste of time – and people disengage. Keeping them brief and on-topic ensures they stay effective, energising, and sustainable. Updates should be concise and relevant to the team’s progress. Longer conversations needed can still happen – just not here.

• Keep it brief, aim for 10 minutes or less
• Talk less, be informative. Be as to-the-point as possible. Be on track and speak to what team needs to know
• Take conversations offline (agree how to follow up and who’s taking the action)
• Only team members contribute (i.e. not stakeholders, supporting roles, observers)
• Make sure the board is up to date before you start
• BUT, fun is good! A bit of informal chat, banter and jokes is ok 

Well facilitated

A well-run stand-up doesn’t happen by accident – it needs strong facilitation. The facilitator sets the tone, keeps the meeting on track, and reinforces good habits. Without that, it’s easy for bad habits and practices to creep back in.

• Have a clear agenda and stick to it
• Be the pace setter
• Be energised
• Ensure you’re sticking to the agenda
• Ensure you’re adhering to best practices

Rotate the facilitator

The stand-up is ultimately for the team, not for the facilitator. Rotating who leads it is a powerful way to build shared ownership and reinforce that principle. When the same person always runs them, it can start to feel like their meeting – which subtly encourages passive behaviour, status reporting, and a lack of collective responsibility.

By rotating the facilitator, you signal that everyone has a role in making the stand-up effective. It keeps people engaged, encourages investment, and helps the whole team develop a shared understanding of what ‘good’ looks like.

But there’s a big caveat: facilitation still needs to be good. Make sure everyone taking the role:

• Is confident and capable of running an effective stand up
• Can hold the line if things go off course
• Is open to feedback

Importantly, someone still needs to be ultimately accountable for ensuring your stand-ups remain effective.

A great stand-up should energise the team, not drain it. If yours isn’t doing that, fix it.

Appendix

Stand up health check

Use this to periodically assess whether your stand-up is working as it should:

✅ Was everyone present and on time?
✅ If in person, did the team gather together (not stay at desks)?
✅ If remote, did everyone have their camera on?
✅ Was the board fully updated before you started?
✅ Did it finish within 10 minutes?
✅ Was everyone engaged and paying attention?
✅ Did everyone in the team speak and confirm what they’re doing?
✅ Was all work in progress discussed?
✅ Were any follow-up conversations taken offline, with a clear owner?

Further reading

Martin Fowler – Its Not Just Standing Up – a comprehensive guide to patterns and practices for daily stand-ups.

Most people were taught OOP means organising code into classes, using inheritance to share behaviour, and exposing/manipulating state via getters and setters. This has led to bloated, brittle code and side-effect-ridden systems that are hard to change.

But that was never the intention!

Alan Kay, who coined the term in the late ’60s, had something very different in mind. He saw OOP as a way to build systems from independent, self-contained objects – like small computers – that communicate by sending messages.

So where did it all go wrong?

Languages like C++ and Java formalised classes and inheritance as core features. Academia followed, teaching the “4 pillars” of OOP – encapsulation, abstraction, inheritance, and polymorphism – often illustrated with real-world analogies like cats inheriting from animals or shapes extending other shapes 🤦‍♀️

This encouraged developers to focus on classification and hierarchy, rather than systems that emphasise behaviour, clear boundaries, and message-based interaction.

Kay later said:

“I’m sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”

And:

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

In other words, OOP was meant to be about communication, modularity, and flexibility – not rigid structures or class hierarchies.

Kay’s original ideas are still just as relevant today. They’re language-agnostic, and they apply just as well in JavaScript, Go, or Rust as they do in Java or C#.

If you’ve got a beef with OOP, aim it at what it became – not what it was meant to be.

What can we do instead?

If you want to align more closely with the original spirit of OOP – and build systems that are easier to understand, change, and scale – here are some heuristics worth considering. These aren’t hard rules. Like any design choice, they come with trade-offs. The key is to think deliberately and apply them where they bring value.

Design small, composable parts that can evolve

Avoid deep inheritance hierarchies. Instead, model systems using small, focused components that you can compose (“composition over inheritance”). This encourages flexibility and separation of concerns.

Let objects own their state and behaviour

Don’t pass state around or expose internals for others to manipulate. Instead, define clear behaviours and interact through messages. This reduces coupling and makes each part easier to reason about in isolation.

Reduce hidden side effects

Use immutable data and pure functions to limit surprises and make behaviour more predictable. This isn’t about functional purity – it’s about making change safer and debugging less painful.

Look to supporting architectural patterns

Approaches like Domain-Driven Design (DDD) and Hexagonal Architecture (aka Ports and Adaptors) both support a more Alan Kay style approach to OOP.

DDD encourages modelling your system around behaviour and intent, not just data structures. Entities and aggregates encapsulate state and logic, while external code interacts through clear, meaningful operations – not by poking at internal data. Bounded contexts also promote modularity and autonomy, aligning closely with the idea of self-contained, message-driven objects.

Hexagonal Architecture reinforces separation of concerns by placing the application’s core logic at the centre and isolating it from external systems like databases, user interfaces, or APIs. Communication happens through defined interfaces (“ports”), with specific technologies plugged in via adapters. This approach makes systems more modular, testable, and adaptable – supporting the kind of clear boundaries and message-based interaction that aligns closely with the original intent of OOP.

If you’ve not yet got into Systems Thinking, now is more important than ever.

AI brings the promise of big productivity gains – but so many optimisation efforts deliver nothing. Worse, they can take you in the wrong direction, faster – exacerbating the very issues you’re trying to solve.

Why? Often the things that look like the problem are just symptoms. They’re usually the most visible and measurable activities – and therefore appealing to focus on. At best, it’s like taking painkillers instead of treating the underlying cause of the illness.

I see it all the time – organisations attempting local optimisations to the wrong part of the system, blind to the knock-on effects. Fixes that make bottlenecks worse, and costs taken out in one place, only to reappear elsewhere – often bigger than the original saving.

GenAI makes it even more tempting to fix the wrong problems. It’s good at generating documents, writing more code, handling support queries. None of which are directly value-add activities, but they are visible and measurable.

There’s a real risk of just getting busier with busywork.

That’s why you need to step back and look at the system as a whole. Map end-to-end value streams – across people, process and technology. Identify pain points, bottlenecks, and constraints. Understand how the work flows, and what’s actually causing the outcomes you’re seeing.

That’s systems thinking in a nutshell.

A lot of the theory-heavy books make it sound more complex than it is. It’s why I’m a big fan of The Goal by Eliyahu M. Goldratt. Yes, it’s a corny business novel – but it’s one of the most practical intros to systems thinking you’ll find.

When you take a systematic approach, more often than not, you’ll find the real problems aren’t where the pain is, and rather than playing whack-a-mole patching problems, you’ll uncover opportunities to make changes that deliver real, lasting impact 🙌