Win the 1st mile and the race. Making a developer process or tool stick
Recently I have had a number of conversations with leaders in engineerings organizations about their initiatives and how they see new tools and processes fitting into them. There are a lot of ideas they want to try out, and a list of problems that need solving. Projects, companies, and best practices aside, all people really want is a simple way to solve their problems. They wish it were as easy as import api_first or import agile@the_good_one.
As a community we need to face it: there’s a lot of hype about a lot of things. Cutting through the noise of case studies, fundraising announcements, Gartner reports, Twitter, etc is hard for everyone. If you search the internet for any problem your team is having, someone, somewhere is confidently promising to solve all your problems…. “Get started free!”
We all know the reality is not as clear cut. Just because there’s a tool that does X, does not mean it is adoptable by a team. Changing a team’s behavior is really hard and that is the main reason why new tools and process — however promising — fail.
A lot of investors tell founders to build tools that are easy to set up, that require little behavior change, and can scale rapidly. This is all fine, but if you’re not going to try to change how a team works, the impact you can expect is relatively low. This is also interesting to me because every CTO or Dir of Eng I’ve spoken to about using Optic to work API-first really wants to change their team’s behavior. Changing something fundamental about the way their team works is a feature not a bug, but they also know whatever they do needs to be adoptable.
The most impactful products and processes do change how a team works, but that’s where they finish, not where they start. They don’t tell teams to“change everything” so you can get “x benefits”.
Instead, using the product or adopting the process is part of what leads to the first change, which leads to the next, and the change after that. Over the course of several months you’ve climbed the maturity ladder and leveled up how you work. This happens when processes and tools make the “right” thing to do easier than the “wrong” thing to do, and support a team’s transformation one step at a time. They bring you from where you are today, to a world where the rules can be a little different.
So how can engineering leaders increase the odds of a new tool or process having a positive impact, and “sticking”. How can founders build products that help teams import good_idea ?
I’m a runner so I like racing metaphors. To change a team’s behavior with tools or process, you have to win the first mile, and the race.
What do I mean by that?
Well, if you’ve ever watched a distance race like a 5k 10k or half marathon, you know that the person who is leading after the first mile is rarely the person who wins the race. It’s a lot easier to go out fast and then burn yourself out, than to run a steady pace to victory.
Many trendy tools you hear or read about are like the runner who starts off fast, looks great the first few weeks, and then doesn’t deliver on the organization change or benefits you expected. When engineering leaders see “5 min setup” , “zero-config” and “one-click” they know a tool is adoptable, but it’s not alway clear how that tool can bring their team from how they’re working today, to how they will work tomorrow. There’s no such thing as a “5 min” team change.
These tools win the first mile, but lose the race.
There are also processes and tools that promise fundamental changes in how teams work — but it is going to take a lot of work to get there. Think microservices, working API-first, or event sourcing. The proponents of these initiatives can make compelling claims about how their approaches will bring about fundamental behaviors changes on the team, but their adoption can be summarized as “trust us, you’ll love it when you get there”. Sometimes (but certainly not all the time) you get to the promised land and find yourself with a new set of problems and tradeoffs. You’ve traded some problems for others, but haven’t changed the fundamentals.
Adopting these tools processes is a long haul, you might end up winning the race, but most people can’t make the journey. The total number of teams who benefit from ideas like this will be a small niche.
To change a team’s behavior with tools or process, you have to win the first mile, and the race.
The first step of the process or tooling must be easy to adopt. Adopting it must unlocks the next piece, and the piece after that. Each step empowers developers to take steps closer to a new way of working, and supports them on the journey.
If you want to change a team’s behavior you need to put quick wins up on the board (winning the first mile), and have a plan for how these processes and tools help make fundamental changes to how a team works over time.
That’s hard, and it requires constant attention. You can’t just set things into motion and walk away. These are not “deep tech” problems and they can’t be solved with features on the roadmap. They’re “deep people” problems, that require a thoughtful human approach from everyone involved.
To engineering leaders, I leave you with this. How can you make your initiatives easier for developers to adopt? What investments would you make?
To founders, I ask this. If you put behavior change back on the table, how you do it? What are the stages of maturity your product could help a team level up against?
To both groups — find each other, and make magic happen.
