One of the things I’ve learned during my career is that frameworks can be your friend – leaning on them when you need them so they can help steer you in the right direction.
In addition to the support aspect – I like frameworks so much because they can be applied to different situations. For example, consider the following statement…
If you’re not re-evaluating and re-working your decision making framework you’re likely trying to solve a set of problems that will persist because of your framework.
It’s pretty wordy, but if you give it a good read you’ll see that it’s akin to the quote often misattributed to Einstein regarding insanity.
Insanity is doing the same thing, over and over again, and expecting different results. – likely not Albert Einstein
Making decisions (aka problem solving) is simple when you know there’s a problem to be solved and the solution is clear. Things become more complex when you’re not sure the challenge you’re faced with is the root of a problem, or a symptom of something greater.
Root-Cause vs Symptom identification is a problem as old as time. I’m not sure about medicine but in management, popular literature says that if you ask “Why?” at least five times, you’ll be pretty darn close to the root of the problem.
Here’s a snapshot of how that’s applied.
A Head of Innovation (whatever that might mean in your org) might come to the conclusion that their team isn’t innovating fast enough (not good for a Head of Innovation). Having done some reading, the Head of Innovation understands that Deployment Frequency is one keys of Google’s Four Keys Project.
From here on out let’s call the Head of Innovation by something shorter – Pat.
Pat (the Head of Innovation) might be thinking that Deployment Frequency (we capitalized it because they made it a KPI) needs to improve. Pat may look at the Deployment Frequency needing to improve as “the Deployment Frequency is too low for what I’m spending.” Uh oh. Pat didn’t ask the Five Whys, and Pat might not necessarily know what a reasonable Deployment Frequency would be for a team with its history, its talents capabilities, and the norms – both implied and explicit – that exist inside the organization.
Is a low Deployment Frequency the root cause of not being able to innovate, or is the low number a symptom of other, larger problems within Pat’s organization. If you compare this to the Five Whys example from Wikipedia, we’re at the “Vehicle will not start” part of the problem. This is when we start asking Why? We typically get some really interesting responses and as a result complexity tends to grow – but it needs to in order to get closer to the root cause.
Danger. This is starting to sound like a huge organizational change just to hit one KPI. It doesn’t have to be.
Enter the Innovation Framework
We’ve figured out how to introduce and manage this kind of work and have seen the steps repeat enough times that we build a framework around it. It’s a framework that’s designed to help sell the value of innovation to folks that work at the level that Pat works at.
What we’ve observed is that recommendations that Pat finds valuable often don’t provide substantive enough opinions to be easily leveraged by Pat’s teams. We like to call that a “Tactically Weak Strategy”. Our framework takes this into account and we deliver to the level of detail that the teams dealing with the technology need.
Pat’s team is identified as one of the following, but not both:
- Pat’s team knows how to improve Deployment Frequency
- Pat’s team doesn’t know how to improve Deployment Frequency
We deal with teams that manage KPIs like Deployment Frequency and we often find out that the KPI was crafted without much team input or that the KPI isn’t reflective of the current setting.
Not being reflective of the current setting means “Things changed, but the KPI didn’t”. Perhaps more importantly, the things that kept the KPI in check are now either obsolete, underperforming, or are undermanaged.
If Pat’s team knows how to improve the Deployment Frequency but hasn’t done so, we help them articulate what training, systems, processes need to ramp to support moving the KPI in the right direction.
If Pat’s team doesn’t know how to improve the Deployment Frequency we have a new set of challenges, but it’s ok – we are covered by the framework! In this case we’d start with informal architectural conversations to determine what a future state could look like. Our recommendations and next steps are based on the team’s awareness of current trends and their capability to take advantage of them inside Pat’s organization. For example we’d never recommend Cloud Run to a team that only manages VMs today – we’d put a plan together to get them to a point where serverless is an option, but not a requirement.
Ok you get it – we have a framework.
Framework for Innovation
At a very high-level – our framework is about mapping where you are to where you want to be.
- Understand Current State: We need to know not just where you’re at, but why you’re here.
- Understand Desired State: We ask “What does good look like? What does great look like?” and go from there.
- Create the Roadmap: How do we get from Current State to Desired State? Our roadmaps consist of a set of changes that take between a week or two to put into place (think Sprint)
- Roadmap Workbook Execution: We can go as granular as creating tickets in JIRA and managing the epics ourselves, or we can observe and lean in where risk presents itself.
As you can probably tell, our involvement can vary based on where Innovation has met barriers in the past. Pats in the past have kept us at the 10,000ft level, and some other Pats have us as engaged members of their own teams, helping them navigate the never ending Sea of Change.
Keep on the lookout for blogs from the Arctiq team for more granular discussion around some of these topics.