The Startup
Published in

The Startup

Photo by Magnet.me on Unsplash

Is Your Demo Meeting Worth It?

Sprint Demo. Sprint Review. Demo Day. All Hands. Show and Tell. Lunch and Learns. I’ve seen many flavors of the BIG DEMO meeting in tech companies who want the disparate squads of a growing engineering team to still come together and feel like a team. They generally look the same: Every two to four weeks the entire engineering department and a handful of key stakeholders gather while a product person drags engineers up to a podium to talk about their latest work. These meetings usually have well-meaning and lofty goals such as:

  • Demo functionality to management and stakeholders from across the business and gather feedback
  • Celebrate the accomplishments of individual teams
  • Drive alignment and inspire collaboration between disparate technical squads
  • Highlight the individual contributions of various team members across the company.
  • Share learning across teams
  • Make us feel like “one team again”

This all sounds great, but BIG DEMO meetings can quickly become expensive drains on your engineering team. For example, let’s consider a team of 25 product, engineering, UX, and management folks split across three teams at a growth-stage startup. The team decides to meet for one hour at the end of every other week to show off the work recently accomplished. If the average salary of your team members equates to about $50 an hour ($104k annually), each meeting costs your company $1,250. At the end of the year, the company has spent $32,500 on the BIG DEMO meeting. There’s a lot of tangible things any company could do with $32,500:

So how do we make sure BIG DEMO meeting is worth it?

Photo by Austin Distel on Unsplash

Clearly articulate the goals for every audience member.
BIG DEMO meetings typically include Makers and Managers. Be respectful of Maker schedules so you don’t kill an entire afternoon of productivity. Make sure that the content is valuable to both audiences and isn’t just a status update to the Managers in the room. One way to do this is at the start of each demo, have the presenter articulate the following:

  • What I am sharing today is _____ (what is the actual problem you are seeking to solve with this work)
  • The work is at the stage of ______ (done, discovery, in progress, etc)
  • The constraints I am dealing with are _____ (e.g. “I only have two weeks,” or “We don’t have x data available”)
  • The type of feedback I am looking for is ______ (workflow fit, how others could use a shared service, detailed design or copy critique) and I’d prefer to get feedback by ______ (conversation after, email, slack channel)
  • The next steps for this work are _____ .

Tell a Story. Focus on Learning.
Nothing is worse than sitting through a demo that gives no context on how it affects you as a team member or how it will help your company’s users. Clearly articulate the value of the work in terms the whole audience will understand. What user stories defined the work? How will you measure its success? What lessons did your team learn from this work that you want other teams to benefit from? What new technology did you pioneer that you’re now proud to call yourselves the resident experts on?

Be clear on what BIG DEMO is NOT.
If you’re running a strict Scrum shop (or claim that you do) Sprint Review and BIG DEMO are not compatible. In the words of Maarten Dalmijn, “Calling the Sprint Review a Sprint Demo, is like calling a nine-course meal an appetizer.” Sprint Review should be focused on the work of one team with a targeted set of stakeholders and include the work to plan for your next Sprint. BIG DEMO is not a collaboration session; there are too many cooks in the kitchen for that.

Don’t duplicate demos. Make each one meaningful.
If you already showed off functionality at a different corporate function that the majority of the team participates in, don’t show it again. If the audience is familiar with the bulk of the workflow, start with the newest additions. Don’t show off changes that are trivial. No one cares you changed a button color from blue to red unless your data also shows that significantly moved the needle on a key success metric.

Don’t be afraid to get technical if engineers will be legitimately excited about it.
Engineers love a good geek-out session. Sometimes having DevOps fire up a console and show a new automated process is a great way to fire up your dev team. Walking through a code sample of how to use new tech can be a great learning opportunity. Demonstrating how much faster your application is after a major refactoring effort is a big win. Your stakeholders and your management team may have no idea what they’re looking at, but if you told the right story about why it’s valuable at the start and your engineers are genuinely stoked, they’ll be more apt to listen the next time you’re advocating to prioritize similar work.

End it early. Be willing to cancel from time to time.
Don’t meet for the sake of meeting. If there’s not enough quality work to show off in an iteration, end early or preferably, skip altogether and include the content in a larger gathering next time.

Truly celebrate the work.
Be proud of what your team has accomplished and make sure management is there not just to get status updates, but to be a cheerleader for the team. Use it as an opportunity for the team to get positive kudos and demonstrate the value they bring to the organization.

Evaluate the value of the meeting frequently.
Talk about BIG DEMO in Retrospectives. Share ideas on how to improve it with the organizers. Don’t just sit in the back and sulk about the waste of time. And most importantly, don’t be afraid to kill it. Your team might get the same team camaraderie and knowledge-sharing benefits out of paying for more team lunches, and that’s ok too.

Hopefully, with these tips in mind, you can run productive, informative BIG DEMO meetings. Or successfully kill them and get more free food. After all, there were some very compelling reasons Google paid for lunch every day.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abby Allen

Abby Allen

46 Followers

Abby Allen is a user-focused product manager, engineer, entrepreneur, and mom based in Minneapolis, MN.