I had an interesting conversation with a colleague this week in one of those only-happens-in-person-serendipitous-conversations as I visited our Menlo Park office for the first time. She asked me about my background and how I got into community work. After I gave the standard resume rundown, we started talking philosophically about how I think about building developer experiences - especially in relation to my change management background. Here's the net of that conversation, which I hope will help as many of you step into developer communities, developer relations, and developer experience for the first time.
What is ADKAR?
The Prosci change management framework is called ADKAR, which is an acronym for the different stages of need a person experiences when navigating a change in their lives. This change could be work or life-related. This change could be mandated or discretionary. One thing I learned as I went through the Prosci certification course was that regardless of the change, everyone goes through every stage of this process, but the point of greatest resistance to the change is different for every person and every scenario. Here are the stages:
(A)wareness - Does this person know about the change? Do they know what is changing and when? Do they know what they need to do to make the change and how it's going to impact them?
(D)esire - Does this person want to make this change? Will this make their lives easier or harder? Do they understand why the change is necessary or beneficial?
(K)nowledge - Does this person have the knowledge of how to make this change? Do they have the information they need to successfully complete the change?
(A)bility - Is this person actively enabled to make this change? Do they have the autonomy to do so on their own or do they need permissions, tools, access, or something else to enable them to make this change? Do they know how to get those things? Are they accessible?
(R)einforcement - What is going to help this change stick? How can we help them stick with this new habit, tool, process, etc.? There is both positive (rewards) and negative (consequences) reinforcement and it can come from many places. The sources will vary depending on the situation (could be your boss, your peers, your family, the government, etc.).
So, how do we apply this framework to building a holistic developer experience?
Well, first let's start with the goal. For most DX teams, the goal is to grow adoption of your tool or product. For developers, this means creating the lowest friction experience at each of these journey points. If we reposition the framework around product adoption, the phases break down more like this:
(A)wareness - Do they know this thing exists?
(D)esire to use it - How does this make their lives easier? Why would they want to use this thing? Who do they trust to make recommendations on tools
(K)nowledge - How do they use this thing? What skills and background knowledge do they need to have to be successful at implementing this? How steep is the learning curve and are you going to help them along the way?
(A)bility - Is there a safe, low-friction way to test this tool? What access do they need to their company's systems to get a real test? Do they have to use production data or is there a full sandbox that they can use to see this tool in action? What kind of infrastructure is required to support this? Who will they need to get approvals from?
(R)einforcement - How do you ensure that this tool becomes a critical component of this developer's every day routine?
In most companies, the responsibility for addressing the needs of the developer at each of these stages of adoption lie across multiple teams, including developer or product marketing (awareness, desire), developer education or advocacy (knowledge, ability), and customer success, community, and even product (reinforcement).
In the next few posts, I'll cover some common tactics for addressing each of these questions for achieving product adoption with developers.
Top comments (0)