As you read in the previous post, we shed some light on what we were (and weren’t) doing with some simple Clarity mechanisms with regards to planning our software development. Now we needed to make sure everyone knew who should be doing what – a.k.a. Control.
We started with a new roadmap governance process. We knew that if we wanted to scale the organization we had to fundamentally rationalize the “roadmap committee”. To that end we developed the following decision flow chart:
Though it appears complex, it’s built around a single principle: push as many decisions to the teams as possible. The “roadmap committee” would be responsible for major strategy and funding decisions and for monitoring progress; the teams would execute under the broad guidance from the committee.
This shift to distributed control was fundamental to our later growth and success but the truth is that it took the better part of a year until we “got it right-ish”. It was an iterative process of building trust on all sides – management had to trust the teams to make good decisions, the teams had to trust management to provide clear guidance and hold to it, and the stakeholders had to trust both. But it was worth it.
Most importantly, the teams began to “own” their mission which changed everything.
The Roadmap Committee has long since been replaced with other more focussed and lighter-weight mechanisms, but the principles still hold true – executive management sets the goals, allocates resources and provides experience and mentoring; the teams decide how to achieve the goals and execute. We continue to explore different organizations and alignments to optimize our software development and delivery and we assume we’ll continue to experiment as we grow and our missions changes.
Another major step we took that impacted both control and clarity was to align our teams into Value Streams. In our effort to improve how we applied Lean and Agile principles at the team and group levels, we decided to adopt best principles from the Scaled Agile Framework (SAFe) for software development at the enterprise level. SAFe teams are built around “Programs” or “Value Streams” that allowed teams to focus on a specific portion of the mission and operate as independently as possible. We deviated quite a bit from pure SAFe and formed three streams around our user facing efforts, our business systems and our operations initiatives. Never-the-less the benefits were immediate as we reduced “prioritization hell” which is what I call the often fruitless act of trying to compare a revenue generating topic with, for example, a cost savings or security topic.
Key takeaway: it’s impossible to both scale and maintain central control. Effective scaling requires creating semi-autonomous, fully-capable teams organized to be relatively independent and provided with the clarity needed to tackle their mission. This can be a tough step, especially in organizations with a long history of central control, but it’s a step that must be taken. (FWIW I’ve seen the opposite and it’s not pretty.)
So now we knew what we were doing and who should be doing what. We were getting a lot closer, but we had one more big step…