Hi, my name is Ryan Clair and I like change.
I’m the guy who comes in and spews out awesome things that are all the rage these days. You could use a buzzword bingo sheet and within a few minutes you’d be yelling BINGO!
Why do I do this? Part of the reason is because I like shiny new things. But the bigger reason is that I hate waste. If I could chose the biggest pet-peeve of mine, it’s that. Waste always exists (so really, I’m doomed for the rest of my life to be peeved), however, if I could optimize toil out of existence, I would. To give you a glimpse into my psyche: I was the freak who would immediately start all over in RPG games when I realized I’d made a mistake with my character’s stat/skill allocation.
So yes, I like change.
Change is hard, though, because we’re all selfish creatures and if <insert_change> doesn’t align to a benefit, why would we accept it? You have to sell the change, and frame it in a way that people can see the merits of it. To be excited for it. And that, my friends, is hard. If you don’t do this, there will be seeds of doubt sowed. These seeds can become the poison pill for said change. Anyone who tells you humans are inherently resistant to change is lying to you. They just haven’t learned how to frame it properly.
But this post isn’t about selling it. This post is about ensuring the change you’re proposing is right for you and your <team/organization/company>. Because let’s be real, not all change is good. Knowing what’s good and what’s not can be difficult. Sometimes even impossible — leading you to experiment with it, and accepting the fact that you might make a mistake.
This is my (working in progress) framework for change. I use this when advising my customers on questions around “is this right for me?” when adopting a new technology or process. I hope you get as much value out of it as I have.
Without further ado…
The Guiding Light
Let’s start with the one core question to this framework, that should be repeated like a mantra: “Is the juice worth the squeeze?”. For those of you who aren’t familiar with this expression, it’s a clever way of saying “Is the end result worth the effort to achieve it?”.
You should be pragmatic with your changes. Don’t change just to change. That’s asking for a world of hurt.
The easiest way of knowing this is tying the benefit(s) back to the business in a measurable way. Let’s face it, the reason technology exists in a company is to support the business. And the business will only invest into something that meets at least one of three fundamental needs:
- Will it make me more money?
- Will it make me money cheaper?
- Will it reduce my risk?
The first two equates to profits, and the last one ensures those profits continue.
Time to Value
This is a great transition to another key idea. I’m a big fan of small iterative changes. Big Bangs and Boil-the-Ocean-with-a-Nuke has rarely (ever?) worked. Making changes in small incremental steps has a number of benefits:
- You give instant gratification to the business —giving value back quickly creates a quick win for you to build upon a marketing campaign of more changes. Longer it takes to give value, the higher the chance of failure.
- Self-funding milestones — any change typically requires $. If at all possible, try to show $ saved (Opex/Capex) from the change, and using those savings to reinvest back into your organization for more changes. This turns into a positive, force multiplying, feedback loop. And frankly, an easy sell.
Obviously, this means finding low hanging fruit to tackle first. You want easy wins to build up your own credibility. Using the KISS philosophy (Keep It Simple Stupid) can certainly help. The more complex a system is, the more chances of failure to appear in the most gloriously epic way.
There’s ALWAYS Tradeoffs
I’m not a fan of absolutes, but this one I’m pretty confident in saying. There is no such thing as a decision that doesn’t have a trade-off. When I hear a new buzzword, technology or even a process, the first thing I do is dig into the trade-offs. My post on Metaparticle is a good example of this.
You can’t just focus on the benefits, otherwise you’ll be blindsided later (either by the tradeoff itself, or the potential of the tradeoff will be used against you by someone resistant to the change).
I really enjoyed this article on hype driven development, it touches on this very topic. Just because something worked wonderfully for one organization, doesn’t mean it will work for yours. Evaluating the trade-off(s) is a good litmus test to this.
So go in eyes wide open and have an appropriate response/plan to the tradeoff(s). An informed decision is the best decision you can ever make, in my humble opinion. Having a friendly debate can be extremely valuable, and I highly encourage it.
Along those lines, I’m reminded of Marc Anderson’s saying:
Have strong opinions, loosely held
Be willing to change your own mind, if someone comes along with a better argument.
There is, of course, the danger of getting stuck in analysis paralysis, so also know the cost of not changing. Like I’d said before, every decision has a trade-off, including not making a decision. Yes, that means it can be a bit scary, and you have to walk a fine line at times, but sometimes you just have to feel the fear and do it 🙃.
Just please, please, PLEASE, do it with a back-out plan. Assume failure will happen. If there is no easy back-out plan, I’d strongly suggest reevaluating the situation. Expect the best, but prepare for the worst.
Measure Everything and Feedback Loops
This one should be obvious, but before you make a change, if possible, get a baseline. I know, this can be difficult at times, but try. Also, make sure you’re measuring a metric that actually makes sense (read: The Guiding Light). Lastly, make sure you have a system in place to get feedback from the stakeholders who are impacted by the change, before making the change.
It should become a fairly binary decision after you make the change at this point: did the change have a positive or negative impact? Rinse and repeat.
Lean Thinking and The 5 Why’s
That kinda sounds like a band name, doesn’t it?
Lean Thinking. For those who haven’t heard of Lean, the principles originated from Toyota, and can be traced back all the way to the 1930s. This site is a pretty good one, if you want a history lesson. The reason why I bring Lean up is that I like the five principles that come with it. They can be a great tool to assess your current state and find areas that are candidates for change:
- Specify the value desired by the customer
- Identify the value stream for each product providing that value and challenge all of the wasted steps currently necessary to provide it
- Make the product flow continuously through the remaining value-added steps
- Introduce pull between all steps where continuous flow is possible
- Manage toward perfection so that the number of steps and the amount of time and information needed to serve the customer continually falls
Before you say, “what does that have to do with…”
Squint your eyes and imagine this:
Business <-> Developers <-> Operations
As an assembly line (from Idea to Production), then the above principles start to make sense. As a guy who hates waste, this speaks to me at a spiritual level.
Another somewhat related concept is the 5 Why’s technique. This can be used in both root cause as well as evaluating an existing process/technology. It’s another great tool for challenging the current state and is stupid simple to understand. You ask “Why” five times.
Here’s an example I stole from that wiki link:
- Why? — The battery is dead. (First why)
- Why? — The alternator is not functioning. (Second why)
- Why? — The alternator belt has broken. (Third why)
- Why? — The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
- Why? — The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
Not only do you get to the reason why <something> exists, but it gives you the context to the reason why the decision was made in the first place. Is the context still applicable? If so, is there a better way of doing it?
Sponsorship and Blameless Postmortems
Last but certainly not least, we’ll talk about arguably the most crucial component of this framework: Air Coverage.
Many of us are risk adverse. Especially when you’re talking about someone’s livelihood. Very few people I know would knowingly do something significantly different (which works today) without having the support of their boss. Support can be provided in two ways, and in a perfect world you’d want them both.
The first is in breaking down potential roadblocks across teams/organizations. It’s easy to implement change in your direct sphere of influence, but it can be significantly harder to make any changes that touch other people/teams. Having support from upper management can grease the skids.
Don’t get me wrong, you should always lead with the carrot, but it certainly doesn’t hurt when people know there’s a big stick behind your back. Bigger the stick (read: Executive Sponsorship), the better.
The second way of helping is adopting a blameless postmortem process. I’d argue this is the best kind of air coverage you could possibly give. We all make mistakes, and mistakes are bound to occur when you start to make changes to the norm. While Etsy (who’d mainstreamed this idea) has a great post on this, I highly recommend this page out of the SRE book. Some great tidbits in there.
I’ll just end this with a quick thank you for sticking with me to the end. I hope you took away at least one valuable thing from my little framework.
Sticking to my own advice of “strong opinions, loosely held”, I’d greatly appreciate any feedback — good and bad — in the comments below.
I always love a good logical (oh please logical) debate. 😀