Here’s your new cubicle. Okay, it’s more often a case of here’s your new desk, your new laptop, smartphone, financial expenses and human resources app, or – if you’re a software engineer – your new integrated development environment, project code version control repository or team workflow methodology. They’re all significant changes to the way an employee needs to do their job and get on board with the work ethos of the department, team or organization that they find themselves in.
The Age Of Onboarding
Back when Generation-X started work at around the end of the 1970s, workers had to (mostly) like it or lump it when any change occured. Fast forward half a century or so and we’re a little more humane. This is the age of onboarding i.e. a time when formalized procedures are in place to make sure new work factors of all kinds are introduced carefully and compassionately to familiarize people with change. By providing onboarding meetings, documents, how-to videos and more, what we used to casually call “induction” is now a more sensitive process that is designed to improve employee retention and job satisfaction.
Of all the changes happening now at the coder’s command line (and this is not a story about AI, mercifully), the elevation to platform engineering is perhaps one of the most important factors to onboard software developers for. By providing self-service software toolsets and workflow items via an internal developer portal, developers get a nicely pre-paved path with automations that abstract the complexity of infrastructure provisioning and management that they might otherwise have to also attend do.
But as good as platform engineering is, it’s still a change, so organizations will need to be sensitive to the initial user interaction that developers have with the platform approach, which can significantly limit adoption.
Innovators & Early Adopters
According to the diffusion of innovations theory, there is a 16% user adoption point that represents a critical threshold where an innovation moves from the early market to the mainstream market. This occurs because the initial adoption is often driven by “innovators and early adopters” who are willing to accept unpolished experiences due to curiosity or strategic vision; however, broader adoption requires appealing to the majority with more refined solutions.
“The majority of early adopters, comprising around a third of users, becomes essential for achieving mainstream success. They demand clear value, proven stability and intuitive usability (even it comes with a few rough edges). This transformation in user expectations creates a gap that many platform engineering initiatives fail to address. Initial adopters may overlook issues or points of friction in the onboarding experience, but mainstream users will not,” explained Bryan Ross, field CTO, GitLab.
Ross says that any software platform’s “brand identity” represents users’ first point of contact with an application, tool or service. He thinks that strong platform brand identities communicate benefits than any explanation or clarification of underlying infrastructure. He asks us to consider software brand names like “Runway” (a technology that coalesces various cloud infrastructure elements to streamline deployment pipelines and processes) that showcased the intended value proposition of the service, rather than using any more technically explanatory jargon like “Kubernetes Pipeline Producer”, for example.
Version 9.120.80, No Thanks
“Technology teams working to deliver, implement, augment or dovetail with platform engineering principles should avoid common naming shortcomings that can undermine a platform’s credibility,” said Ross. “Showing the number of versions in the name suggests that past iterations have failed, calling durability into question. Similarly, choosing an unimaginative three-letter acronym combination makes a platform indistinguishable from other abbreviations, while technology-aimed names indicate a prioritization of systems over user requirements,” said Ross.
Because users’ initial perceptions are usually visual, he underlines the fact that outdated or inconsistent interfaces can deter users, despite strong underlying functionality.
“Organizations often dedicate months to refining platform capabilities while ignoring the most fundamental need: creation of a smooth, effortless experience. I’ve seen this pattern across companies of all sizes and sectors,” clarified GitLab’s Ross. “The most common obstacles include manual onboarding processes for a platform claiming to be self-service. When full automation isn’t realistic, handle human tasks asynchronously as much as possible to avoid long approval workflows or restrictions that prevent instant testing. One solution is to offer immediate, temporary access to your platform free of charge for 30 days, which is usually enough time for someone to determine if your platform is a fit for their needs.”
Training, Not An Entry Barrier
Another common mistake is when a team can be defined to require training before using any given platform or service. The advice here is that while training is (almost always) useful, it should be required after joining the platform rather than being a barrier to entry.
Even the best solutions require support and immediate, responsive support is the best way to build trust with users. The main objectives during support interactions should be to reduce user frustration and maintain momentum. Ross and team advocate the need for a strong support structure using diverse channels, they provide the following four cornerstones:
- Ticketing systems offer tracking and integration with current workflows.
- Email correspondence can tackle complex topics requiring a thorough explanation.
- Real-time chat enables instant problem resolution when users are actively working.
- Documentation hubs provide self-service answers to frequent questions
Ross says that organizations aiming to roll out new platform engineering toolsets (and this is probably advice that could apply to the deployment of any new element of IT services at any level) should stay reachable through each users’ preferred communication methods, even if that requires monitoring several platforms.
“The bedrock of platform engineering excellence isn’t choosing optimal technologies. It’s rooted in empathy and understanding. The best platform teams are the ones that build a deep understanding of the daily realities of developers, security professionals and operations specialists. They realize the constraints these teams must go through, their success measurements and the obstacles that create the most friction,” concluded Ross. “Companies that prioritize user experience from the start gain significant advantages in adoption rates and user engagement. By establishing smooth onboarding workflows, comprehensive documentation and reliable support networks, teams convert the user experience from being a challenging one to an excellent one.”
Platform engineering has made plenty of headlines across the technology and business media over the last year or so, it has also impacted the social discussion threads among many technology communities (there was little talk of little else at the last couple of Cloud Native Computing Foundation symposia) and of course it has actually physically impacted the way many software engineering teams operate.
Because platform engineering is a significant change, an additional degree of forethought is sure to go along way. If we take more care upfront in terms of onboarding, then it should be plain sailing ahead.
