Hey there,
To believe you can build a platform and “they shall come” is as naive as building a website for mechanical keyboards and hoping somebody will buy. They will not. Is that because your platform sucks? Maybe. But assume you’re a platform wizard and magically created the world's best platform (congratulations btw, big achievement, look at you!), you would still see no fast adoption. Why? Because nobody likes change, the reality is they don’t care about your automobile, they like their horses. We always think “they are engineers, they'll be receptive to change” but guess what: disruptors dislike to be disrupted.
Platform Engineering is a socio-technical problem (hey James) and even if you get through the 50% fun tech bit, the 50% socio stuff will still require a strategy. And this is where BUTD comes into play. BUTD is a completely useless acronym that I don’t even know if it exists. But it stands for something you should consider tattooing on your forehead because it’s so damn important: Bottom-Up-Top-Down. And before you think this is some crazy new move in the bedroom, famous in Berlin's clubbing scene, I can relieve you: it’s not. It describes in my personal opinion the perfect approach to managing platform adoption.
If you plan adoption, do it as follows: first “go bottom up” means you should start at the developer and user level to build your first fans. Don’t go top down (executives down). Why? First, this backfires, and you need allies on the ground. To build those allies go sloooooow. Single out one team, your best case a slightly more senior team that has to do something for the first time (like onboarding an app to K8s). Senior people are amazing, because they know what they don’t know. If you help them and laser focus on their app to optimally support your platform you can win fans. And fans are what you want. Napoleon once said, “10 people that speak are more powerful than 10,000 that are silent”. Create realities. Make sure this team uses your platform every single day and you can prove in metrics that things turn out to the better (check the upcoming course that will cover measurements!);
You need to have created realities. It’s easy to fight dreams, it’s hard to fight reality (at least long term).
Anyhow, let’s say you got it. Time to swap the motion. Don’t try your luck with the next 10 teams, it takes too long. Now you want to go Top-Down. Take your first team, take your measurements, go to your management. And now make a compelling case for why this reality should be more people’s reality. Get them to buy into a sticks and carrots strategy to make it either really nice to be on or really ugly to be off the platform. Which route you take depends on a.) your culture and b.) your security posture (which is the inverse of your culture btw.). Here are some examples for carrots:
- If you use the platform, you will not be on call and not liable
- If you use the platform any request to ops will be prioritized
- If you use the platform you will get an extra vacation day
- If you use the platform you will get swag
- If you use the platform you get a badge
And here are some for sticks:
- If you do not use the platform you are on call, and liable for what breaks
- Requests will be dealt with last
- Fine if you don’t use the platform in dev and staging, but it’s mandatory in production
Get management to publicly announce this. And yes, I’m asking for a lot and it doesn’t need to be on a company wide level yet (in fact it will not, that’s naive) but totally fine if this for a smaller group first. Don’t be afraid, your management has material interest to see your initiative be successful.
And with that: BUTD!
And if you’re unsure of how to execute on this, I think the upcoming platform engineering course will do a fantastic job of walking through this process.
With Love from Las Vegas
Kaspar
