Tackling Developer Onboarding Complexity
How do you onboard new developers? What do you need to have in place to, for example, ensure that any new developer can safely and comfortably get their hands on a pull request on Day 1? Effective onboarding is a challenge for many cloud native organizations and their engineering teams. I’ve talked to a lot of developers, platform engineers and SREs, engineering managers and leaders, and the consensus is clear: Onboarding new developers is hard. But if you get it right in a complex microservices environment, it pays dividends in the long term.
In a series of Ambassador Labs podcasts, the onboarding subject comes up time and again, usually highlighted as a point of friction and frustration, but also a potential source of experimentation. How can onboarding be most effective and sped up? How can new developers get straight to work? How can they be sure they are getting what they need? How can companies be sure they’ve provided the right insight, guidance and tools to support the long-term developer experience?
Help Yourself: Self-Serve Developer Control Planes for Efficient Onboarding
A common denominator across most cloud-based organizations I’ve talked to is the drive to centralize the developer experience within a self-serve platform or developer control plane. Standardizing tools and processes in a single place builds consistency of experience and provides a single source of truth. It offers the developer clear on-ramps and paths, relieving the cognitive load and making onboarding a priority.
The beauty of a developer control plane is that it’s an idea more than an out-of-the-box product. The developer platform is a configurable concept that allows an organization to pick and choose the right tools for their developers’ tasks and include these in their platform as a paved path, or guardrails, for their experience. Lead platform architect at Lunar Bank, Kasper Nissen, explained that when advocating for investing in developer onboarding, “If a platform team can offer a preferred take on how to do specific tasks in the workflow and recommend a set of tools to use, developers won’t spend too much time on trial and error.”
Developer platforms serve a similar purpose at Zipcar, where the platform team works to provide a developer platform that paves a seamless path to production, giving them the tools they need and an understanding of dependencies without slowing them down. The platform team should be able to provide self-service tools and on-ramps to help developers work confidently with the aspects of software delivery that aren’t their core responsibility.
Onboarding for Your Engineering Culture
Not every engineering or developer culture is the same. In fact, most aren’t. While many engineering managers and platform architects advocate for the self-serve platform approach, how this — and overall onboarding — happens is largely unique to individual organizations. The platform contains the tools developers will use from the moment they arrive. The tools are an important part of onboarding, particularly when the platform relies heavily on internal tools — you’re encouraging developers to “drink your own champagne” (use the tools your company develops) from Day 1. But the platform and the tools are just one, albeit key, aspect of getting onboard.
Using a tool as part of daily work and eventually knowing enough to be able to improve on the tool may be the end game, but everything leading up to that involves culture and processes, which differ wildly between organizations. Culture and processes, too, are just other vintages of the same sparkling wine and will be unique to your engineering culture and the needs of your organization.
Building Your Underlying ‘Champagne Culture’
There is no one single way to onboard developers. In practice, developer onboarding can take a lot of different tacks. Drinking one’s own champagne is critical to the onboarding journey — and this champagne contains culture and process as well as internally developed tools.
The Wisdom of the Crowd
For example, Apostolis Apostolidis (better known as Toli), principal practice engineer at U.K.-based car-purchasing platform cinch, shared that his company has built out an “engineer progression framework” that helps to make roles more visible and that existing internal engineer managers at cinch support the onboarding process. Everything is held together within the context of building communities and collaboration.
Katie Gamanji, former ecosystem advocate at the Cloud Native Computing Foundation, encourages turning to the community for answers: “Technology is great, but the community around cloud native is what really makes it great.”
Listen to the Developer and the Org, and the Spirit of Improvement
Onboarding is also about empathy for the individual. Organizations that empathize with new developers will eliminate friction and fuel a more collaborative, supportive onboarding experience that allows developers to provide input on processes or tools as they progress in their onboarding journey.
Crystal Hirschorn, director of engineering, infrastructure, SRE and developer experience at Snyk, discussed the importance of addressing that different people learn in different ways and making a rapid onboarding feedback loop a critical part of rapid and effective onboarding.
“Educating developers about a platform is also about being in touch with them and understanding their needs. 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,” she said.
At the same time, empathy includes the actual software development process. Developers should learn as a part of their onboarding that using their own software products in their work better prepares them for building and refining customer-facing products and solutions. Having an understanding of customer pain points and challenges firsthand and where they encounter friction in the software creates conditions for more usable, human solutions.
Software development is, as Google’s Kelsey Hightower shared, deeply human. “If you get really good at the human side of it, I think you will end up writing much better software,” he said. Cultivating the human side of software development is a step that can be taken during onboarding. Onboarding in this way becomes about infusing the engineering culture with the spirit of improving the software constantly. Developers are motivated to do this not just for customers but because they are drinking the champagne themselves and will benefit from the efficiencies they create.
Standardize and Reduce Complexity for Speed and Creativity
A common thread in onboarding, and more broadly on reducing developer cognitive load, is the concept of “golden paths” or “paved paths.” Ultimately, the idea is to reduce complexity and get to the bare bones of what needs to be learned or done to increase developer velocity and safety. Mostly, once the cultural aspects of onboarding are covered, this comes back to the “golden path” platform created for developers, which includes the tools and processes that are proven to work but aren’t handcuffs. Once a developer knows how to walk, for example, platforms should be flexible enough to let them run.
Humanitec’s CEO, Kaspar von Grünberg, said, “Perhaps more important than fancy golden paths is to agree on the lowest common tech denominator to empower developers to work faster. Why run ultra-complex things if there is an alternative? It is like taking a tractor to do your grocery shopping, which is not productive. If you scatter things all over the place, you are not getting the effects of scale, and the tools you bring in are not delivering ROI. This is why I advocate for the value of standardization. Standardization forms the lowest common tech denominators, clearing the way for individual freedom where needed.”
Nissen of Lunar agreed, saying, “As they learn, developers are empowered to explore other possibilities. Lunar believes in the balance of freedom and responsibility, telling developers: ‘This is not the only way to do X, but it’s one way that we know works, and we recommend that you learn to do it this way to start.'”
Developer Onboarding in Practice
Katie Wilde, Ambassador Labs’s vice president of engineering, firmly believes in “unblocking engineers” as a key part of her role. And there are, according to Steve Barlow, senior engineering manager at Ambassador, few spots in the life cycle of a developer that need unblocking more than onboarding.
At Ambassador, as part of actively using the tools we create, Wilde was able to identify some potential hindrances to smooth onboarding. Despite Telepresence being a collaboration tool, having difficulty installing it in the first place would certainly stop a developer in their tracks.
“I realized it could be tricky for people to install Telepresence and get it running,” Wilde explained. “If you are onboarding an app developer into this environment, battling with an install and complicated instructions, this isn’t a productive use of a developer’s time. This is straight-up toil — and not the developer’s core job. Creating a simple, easy-install command reduces a huge amount of friction, especially if you are starting from zero. With onboarding, the clock really starts when you sit down at a blank machine with nothing on it, and we say ‘go.’ We want to be able to assign PRs [pull requests] to new developers on Day 1. It’s through fast and effective onboarding and growing familiarity with internal tools that we are able to get there. From day one, we have seen onboarding times dramatically decrease.”
Barlow expanded on these points, explaining that his own approach when he joined Ambassador was to onboard as though he were joining as a developer. “I tried to run Quick Starts, tried to get my dev environment up and running, and so on. This immediately exposed a lot of friction, seeing what developers need to do, but might not have any easy time doing. I should be able to get a dev environment running within a day, and if I can’t, something is going on. As a manager, I am looking for those points of friction.”
Onboarding Best Practices and Cultures Using Your Own Tools
“Drinking your own champagne” isn’t only about using your own tools internally. It is also about using tools as enablers to spread best practices and a productive development culture that powers growth. Tools are only as good as the way they are deployed within a well-functioning development culture. By extension, a good onboarding experience positions developers as contributors to the tools that not only help their productivity, but extend productivity to external users.
After all, why should external organizations and developers use your tools? Onboarding for new developers should begin with and constantly return to this question. It is not only about the tools themselves, but about culture and introducing that culture to newcomers as soon as they join your organization, and helping them to contribute to both the tools and the culture. A shared culture is the basis from which well-functioning tools and processes are created.
Ambassador principal software engineer Alex Gervais described the balance well.
“Once we have built and live in a strong culture, we have room for experimentation and sharing. We like to share what we are working on across the org, and feedback is always more than welcome. Once more, drinking our own champagne is a lot about sharing and collaboration. We learn from each other and each other’s experience, which informs how tools are created and improved. This is true from a new developer’s Day 1 at Ambassador.”
