How we Plan at Bonial (part 2: clarity)

Clarity

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:

Screenshot of first Bonial Roadmap on Google Sheets

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. 

How We Plan at Bonial (Part 1: the early days)

Today is the first day of our quarterly planning ritual here at Bonial.  As I write this the teams are huddled away passionately discussing, digesting, challenging, and estimating their candidate work items.  We have over a hundred people from 25 different countries and multiple offices working through dozens of epics.  By tomorrow we’ll have a solid plan agreed upon by the engineers, designers, testers, data scientists, operations specialists and product managers as well as their stakeholders.  

It wasn’t always like this.

When I arrived at Bonial a couple of years ago, there was no documented roadmap or cohesive prioritization process.  The planning horizon ranged from intra-day for emergencies to a couple of weeks for most other items.  No-one had a clear understanding of what we were working on and why.  The stakeholders didn’t trust engineering and everyone was unhappy.

Getting from there to here hasn’t been easy.  Over the next few posts I’ll walk you through how we got to where we are today.  

But to understand the journey we have to start at the beginning-ish…

In 2014, Bonial was a mature startup with seven or eight years under its belt.  We had a very successful mobile and web app being used in a dozen or so countries.  The product development crew was organized into four scrum teams, an ops team and a design team and was responsible for developing all of the user facing systems as well as the critical business systems.  All-in-all, there were 40-50 people working together in product development.

Unfortunately the team was less effective than it could and should have been, in large part due to lack of clarity and governance.  For starters, not only was there a lack of a coherent roadmap, there wasn’t even any clear record of what work was currently being executed.  We had tickets in Jira scattered across a dozen or more “projects,” Trello boards, stickies on blackboards, and whole lot of ideas in people’s heads, but there was no one place a stakeholder could go and get a simple answer to the question: “what is the status of my project?”

What roadmap planning was done happened in a bi-weekly session called the “roadmap committee.”  This was a group of senior managers from the extended product development organization and stakeholders who reviewed development progress and made decisions on new initiatives.  I’m being nice when I say that it wasn’t much fun.  The selection of initiatives being governed was somewhat arbitrary and the value provided by the committee was questionable.  We often hashed over the same questions over and over again.  Unfortunately it was the only vehicle in place to provide some level of two-way communications regarding roadmap and status.

The end result was that no-one was happy.  The stakeholders and customers felt like their needs were ignored and that, when their projects were accepted, delivery was too slow.  The engineers felt like they were in a blender of arbitrary and incoherent requirements over which they felt no sense of ownership.  And the product management team was stuck in the middle, working to adjust to the latest change and managing both unhappy stakeholders and engineers both.  The end result was perceived and real low performance and sense that we were set up to fail.

So we decided to change this; the solution would require a great deal of work in many areas across the people/process/technology spectrums.  It all came together, though, in planning.  Stay tuned for part 2. 

The Micro-service Conundrum

 

Micro-services have been the rage in software circles over the past couple of years.  A natural evolution of service oriented architectures (SOA), and popularized by successful implementations at companies like Spotify, Soundcloud and many others, micro-services have become the “must have gadget this holiday season”: if you aren’t doing them, you must be doing something wrong.  

But is that true?  As much as people (and especially engineers) love black and white, the answer here is a firm “maybe.”  Here are some of the positives and negatives from one CTO’s perspective.

On the plus side, micro-service architectures provide an excellent canvas for rapid development and continuous integration.  Hard dependencies are minimized, business logic is localized, and the resulting services are typically cloud ready.  Developers tend to like micro-services because it allows for a great deal of independence.  It’s hard to understate the potential pain savings and optimizations – people, process and technology – that can be driven by moving to this type of architecture.

But it doesn’t come for free.  For starters, you’ll likely have a lot more moving pieces in terms of individual components and running executables.  A few weeks ago I wrote a post on the architectural heuristic: Simplify Simplify Simplify in which I posited that simple is better when it comes to minimizing TCO.  In that vein, one must ask if micro-services follow the rule.  Yes, each individual service itself is simpler than a bloated monolith as a result of the small size and tight boundaries.  But the total business logic in your enterprise hasn’t changed, and now you may have hundreds or thousands of additional code modules to manage and executables to orchestrate.  The good news is that cloud hosting providers like AWS provide an ever increasing set of tools to help with managing micro-service architectures (e.g. Lambda, Container Services), but it still requires a good deal of cultural and process change.

