Climbing The Product Development Communication Mountain
By Abby Sorensen, Editor
I recently talked to an iOS developer who works for a software company that sold this past year for more than $400 million. That kind of cash isn’t dropped on a software company unless its product engineering is ahead of the curve. That’s why I was surprised to learn the different development teams weren’t always in synch. For example, the web developers will push out a product but the iOS team won’t know about it, so they aren’t able to support the new features until the next release. By that next release the iOS team is perpetually in catch up mode, and the vicious cycle continues.
Sound familiar? Shipping code on time and on the same schedule isn’t as easy as it sounds. Sometimes product development miscommunication can’t be solved by creating an extra Slack channel or emailing timetables to the entire engineering team. Instead it takes a process to manage the product development process, such as Quantitative Software Management’s five laws for successful product development:
- Every software project has a minimum development time.
- Schedule and cost do not trade off evenly.
- Projects grow.
- Small teams are better.
- Allow sufficient time and effort for analysis and design.
You can read more details and advice for following these laws in the October 2017 Software Executive Magazine article “5 Software Laws For Smooth Product Development” by Larry Putnam Jr. and Don Beckett.
Even if you know and abide by the five laws, and even if your developers are on the same page, getting a project from the whiteboard all the way to your customers still isn’t easy.
At the Business Of Software Conference in September 2017, Chris Savage offered software companies advice for getting teams on the same schedule. Savage is the CEO and co-founder of Wistia, a video software editing/hosting company based in Boston with more than 100 employees. When the company scaled from 20 to 100 employees, it faced a mountain of communication challenges. Engineers would release a product, but marketing wasn’t ready to market it, and support wasn’t ready to support it. Wisitia changed its entire internal operating system by implementing a mountain climbing metaphor to guide a five week project cycle, similar to how engineering teams work on a product roll out.
Every business unit within the company had its own climb to accomplish during those five weeks to ensure everyone was pulling in the same direction. Week one was spent at “basecamp,” where teams prepared for the “climb” by holding planning meetings, conducting retros, and forming teams. A basecamp is where climbers prepare for the next climb by monitoring weather, reviewing past climbs, learning from other climbers, letting off steam, and revisiting the overall climbing process. The next four weeks, the getting to the “summit” period, meant executing among those teams and preparing demos to track progress. Climbing to actual summits involves laying ropes, rigging ladders, acclimating to different elevations, dropping off oxygen for future climbs, and actually climbing.
When Wistia first rolled out this document about the new five-week project plan, employees pushed back. It felt like their entire workflow was being overhauled (it was), and like many employees at many companies, this change wasn’t welcomed with open arms. Savage admitted the tone of the mountaineering metaphor was off, and it was a mistake to not be adamant that new structure was meant to be a test. The company needed to first encourage teams to try the new operating system, not have it forced upon them. This concept of getting employee buy-in is applicable to any serious change, whether it’s adjusting your pricing model, overhauling your marketing strategy, or buckling down on spending during a tight quarter.
Savage was honest in admitting the company’s leadership team had a habit of trying to secretly solve big problems, and then being naïve when they presented their solution to the company. The right solution is often created by involving people from across the company to collaborate on challenges. In the case of the operating system change, Wistia rolled back the policy document and the leadership team focused on making communication less serious. To do this they pushed out updates and encouragement using videos with the founders’ mouths and voices overlaid on a photo of a famous mountain climber.
This metaphor works for Wistia and its culture (the company is full of outdoor enthusiasts, and it takes an annual ski trip). Since Wistia’s entire company is built around video, using videos to keep employees engaged with a new process was already part of the company’s DNA. Your company doesn’t need to use this climbing metaphor or flashy videos to get your team on the same page. Find your own metaphor and your own way to create employee buy-in before you overhaul a process or try to smooth out your current product development cycle. All software companies should start applying engineering practices to other non-technical business processes.