One of the biggest mistakes I see managers make with Status Hero is setting the team’s expectation that longer check-ins are better.
They are not.
Status Hero check-ins are modeled after stand-up meetings. These meetings are designed for brevity and to capture only critical information. (That’s why they are called “stand-ups”: the discomfort of standing for long periods is intended to keep the meetings short.)
Short check-ins have the following benefits, just like short stand-up meetings:
- Participation and engagement. It’s simple: short check-ins require less time. With burdensome long-form check-ins, team members will surely find ways to prioritize other activities over filling out the form, crushing participation rates and limiting valuable data for everyone.
- Team communication and collaboration. Short check-ins are consumable by the rest of the team, enabling them to work together, avoid duplicative efforts, and unblock each other. Long check-ins will just get ignored or skimmed, and all of these efficiencies are lost.
- Purpose. Distilling accomplishments and intentions down to a sentence or two encourage critical thinking: re-centering focus and grounding daily work. Creating a long-form list of details is generally a passive activity.
As for tasks, issue updates, commits, deploys, and other essential team events and project management activity, Status Hero compiles all of that for you automatically and marries it to the check-ins. No need to bullet those items out.
As I’ve written before, Status Hero is opinionated software, and we are certain of the belief that short check-ins are more valuable. That’s why the configuration defaults include:
- Limitations on adding questions.
- Copy that encourages brevity in the forms, e.g. “Just a sentence or two.”
- A simple yes/no goal-oriented approach that works in conjunction with your existing task management tools
If you’re asking for long check-ins or observing your team members filling out big blocks of text for check-in answers, I urge you to reconsider your team’s approach to check-ins. One tactic that works well is approaching check-ins like you would a git commit message: with a style guide for the team to follow. This way, your team’s check-ins are both concise and consistent.
Still skeptical? Try out short check-ins for a few weeks, perhaps with a commit-like style guide. I think you’ll be pleased with the results. (And your team members will be a lot happier.)
Have a great weekend,
Henry