Hi, thank you for joining me to talk about adoption and deprecation and how to get everyone to use the internal developer platform. I'm Omar Kahani. I'm a staff engineer in the infogroup at SNC, where I lead platform teams. Building the internal developer platform before we dive in a bit about the infra group. We are three teams, but we're not doing any companywide ops, DevOps or on call for everything. We're building a paved path for other teams to lower cognitive load and make their day to day happier and simpler. As a result, if you want our solutions to be effective, we need the teams to adopt it. It can be as simple as a minor version of a helm chart, that provision postgres, or as complicated as changing the git brand strategy. Today, I want to show a framework with a set of practices that can make migration and adoption successfully, fast and without frustration. The framework is based on the technology adoption lifecycle, first presented in 1957 and then republished and generalized in tools and studies such as crossing the chess on the lifecycle describe how technology is adapted in the general population from zero to 100. The model splits the market into buckets, each with a different consumer behavior. Using the same process, we can segment the RND and have an adoption strategy for each group using the model. We can also provide a systematical way to show progress in the migration project. Breaking down the model, we will now discuss each segment and the tools and practices to apply to it. Also in each segment, we will identify the relevant teams cases on the criterias of the segments. That mapping might change over time as teams change their behavior. So do that exercise each time before you start a migration project. The first group is innovators, a small group of people who get excited about new technology because it's novel. People in this group are willing to pay the tax of using a product that is not polished, has bugs, and lack any necessary documentation for onboarding. As long as they will be the first to use it, they will use it. That willingness is a gift for us as we build new solutions because we need design partners to build with us that product. So usually we will collaborate with ones or two teams to test our assumptions and to test the product that we build as we build it. Using design partners, we will be able to build a more specific solution, one that will work later on. For innovators, we will look for teams that have application without risk or low risk. We don't want application that will impact customers if there is downtime or problems. We also need teams that have time and are willing to free time in their sprint for pairing with us and make the effort to use our tool so we know who they are, we know what to do with them. We are ready to move to the next group. The second group is the early adapters. This group still get excited about new technology, but they also need to get a real value. Although they are willing to have some bugs and figure out some things, they still need it to solve a real problem for them. It's an excellent group to test the product as is a moment before GA. It's also a great group to validate and write the onboarding guides that will help us support the majority. Inside R D we will look for teams that have trust and are willing to try things before they come GA. We also need teams with time because the onboarding is not trivial and there might be bugs that will require pairing time with us. There's a lot more to talk about early adoptions, but I want to talk about the next group first. The next group is the majority, and as the name suggests, it's most of the organization. In the model. It's about 68% of the population. The majority cares about their day to day work and the problems they have, and technology is only a way to solve those problems. Therefore, approaching the majority is completely different from the first two groups, not without a reason. Crossing the Chessam put a gap between the early adopters and the majority. From my experience, there are two main reasons for failure with this group. One is a product that doesn't solve a problem, but hopefully doing user research, working with design patterns and doing pocs, that's not the case. The second reason is that the migration is too difficult. Every product, technology, tool and practice that we use should provide us a value, but the value get lower by the effort it takes us to actually use that new tool. At the left corner we can see great products, but the effort to use them is so high that we wouldn't get any value from them. On the right side, we can see that the migration is so simple we can capture all the value of the product. Good product and low migration effort should be our goal. There are two practices that we use at Snyk to make that migration effort lower. The first is using self serve tools. In one case, we upgraded our internal deployment tools to have more options, but that required every application team to change their deployment configuration. That's a very high migration effort and we wanted to lower that, so we automatically opened PR for them, reducing the migration effort to a simple PR review and a simple click on the merge button in GitHub documentation can also lower that migration effort. Use the early adapters to make sure the guides and the docs are simple and clear for people without prior knowledge. We also usually task one of our teams members to follow the guide word by word. He is not allowed to do anything that is not strictly written in the guide so we can see where he gets struggled and how we can improve our documentation. The last group is the laggers. In the classic model they hate change. In the classic model this group hate change. They hate it so much they never do it unless they are forced inside the RND. Some teams must be the last to adopt, but it doesn't mean they hate change. There might be other reason for that. It might be that they have a production critical application, they can't suffer downtime and they don't want to take any unnecessary risk. So they prefer to wait and see the problems that other teams will have. They might have a legacy system, one that no one is familiar with. So in one of my previous companies we had those kind of legacy system which was super difficult to make any change. And anytime we wanted to change anything we had to group a lot of people inside a room and understand the legacy system and how it's deployed in order to make that change. Or they might need more time. So think about that team that is currently on the hook to deliver a very significant milestone to your company. They don't have time to mess with their deployment process, with the way that they provision cloud resources. They need things to work and without any change. So what can you do to make those team adopt your product? What is the best thing we can provide them? We can provide them knowledge just in time specific knowledge for their application about the migration effort. In other words, we can pair with them in that pairing session. We will be able to provide the necessary knowledge to make the migration effort as low as possible. While they can provide the specific application context. Together we can make that change easy and affordable. So to recap, we talked about four segments, the innovators, our design partners, the early adapters that will do pocs and test our documentation, the majority, both the early and the late, that will use our self serve tools and guidance to make that migration. And we talked about the laggers where we need empathy and pairing time with them to complete that migration project. We also talked about the majority and how they are a key group to our success. So now I want to talk about more tools and practices. Aiming to the majority, we will talk about two practices, trust and sticks. Trust is part of every buying decision we make. A while ago we bought a home coffee machine because we thought the coffee at home will be better than a coffee in the coffee shop. The first way to build trust is by celebrating our early adopters success and even using them to demo and explain the problem and the solution in their own words. So at Snyk there is A-R-D sprint demo which is an excellent platform for those kind of celebration. Find the best place to celebrate those in your company and in fact make it a rule. A PoC must end with as many people hearing about it. Speaking about early adoptions, let's go back and add another criteria. Early adoptions must represent as many use cases and groups as possible. Trust is established by people close to you with a similar use case, but trust is also established by people. You value their opinion. In every group, organization and community there are always individuals that can reach out and influence people's decision because people trust and value their opinion. In SNCC, those are group level staff engineers which can influence the group practices. In one of our first migration projects, we intended to replace the continuous delivery system. This was a fundamental change to an historical process inside SNCC. Not only that, but everyone inside the group was less than a year in the company and wasn't in the position to build trust with the whole organization. We had to use other people for that. So after identifying them, we engaged with them in a series of meetings where we presented our assumptions and shared the blueprints of the final process. It was even before design patterns, very early in the process, after sharing our thinking process and our results, we asked them, where do you see problems now? It didn't meant that we implemented everything that came up right away, but it helped us to prioritize and help us segment R and D. For example, we knew some teams can be early adopters because they have some special use cases that is not yet covered. Besides that, they had become ambassador for the majority. We saw that in slack threads where someone was suddenly saying that the infragroup is working to solving that specific problem and please engage with them. And when it came to the actual adoption, they were able to explain it and build trust. With all the r D so far we were friendly. We tried to do a natural adoptions, but sometimes sticks must be pulled. Sticks can be as simple as a support deadline. In four or six weeks we will stop support the old version, but support deadline need to be realistic. If the organization is working in two weeks prints you probably need to put four or six or even 80 weeks in advance to give teams the times to add it to the next prints. The other stick that can be used is getting high level manager support so they will instruct teams to create time for the migration. Use high level manager support. You don't want to force every change across the organization. You want to be able to create natural adoption and have lightweight sticks like the support deadline. Sticks are not excuse for not doing anything else. Trust, good product, self serve migration all must be used before sticks and in fact if you do them it will be even easier to use those sticks and get high level manager support and people will be less frustrated when you introduce any forcing mechanism. So to summarize, we talked about the technology adoptions cycle and how to segment our R D organization the different approaches for each segment. We talked about migration difficulty and how it affects the majority. We talked about trust and how to establish it. And finally we talked about sticks and forcing change. For anything else please reach out on Twitter. Thank you.