Cut into the watermelon
How to avoid debating between 68% and 70% complete
Photo by Sahand Babali on Unsplash
Anyone who has worked in the corporate world for any amount of time is aware of status meetings. These meetings happen at all levels of the organization and usually feature some sort of tracker being displayed with some poor soul having to go line by line asking about the status of each project/program. How many lies and half-truths have been told during these meetings?
While there is some value pulled from these meetings, the vast majority feature questions like:
What percent complete is your project?
Is it yellow-trending-green?
Have you solved some of the more challenging user experiences?
Not wanting to look bad in front of their peers, most managers will give the most positive update possible. This ceremony directly produces “watermelon reporting,” a term I thought I coined in graduate school when writing about project management, but apparently, a watermelon being a proxy for project status wasn’t that hard of a concept for others to come up with.
Watermelon reporting is simple: project status that is green on the outside, but red where it counts.
The only way to find out is to cut into them. The questions above don’t do that. Senior leaders should be looking for alternatives to better understand the status of projects. One very effective way is to push teams to perform regular demonstrations of their projects/programs which can be used to dive deeper into the real status of the work.
Quick aside: I recently wrote about how to give a good demonstration and would encourage you to check that article out if you haven’t already!
How do we set teams up for success in this model?
Find out by becoming a premium supporter of the Common Reality and unlocking the rest of the article.
Use regular demos to build a successful team
One of the best ways to build an effective team as a Manager is to generate credibility with your stakeholders. This becomes a bank account (of sorts) that can buy you time and support when your projects aren’t going well. And one of the best ways to increase the balance of this account is by constructing a team operating model that emphasizes demonstrations.
Begin by creating a team-level model that prioritizes demonstrations. Schedule a recurring meeting, every 2 weeks, where the team comes together to show off what each team member has built. Each demo should be roughly 5 minutes in length and follow the leading practices outlined in Don’t bobble their heads. Let everyone pick their topic to show off - an interesting bugfix, a new ops tool, an itch that needed to be scratched, etc. - the content doesn’t matter as long as everyone gets an opportunity to practice.
On your sign-up sheet, let everyone also sign up to be a feedback provider for one of the demos. While everyone should be paying attention and providing feedback, this more formal reviewer will evaluate the demo against leading practices. This isn’t meant to be a stressful situation, but the feedback captured should help the presenter improve on future demonstrations.
Most importantly, by creating an environment where the individuals on the team build comfort with the act of giving and receiving feedback, you drive toward one of the key elements identified as a marker of a successful team: psychological safety.
Align demos to strategic objectives
The team’s more formal demonstrations need to be aligned with how the organization reports progress. For example, at Citizens we have a Capstone meeting roughly every six weeks in which teams update senior leaders on key initiatives. At AWS we aligned to quarters (as a default) and major conferences (e.g. re:invent). Figure out what type of rhythm your organization has and start building out a plan that gets your team’s deliverables presented.
If your organization doesn’t have something for you to align with or the period is longer than six weeks then the team manager should develop their own frequency. In the lead-up to the 2023 AWS re:invent conference, my team was delivering two major features for Amazon CodeCatalyst. I opted to have the team come to the leadership team’s daily status meeting every two weeks to show off our progress. The team built trust with senior leaders that we were on track and gained valuable feedback from the audience.
Assume that you have a team (8-10 individuals) working to deliver a major new feature on one of your software products. They have estimated roughly fourteen calendar weeks of delivery time to get this feature live in production. Back off from the 14th week because you don’t want to be feature-focused that close to launch. Make your last end-to-end demo at the end of the twelfth week with 2 additional “major” demos at the end of the 4th and 8th weeks. If you have a cool/interesting user journey that can be demo’d in a contained way, sprinkle that in somewhere between the major demos.
Orient the team around this schedule. Reference it constantly during kick-off meetings and planning meetings. What you are showing off is what you are building so it makes sense to spend your time and energy on this.
Here are some actionable steps the manager should take:
Write out the final demo script as a checklist. Working with your Product Manager, put the user experience you want to ship on paper. Be specific about the steps:
I log into the web application from /login
Post-login I am redirected to the /profile page
I observe my role as “System Administrator”
I click the “Edit Profile” button
etc.
Set a recurring meeting for the end of the week and set the agenda to be the same thing each time: the final demo script.
Start at the beginning of the demo and work through each step. Take notes, screenshots, etc.
How far did you get?
Why doesn’t step 3 work?
What do we need to get done to make that happen?
Challenge the team when something feels sloppy or the user experience feels bloated
By going through this process each week, the team will naturally start to figure out what work is needed and which work is less important. The team will also be really clear on how their work fits into the bigger picture.
The Manager should also not just be an observer of this process. The best Managers will actively give the demonstration - both to model the right behavior and to identify any issues that may have been left unsaid.
Showcase your people
Demos are also a great way to introduce and promote members of your team to the rest of the organization. These demos become a bookend for project work that can feel more complete vs. just pushing code to production. Think about the individuals on your team and where you are trying to guide their careers. Identifying work that pushes them out of their comfort zone is great, but combining that work with a demo to show it off is even better.
By getting the names of the members of your team out in the open you also can help avoid ending up in a situation where you are trying to promote someone only to find out that you are the only person that knows them. I recall a situation where a peer manager was presenting the performance review for a member of their team and was highlighting how great this person was. They had been one of the better members of the team for a few years, delivered some challenging work, and supported others on the team with their work. The only issue was that none of the other managers in this organization had ever heard of this person and started questioning whether or not the output was legit.
Reminder
Building a team-level culture of demonstration giving will help align the team on priorities. It will also enable the team to have a bench of individuals capable of showing off work - making the whole team appear “on top of it.” Senior leaders should open up the watermelons by pressing their teams to give progress updates in the form of a demonstration.
This is an operating model, not a one-time meeting. The team should be built around demonstrations, not just told to “demonstrate.”
I would love to hear your thoughts on this approach. Send me an email or post a comment on this article if you agree or disagree. How would you improve this model?