Why I Killed the Daily Standup
I hate having meetings on my schedule. It feels like I cannot even start anything productive until I have finished my meetings for the day.
If you work in tech, you probably know the concept of the maker versus manager schedule. Managers operate in one-hour blocks. Makers need half a day just to get into the right headspace to solve a problem. Yet, the tech industry still insists on dragging developers into a daily morning video call to recite what they did yesterday. It shatters the morning before the work even begins.
A few years ago, I decided to stop doing it. I manage my team using a hands-off, observation-based approach. We do not do daily standups. Here is how I actually track performance, catch blockers, and keep project managers happy without breathing down everyone’s necks.
The GitHub To-Do List
People ask how work gets reviewed if we never meet to discuss it. The answer is simple: I look at the work where it happens.
I use the GitHub integration in Slack. Whenever a pull request comes in, I get a notification. The bot also pings me twice a day, once at 10 AM and once at 3 PM, with a list of PRs I still need to review. This acts as my actual to-do list. It makes it very difficult for me to ignore pending reviews.
If a junior developer gets stuck, I do not want them waiting for a morning meeting to tell me. I instruct them to open a draft PR early. This lets me comment directly on the problematic code. We fix the issue in the context of the code itself. If things get too messy or they need a longer explanation, they can ping me in Slack for a quick chat.
Aim to get it wrong. Try something, see if it works, and push a draft PR. We can step back, assess where it went wrong, and iterate from there.
Reading the Room
You do not need a video call to see if a developer is struggling or burning out. You just need to pay attention.
Instead of tracking lines of code or listening to status updates, I track behavioral changes. Often, the signs are very subtle. A developer might get slightly more aggressive or defensive when I leave a routine comment on their code. Other times, someone who is normally chatty goes completely quiet in Slack. They stop sharing fun links in the social channels. They stop giving unprompted progress updates in the production channels.
These are the real red flags. If a developer stops talking to the team, they are usually drowning in a problem or burning out. You catch these things by observing human behavior, not by forcing them to fill out a timesheet or speak in a daily standup.
Coaching the Project Managers
Working at a Canadian digital agency means dealing with project managers and client budgets. PMs need updates. Sometimes they ask for updates too frequently, to the point where it becomes disruptive for the developers trying to build the thing.
I do not fight the PMs. Instead, I empower them. I teach them how to look at GitHub. I show them how to read a commit history or check a PR status so they understand what is going on without needing to ask.
I also ban back-channeling. All progress updates must happen in the public production channels, never in direct messages. But there is a catch. I have to coach the PMs to act as silent observers. They can read the updates, but they cannot jump on a small Slack message to demand more information or become a helicopter manager.
We do keep one synchronous ritual. Once per sprint, we hold a 15-minute health check. We go down the list and state if a task is on track or if it needs to get pushed to the next sprint. That is it.
The job function of a software developer is to solve a problem in an automated way. They need long stretches of quiet time to do that well. Give them full agency. Trust them to get the work done. You will be surprised by how much more they ship when they are not worried about what they have to say at 9:30 AM every morning.