Do you feel overwhelmed keeping track of everyone’s status?
Daily updates and stand-ups never worked for me. I don’t have time to check up on everyone and progress at a B2B company doesn’t change every 24 hours. Even asking for an emailed daily status seemed inefficient. Often I’d observe the same status “working on X feature” from an engineer. Well, of course – we both agreed that’s the task done by a certain date. I don’t need to hound the engineer if the feature is done or not.
If I eliminate constant updates and stand-ups, how will I know if there’s progress?
That sounds pretty drastic. Let’s reframe the situation. My team knows they can ask me for help. I’ll do whatever I can to clear roadblocks which includes allocating more computing resources, advising on technical decisions, or reframing the problem. They contact me however they want – in person, email, instant messaging or phone calls.
Depending on how much help they need, we will re-evaluate deadlines and project scope. That’s one way I can tell how things are progressing. If they’re quiet, we have an understanding they’ve got everything under control.
Now you don’t need daily standups or whatever your “scrum jedi” wants. Assume your team has 10 engineers and standup context-switching drains N hours from everyone. Let’s get idealistic with my math. By eliminating daily statuses, you save 10 x X x 5 = 50N work hours a week for the team.
You just gained more than a work week if N >= 1. Think of all the other things you can accomplish with extra time.
Encourage your team to update you
So rather asking for an update, have everyone update you. You can use your time productively to assist teammates that need help or concentrate on other tasks like hiring, writing down next quarter’s roadmap, or fetching coffee.
I call this technique “asynchronous updating.” Asynchronous is more efficient for my organization because the team only reports status when it’s actually worth reporting.
Conceptually, this sounds wonderful.
One major concern is this approach assumes projects are very well-defined, like waterfall style. The dream is your team knows exactly what they have to work on, and you don’t have to interfere until it’s done.
Dreams aren’t real.
Reality
Business requirements do not exist in a vacuum and there will always be changes that could affect what your team is working on.
A friend in management consulting recommended looking at the new change in requirements by determining which category the project falls under:
- Architecture (affects multiple engineers)
- Features (affects one engineer, typically siloed)
- Twiddling (tweaks that do not really involve anyone)
Incoming request: Priority Zero
You begin the day with an important customer with urgent requests. Your job is to determine if it’s an architectural or feature change, and then interrupt the correct number of engineers to update them on the status of the product change. But you’re still not pulling your entire team in.
Most of my the projects are on 3-4 day cycles. By the time we figure out the actual requirements of a new feature (which takes at least a day), they have time to complete their previous work. Then they can move on to the new project.
Polling is still okay
Just not hourly or daily.
You should still ask for status periodically. This lets you resync with your team and you’ll be more engaged with progress. Your team might feel bad for interrupting you with an asynchronous update. If you ask them ‘How’s it going?’ once in awhile, you could learn a few things. You might notice they’re stuck on a problem, and you happen to know what resources they need to quickly push past it.
So check in once in awhile. Double the time you ping each individual for status if nothing has gone wrong. If you ping them daily, ask for status 2 days from now. Then 4, then maybe 8. 1 week cycle (6 business days) seems to be a good medium for my team. A month is definitely too long.
Your team is also updating you in the meantime. So now it’s asychronous updates with weekly polling. Then interrupt the subset of engineers if business requirements change.
I can get wordy and call this whole process “interrupt-driven asynchronous updates with variable polling.” If you can say that with a straight face, then by all means trumpet it proudly. If your team can accept that with a straight face, you are in a very interesting organization. I would like to talk to them.
You’ll be interrupted more with asynchronous updates, but that comes with the job. You can take the time loss because your team is better off focusing on advancing projects. And if you feel lonely with no status reports, get a stuffed bear and talk to it. Everyone will think you’re a little crazy but you also won’t be bothering your team.
Everyone wins.
Leave a Reply