Another side effect of the proliferation of executables is potential increase in cost – many hosting providers and software vendors (e.g. APM providers) still price based on number of processes or agents.  If you take the same processing load and 10X the number of running processes, you might find yourself in a world of hurt pretty quickly.

Finally, in moving to micro-services, you’ll find yourself needing to address a host of new challenges that you may not have had to previously – service discovery, versioning, transactions and eventual consistency, event tracing, security, etc.  At a minimum, the upside benefits you’ll realize will be offset by developing competency and code to solve those new challenges.

So, what does this mean for the typical company.  If you have applications that are bloated monoliths, those are fantastic candidates for breaking down into smaller components or micro-services.  On the other hand, if you have a reasonably well architected system with decent boundaries in place already, I’d carefully weight the cost-benefits – maybe run a few trials projects to get a better sense of how it would fit into your platform.  Just realize that in many ways you’re “squeezing the balloon” – trading one set of problems for another.  So long as you’re happier with the new problems (and the corresponding benefits), you win.

In closing, whether you move to micro-services or not, I do think there are great lessons to be learned from applying the discipline required by micro-services – namely, enforcing clear boundaries around business logic and using “API thinking” to service a variety of clients.  I wonder if there isn’t a compromise to be had in which one uses the principles for developing and organizing the code, but you still deploy in a more constrained manner – “Code Micro, Deploy Macro.”  But that’s a discussion for another time. 

Getting Extreme

 

In my previous post on Extreme Ownership I shared that I wished more technology companies would take the principles more seriously.  Over the last month my wish was granted right here at my company.  

Our executive team had an offsite strategy meeting last week, and one of the coolest things we did was take a deep dive into Extreme Ownership.  In the weeks leading up to the summit each member of the team – managing directors, senior execs and CxOs – read Extreme Ownership and prepared homework consisting of an introspective look into how they’d individually violated or been challenged by the principles as well as which principles we wanted to focus on bringing more into the company.

We discussed our experiences over dinner in a very candid fashion.  Each person shared one or two “fails” that tracked back to the principles, or challenges that could better have been solved by better applying the principles.  It’s not often that very skilled and accomplished senior executives are willing to admit to failures in front of their peers, so I think that says a lot about the character of those around the table as well as their commitment to Extreme Ownership.

Some of the maxims that resonated strongly and were repeatedly mentioned:

  • “There are no bad boats, only bad leaders” – the core idea here is that you have to look first at the immediate leader before blaming the team itself for underperformance.
  • “It’s not what you preach, it’s what you tolerate” – how true.  How brutal true.
  • “Check the ego” – as the authors note, “egos cloud and disrupt everything.”  If you don’t have the discipline to keep your ego in check you don’t deserve the trust and confidence of the people you lead.
  • “They don’t want me to fail” – how many times do we assume that a boss or outside organization is to purposely make our lives harder when they put an obstacle in our way?  Probably quite a bit.  And how often is that true?  Likely very seldom.  If we’d drop the assumption of hostile intent and the resulting “us vs them” attitude, business and life would be a lot easier.

One of the longer and more challenging discussions was around how to move to “Decentralized Command” – let’s face it, it’s not easy to step back and let others take charge of executing a mission that you’re accountable for.  But it must be done to scale the organization and to develop the next generation of leaders.  And guess what – sometime they will fail, and you’ll still own the result.  Our COO made a key point here – while failure in the SEALs often results in injury or death, a business fail will have much, much lighter consequences, so we need to take an objective look at the real risk and balance with the cost of not decentralizing. 

As a team we decided on three of the principles we’d like to focus on for the entire organization and each of us was assigned a buddy from within the group to challenge us grow in these areas.  

I was really energized by this process and I’d recommend it to any team that wants to move in this direction.  In hindsight, I recognize that our company already has a pretty solid accountable culture and a general lack of fear, which probably made this a lot easier; some teams will have to overcome much bigger culture and ego challenges.  Which, in the end, means it’s even more vital.