Ditch Project Status Reports to Build a Culture of Accountability
Foster a Demo Culture to Build Ownership at All Levels
In this post, you will learn how to create a development culture centered around accountability that is fulfilling for everyone involved. Accountability is essential for establishing trust and producing innovative products. One of the most effective ways to cultivate accountability is by fostering a demo culture, where makers take ownership of their contributions and demonstrate their work rather than just talking about it.
My thanks to Chris Clark and Ramsey Lubbat at Grove Collaborative for bringing me into the light of demos. Every agile shop does sprint demos, but taking the next step to commit fully to a demo culture was difficult for me. At Amazon Lab126, we had a ‘Critical Project Review’ status meeting to track projects 8am Thursdays - it was not a fun process, but it got the job done to ship wildly ambitious products. At Grove, we eliminated this type of status review right when we were delivering ‘bet-the-company’ milestones. I promise you this — if you succeed in building bottoms-up accountability, you will never go back to project status reports.
SERV just kicked off demos and it’s already my favorite day.
"Build, iterate, repeat. Don't lose sight of the work itself as your organization scales, as internal feedback cycles can be just as valuable as external ones in finding breakthroughs. The demos build trust and alignment with partner teams so that evolving org structures, processes and swim lanes don’t get in the way of driving impact for your customer & the business."
- Andrew Silard, Head of Consumer Growth, Openstore (former SVP, Growth Marketing for Grove Collaborative)
Queue mandatory Office Space reference!
Why did we commit to demos?
We found project status reporting was ineffective compared to individual and team accountability. Stressing about timelines rather than the underlying team, context, impact drivers, and execution is a mistake I learned the hard way. It’s just not worth it.
When I first started at Grove, we had a weekly product development status meeting attended by about a dozen leaders in our conference room with no engineers present (‘let’s not distract them with a status meeting’). As we scaled company headcount, by mid-2020, this ballooned to 80+ attendees as Zoom meeting creep hit full effect. We tweaked it, trying to refine the format and attendees; it was not worth saving. People were tuned out. PMs bemoaned explaining the work of others, and it had no teeth. Projects that missed milestones just changed the date to a new one. We didn’t know why we were missing, and chasing answers from the team created more swirl than solutions.
It went beyond the meeting. Makers were being given directions by PMs, and PMs were expediters in the kitchen trying desperately to push projects along (literally trying to schedule code reviews). Distrust and frustration between engineering and PMs ensued. Sound familiar? This sucked. We all knew it, and we fixed it together.
“In retrospect, there was a rift despite our best intentions and friendships. My team felt on the hook for creating status presentations, often explaining bad news, and the developers didn’t feel agency to own their work. One engineer even thought I was his manager. We needed a system that could scale past a small group of people.”
- Jenn Bordner, Former Director, Product Management at Grove
Why Do You Need a System Built in Bottoms-up Accountability?
If you build a culture of order takers, you can expect ‘B’ level results and usually get uninspired work. You will get the best of what a few leaders can think of, rather than a distributed system of brilliant minds making micro-adaptations invisible to leadership. At Amazon, I observed the value of inspection by leaders, and in some cases, I still practice it. For specific projects, however, managers telling you about progress against milestones is not productive. Rather, we needed to create a culture of bottoms-up accountability and have leadership focus on the system. To put this in place, you need an organization connected to a single mission. An org should be split until you achieve this. More on ‘Org’ in a few weeks.
How do you know you achieved it? What Does It Feel Like?
When your team is in a flow, it feels like product teams are pulling you forward. Velocity feels like the tracks on a tank: consistent, steady, known, and ready to pivot with new information. You feel like you can take any idea from a white sheet of paper to a product-customer outcome. The work comes to life in small pieces every week. Teams identify issues they need to resolve to achieve milestones and escalate quickly when blocked. Bad news travels fast in small chunks, frequently, along with solutions proposed by makers. Each sprint, you are busy communicating changes to your customer, reading results and making adaptations towards impact.
If you build a demo culture, no status reports will be needed to achieve progress—you will need project communications to understand the rapid change and parallel progress occurring, and to coordinate go-to-market activities. I cannot underline the transformation that occurred in team-level accountability when we fully bought into biweekly, end of sprint demos.
Your teams demand to understand the end-user impact of their work, and all seek to understand lessons learned from past projects. All of this, and as a leader, you are not (a) chasing ‘where are we with X’, (b) moving team members around, (c) solving the team’s problems. It’s not perfect—some projects will be late, some repeat mistakes may happen, and some work may not meet the standards of your organization. But it feels like progress, all the time with no ‘project managers’. It’s awesome.
Even better, it’s perfect for startups and ambiguity. Teams are adaptable to changes in strategy because they are connected to the hypothesis and results. Be warned to have good justification when you pivot, however, because because your team will be fully bought into the mission. You have team members who will step in to cover another job. Makers can explain the customer pain points and potential impact solved by each demo. Revisions from stakeholders come in proactively in demos. For instance, Customer Service reps will see your demo and flag top potential contact drivers.
How Do I Get Started?
Start by motivating a committed team towards a common goal with a shared vision and context. Create an easy-to-understand set of priorities in the language of your customer so every person can understand it from business people, to customer service to technical talent. I recommend doing this with a strategic planning process and narratives that dive deep into the hypotheses, value drivers, and trade-offs. These are tons of work, particularly for the author, leadership team, and PMs. There is no replacement for digging into a vast set of potential priorities, selecting the most impactful, and earning buy-in from hundreds of smart people that it’s the best course of action. This will be covered in-depth in a separate article.
Practice trust and transparency.
One technique to achieve this is a 1 page strategy, tactics and outcomes scorecard. It helps teams visualize their work’s impact towards achieving the bigger picture plan, and creates a transparent evaluation criteria for success. Focus on inputs needed towards your goals and results achieved or not achieved. Make this transparent and review it monthly outside of sprint rituals.
Setup a common Agile foundation
Make sure your teams have a common agile foundation and run fairly consistently. Let the team make their own mistakes and hold them accountable for fixing it by asking them their plan. We brought in Bob Gelan to teach a curriculum and he is a pro. Speaking the same language and using a consistent process makes implementing demos much easier.
How do demo days work?
If done correctly, demo day is the best day of the week. Teams are committed to delivering great shippable work and explaining their choices towards the intended goal. No excuses necessary, no remote work policy, no worry about weekday appointments. People know what they want to deliver, and they get it done to the best of their abilities. It’s fun, visible, and repeatable.
Implementation: Engineering managers were responsible for hosting demo days and they help guide to these milestones. We made the invite public to stakeholders with a tool like a company calendar on Google. The agenda of demos should be emailed out when the sprint ends the day prior, so busy stakeholders know which to join. The PM can set up the ‘why’, add data and contextualize priorities. Highly technical milestones are going to be at least half of the demos, and that’s okay—it allows engineers to explain the ‘so what’ of the work, so stakeholders understand its value relative to customer facing features. You will get active feedback on shipped work, as it’s complete.
Challenges to overcome:
Stakeholders may struggle with demos to start. Agendas help select for appropriate attendance, but no matter what, blocking off a day to sit through 3-4 demos seems like it will kill your week. Start by giving before you take — immediately cut the status and alignment meetings you no longer need. Approach your senior most counterparts, and get their buy-in to attend and visibly participate. For instance, our CMO, Jennie Perry was the most active participant. Her consistent participation showed that demos were a valuable use of time.
You will receive requirement and design feedback after the story is ‘done’. Employ a good balance of backbone and resiliency with last minute input. If the team gathers design and requirement feedback upfront, this happens less frequently. Even so, don’t slap the hand of your stakeholder - they just want to help you be successful. One way to look at it is similar to customer feedback you get post-launch, that you’re getting a head start on.
It can be difficult to be inclusive with matrixed personnel like PMs, PMMs, QA, Analysts and Designers. We structured it so PM, analytics and design present when appropriate to that pods’ work.
Set a constructive tone for feedback. Balance gratitude for getting the story done, with constructive feedback you feel necessary to maximize impact. In the early days, it was easy for demos to be demoralizing or completely devoid of feedback if the group is uncomfortable sharing. If you start with “I think one way to maximize the impact would be…”, you’ll often hit the right balance and invite others to provide their lens as well.
Always hold demos. It’s tempting to cancel when there is nothing to demo. Hold the line here. The only time I recall that we canceled demos was when we broke the sprint due to a layoff, or holiday like the week of Christmas.
What Will the Product Leadership Do Now?
Your role shifts towards more valuable activities for the company! For instance, you review progress towards outcomes brought by product prioritization decisions. I recommend setting up a ‘Strategy Scorecard’ that mobilizes your strategies, tactics and outcomes in a 1 page summary. You focus on whether your outcomes are on track (e.g. improving CAC/LTV), and less about individual dates. You focus on creating value for customers, the company and shareholders.
Prioritization: With greater accountability and predictable delivery, you have more ground to stand on when you reinforce the priorities and steady the roadmap against shiny object syndrome. Allow the team to prove out the product value hypothesis set forth in the strategy. Triage small ideas that may not matter, especially those that come from executives. Use judgment to know which to investigate vs say ‘not right now’. Tell the story of results to the leadership and board to celebrate progress. Talk about what you ARE working on and understand what you chose not to work on.
Dive into the system and most impactful programs: A Head of Product is there to make decisions fast, set clear priorities, and work on the ‘innovation factory’. You need to personally join the working group on the top 2-3 ‘make the company’ programs, particularly those where you are the only person with expertise. You need to inspect your strategy and goals relative to the company’s needs. You need to proactively identify risks your team’s work poses and help break big bets into smaller two-way door chunks—if you’re thinking big, there should be plenty! Your perspective allows you to see broader arcs of work and results (or lack thereof) to suggest pivots. You can identify persistent issues and ask team members to solve them.
Consistent feedback process: The best part, is that this allows you to focus on finding value for the customer, giving feedback on the most important product decisions. These are best reviewed and handled in a specific product review, design review, or MPR meeting. You may need to address resource leveling if teams are thin with few redundancies. Ultimately, when you hit an execution issue, you need to dive into the smallest level of detail and help the team get to the answer fast. You may need to aid in communication and change management with stakeholders to get the 'rude questions’ they may not share directly to the team.
Be a talent developer: By focusing on the system, you will start to see where individual skills have an opportunity to shine, or need to be improved for the team’s benefit.
What About Dates?
Yes, you still need dates. Stakeholders outside of the product development teams need to know when things are happening so they can plan their work, estimate impact, and explain changes to customers. Leadership needs to understand to communicate upwards when to expect milestones from their most expensive resource. Forecast progressively as you refine scope and gain more information to avoid false precision.
Note: Hardware and device software is usually different. There are needs to dive deep and deliver firm developer commitments for hardware lockdown, firmware lockdown, etc, you know… because of factory tooling, printed materials, products shipping on ocean etc. If you hate planning and dates, steer clear from hardware.
Refine dates progressively: from a Quarter to a Month to a Launch Date.
If a project has not started, plan with a t-shirt size estimate to a quarter with high level estimation. Once the kickoff occurs and work is broken down by makers, go ahead and forecast a month using team velocity, points and the number of sprints. Once you’re within a sprint or two of shipping and you can see the finish line, you should be able to forecast a launch date when the final sprint wraps up. The idea is that you should gather enough information through the arc of the project so you only miss by one order of magnitude. For example, in the planning phase, you aim for a quarter and might underestimate by one quarter. Software estimation is usually only accurate to this level. Unknowns are expected in agile development and the ability to uncover them cost efficiently comes with experience.
If you see a more severe miss against expectations, it’s usually because a) it was too big of a project to estimate to a quarter, b) the product failed to refine scope or added to it (maybe a compliance item?), c) our forecasted velocity was materially different (lose a team member), or d) the team was blocked by something out of their control.
In Conclusion
Building a culture of accountability and delivery is crucial for product development. The most valuable product development priorities are: 1) to create a demo culture where the best status report is working software, 2) build a culture of trust and transparency, and 3) allow teams to make their own mistakes and hold them accountable for fixing it. While it's essential to have dates to inform activities, focusing on dates as ‘inputs’ is counterproductive; it takes your eye off the underlying team, context, motivation, and execution. By building a demo culture, you can build a system based in accountability that is also a joy to lead.