I made three mistakes in the process of building an internal developer platform. While these mistakes were temporary if I could repeat the journey I would invest my time differently. You should skip reading this if you work at an organization that is demanding Kubernetes and a Platform-as-a-Service, has IT leadership that understands the value of cloud-native, and you are great at naming and marketing products. The three mistakes that I made were:
- Investing late in a user interface and branding
- Communicating the value to different audiences
- Stakeholder commitment to running on the platform
User Interface and branding
I avoided creating a user interface and self-service portal from the start. Once leadership approved spending time on this initiative I overinvested in research and planning. The hardest part of any project is starting and one danger in the enterprise is a lack of familiarity with doing speculative spike work. It was not until the project manager proposed a three-day “Start-up Weekend” exercise, similar to a hackathon, that unlocked the creativity we needed on the project. I continued to neglect the user interface completely. “The colors look like the Joker,” the project manager said after several weeks of me ignoring any frontend work. “Could we spend a Friday afternoon at the bar and just throw any colors at this with the team?” the project manager continued to gripe but I ignored the request. I asked marketing for design help but my request was too broad and they stipulated I figure out the developer interactions first. I ended up eyeing many other Platform-as-a-Service offerings on the market and started making mockups and color schemes based on designs I liked. A steady cadence of UI updates around the color scheme and displaying of project information drove more interest than parity of functionality such as application secrets and environment variables. If I did it all over again I would mix in more updates to the UI at the start and use those minimal updates to drive communication and marketing around the platform. Finally, we named our platform Dev.Lab (the dot is silent) and everyone responded to my announcement with congratulations and interest to use the platform and join our alpha testers even though the features from the previous week were not much different.
Communicating the value
Communication is hard. Under communicating is easy! Simply go about your day-to-day. Overcommunicating is much more work and it is still undesirable. You can communicate and explain each day and your audience may still not have time or interest in what you are covering. One theme on a podcast that resonated for me was a concept around the requirement for leaders to continue to repeat their vision even after it seems exhausting. I do not have a clear guide on how to communicate your vision to different stakeholders. Looking back I wish I knew what IT leadership wanted to know and hear about the platform. The best advice I can give is to write a vivid vision, try many different things and, see what sticks. Partners that resisted collaborating with me changed their mind after reading my narrative explaining their part in fostering the shared vision.
If you can track analytics of your writing do so and see what resonates and what does not. Over the past year, I have written four internal blogs, a lengthy business case for cloud-native, outlined what makes the legacy Windows platform deficient, explored in-depth other possible solutions aside from Kubernetes, and appeared on a podcast. These all played their part in driving this project in procuring staffing, establishing credibility, and simple marketing for adoption. One IT leader stated, “I finally connected the dots on what cloud-native means for us. Developers have left for our competitors because they thought we do not use the latest cloud-native technology.” For this leader, cloud-native is a key to retention. This platform-as-a-service demonstrates that we are experts and leaders in our field.
Platforms require a high bar for their implementation and stability is key. If you are able find a passionate team to use your platform early it will help reduce your project risk. I vaguely recollect Christian Tragesser mentioning in passing, ‘You need a customer using your platform because the last 90% of the 90% effort in building a compelling platform is the hardest’. I wish I had procured the alignment and buy-in from a team to champion and build on the early version of the platform. The risk/reward is challenging for any team. Early adopters are exposed to untold migrations, breaks, problems, and risks to their business projects. The benefit for the platform team could have been better prioritization of important work and better feedback on the platform. Due to this failing, I missed an opportunity for early evangelization of the platform and better feedback. What I ended up doing was trawling through source code myself and identifying existing projects that were easy migrations onto the platform and making deals to get them migrated. Everyone is afraid of stories of transformative technology projects that were canceled because of a big early failure but if reasonable expectations are set this should not be a concern. You imperil your project by targeting high difficulty high-value projects first. If you can share the story of early success you should do it! No matter the amount of value. The first will always be the hardest and after that, it is much easier. How do successful people become even more successful? They tell people they’re successful! It seems obvious and too easy but you need to tell people you are successful when you are. Use the method “Model. Document. Share” advocated by Will Larson.
Learn from my mistakes
- Make a user interface and name your product. Evolve it to build anticipation and interest
- Equip leaders with the value and why the current platform is insufficient
- Find a team to champion the Platform-as-a-Service and gain their commitment early