How do you go about fixing something that requires you to change almost everything you do? As described in part 1, this was the situation we faced at Bonial in late 2014 when it came to the governance and execution of our product development roadmap.
Rather than re-inventing the wheel, we took advantage of proven play books – one for organization change and one for enterprise agile. On the organizational side, we knew that the “top down, centralized control” model was already strained and would not scale. So we leveraged elements from the (fantastic) book “Turn this Ship Around!” by Capt. David Marquett, which describes one organization’s journey from a top-down leadership structure to a “leader-leader” structure with distributed ownership and control. Bonial would have to undergo a similar transformation – we needed everyone to be engaged and feeling ownership if we were to realize rapid transformation and scale.
In the book, the author presents a couple dozen excellent leadership mechanisms and groups them under three high-level categories – Clarity, Control, and Competence. In the interest of brevity, I’ll describe just a few of the things we did to improve in these categories. (I’ll also break them up over several posts.)
Starting with clarity, we began with the simplest exercise possible: we documented all of the work-in-progress on one list. Absurdly basic yet profound. We created the first draft by literally going from team to team and asking them what projects were in progress and putting them in a Google Sheet. (Why this format? Because normalizing and adapting the existing tracking tools (Jira, Trello) would have taken far too long and wasted the team’s time and energy. Also, Google Sheets allow for simultaneous editing which is critical for collaboration.) To make this relevant for business stakeholders, we then dropped the small “story” and “task” level items and broke down the “saga” level items so that the resulting list was at a meaningful “epic” or “project” level.
Here’s a snap of an archived copy of the first version:
This exercise had several immediate impacts. First, it showed our stakeholders that the engineering team was actually working on a quite a few projects and began to restore some confidence in the product development function. Second, it shed light on all the projects and prompted a number of valid and constructive questions as to priorities and business justifications for the projects. This in turn led directly to our decision to do more formal and intentional planning: we wanted to ensure that our engineering resources were “doing the right things,” not just “doing things right.”
Over time this simple Google Sheet has grown to be the primary tool for viewing and communicating the current quarter’s roadmap development. We populate the sheet with the output of each quarter’s planning exercise (more on that to follow). Twice a week we review the status of all items (red, yellow, green) and discuss as a team what we can do to adjust if needed. The same spreadsheet is publicly available to all stakeholders for full transparency. We’ve considered several times moving to more sophisticated (and expensive) tools but each time we decided that the Google Sheets does everything we need.
Key takeaway: it’s hard to plan if you don’t know what you’re already doing. Take the time to get clarity on what’s happening, tune it to the right granularity, and ensure there’s full transparency.
In the next post I’ll talk about how we approach mechanisms for control.