Set Adoption Goals Set adoption goals. If you want to improve the AppDev experience, instead of a goal like “Tilt is available to AppDev” it’s best to set a goal like “X Tilt adoption by AppDev”. Framing goals like this can be risky and scary because you can’t achieve them alone: even if you write perfect code, you need others to change what they do. It’s worth doing this because: Adoption matters. A tool isn’t useful until it’s used. You probably want to improve your teammates’ experience and you can only do that once they adopt Tilt. Adoption teaches. As more people bring their experience to bear, you’ll find more ways to improve the experience. Adoption reinforces. As you prove the impact and can communicate how much people rely on it, it’s easier to convince management to invest more in DevEx with more headcount and promotions. Every DevEx engineer wants to help others. This advice isn’t to get to your change your your motivation but to help you change the framing of your work so it aligns with that motivation. Every other page on this site describes a tactic to help you hit adoption goals. How to know if a goal is an adoption goal An adoption goal is specific and measurable. If your goal is to get “my team regularly using Tilt”, it isn’t an adoption goal. You haven’t yet specified who your team is, and what regularlity means. How to measure adoption Establish an adoption metric and measure it. Your tooling should ideally automate tracking of adoption itself. For Tilt, we suggest using Active Hours. Why people don’t set adoption goals People often don’t set adoption goals because they avoid discussing adoption objectively at all. People think that rolling out a dev tool is a simple process, and once you get broad adoption, it will be obvious since everyone is praising it’s utility. Rolling out a dev tool takes time and intentionality. You likely won’t get it right the first time around. So it’s important to set adoption goals up front, setting expectations with your stakeholders and even yourself. People may procrastinate setting adoption goals. The thinking is that they will start rolling out a dev tool, and “figure out the specifics” later on, including adoption. Adoption should not be hard to track and for people to understand. Find a metric that is simple, and don’t let difficulty hinder yourself from establishing adoption goals. People may not want to commit to an adoption metric. They may be afraid it would mis-represent or mis-characterize usage and the value of the dev tool. You can iterate on your adoption metric. It’s better to have some tracked metric (even if flawed) with a goal, than to not have any metric at all. If the metric and adoption goals are not serving you, then you can change them. Make them work for you.