Managing three different engineering functions — Cloud Platforms, SRE, and Developer Experience — Crystal advocates understanding the operating model of the teams you are building within the company you're building it. That is, building both teams and systems informed by how the people and technology in workplaces interact. How do human factors interact with technical ones?
At Snyk, Crystal explains, she leads one of the only teams that has to serve both internal and external customers. Not only do they build deployment options for Snyk, i.e., single-tenant SaaS, multi-tenant SaaS, and on-prem, the team also provides "paved paths", or control planes, internally for platform and observability capabilities. To do this effectively, the team needs to be built to understand the business, technical and human factors involved in delivering to external customers as well as those motivating and helping internal customers.
Crystal Hirschorn, Director of Engineering - Infrastructure, SRE and Developer Experience at Snyk, shared some time with Ambassador Labs's Head of Developer Relations, Daniel Bryant, to talk about all things platform engineering and building control planes that “pave a path” for developers.
Here are some of the key takeaways from their conversation:
Platform engineering for growing teams requires a lot of perseverance and the ability to think in the long term with a clear vision in mind. You are playing the long game when you build a platform for developers, thinking both about what kind of control plane will work today and will still work in a few years when hundreds or even thousands of developers have joined your team.
"As I've gained more experience, I see the bigger picture: you have to think about the market that the company operates in, how mature it is, what it is trying to achieve in terms of business and technical goals. And by extension, how should the team be composed to serve those goals, for both internal and external customers?"
"You have to realize that things happen on different time horizons. You have to realize that you may not see results immediately. It takes a certain kind of person to want to work with platforms as well. Someone who can start to see the outlines of what the paved road will look like miles down the road. What does the road look like where you are and where you want to get to? What does the end state look like to know what you are working backwards from? How will we get there practically?”
Ultimately a platform team may be traveling from a "minimum viable platform" to the other end of the spectrum, which might be, as Crystal describes, turnkey. A self-service platform that offers an easy way for a developer to get new instances up and running without any outside involvement, and with the ability to continuously and safely deploy across a fleet of global infrastructure. That's the vision at Snyk, and platform engineering and achieving automation goals will make it happen.
Even if technology and technical choices underpin the building of a platform, the success of a control plane and a good platform engineering endeavor relies on meeting the needs of the humans who use it. But how? It is not as easy as, Crystal warns, building the tech and hoping that your internal users will adopt it. Developer input must go into it. You must advocate for it and non-functionals like documentation and playbooks must be first-class citizens. You must get your early adopters internally, who will then take on wider advocacy, i.e. "championing developers who are resources for other developers."
"The best platform is designed to do its job and get out of the developer's way. We want to enable a paved path without barriers. We can build that platform, but it's useless unless you get the people it is designed for on your side. It is powerful to get the developers who use and advocate for the platform to rally adoption and enthusiasm."
The biggest change a platform introduces isn't technical; it's cultural. Human nature isn't designed to embrace change. Yet with a platform, change comes in the drive to codify good practices within the platform, which becomes more important the more production environments there are. Best practices and standards need to be embedded in the platform and the culture.
And how does culture change? Apart from the internal advocacy described above, education and the freedom to experiment are key.
Snyk has developed a range of educational materials, including extensive documentation using Backstage as a developer portal or ecosystem, adding capability to it and integrations for the rest of the organization. Training and onboarding sessions are frequent and popular, both with the rapidly growing set of new hires and with existing employees.
"Different people learn in different ways, so educating developers about a platform is also about being in touch with them and understanding their needs and having a rapid feedback loop. We want to remove barriers to entry as easily as possible. Having a developer experience team will really help us with this inward-facing effort, listening to the R&D organization and bringing that feedback in."
Platform experimentation
Many engineers may prefer the paved path of the platform. But what about when an engineer wants to do something that is not a part of the platform?
"As part of our platform migration, there was one team that needed a resource we didn't really have the capacity to provide, but we said, 'Here is a playbook you can follow,'" Crystal explains. "We want to encourage an ecosystem of components. Get your hands dirty where you're comfortable, be that with terraform, helm, or a higher level UI, but you can use the platform as it is just as easily."
"The goal of platform engineering is to reduce developer toil and pain, and maybe even find interesting cases where our platform does more than just reduce pain and instead brings joy. We aim for delivering a developer platform that is a pleasure to use and that makes a developer's work easier."