ignite bright starburst logo

How to Streamline Developer Onboarding

In my experience, there are a few ways to create an approach to streamline developer experience. Certainly, the size of the organization will vary the approach, but the points below are meant to help you spur conversations at your org and to start on this ongoing journey. If you are an engineering leader, this should be part of your plan to Remove Developer Friction.

The key themes of this post revolve around:

  • Documentation
  • Automation
  • Centralization
  • Standardization
  • Self-Service (ran out of *-tion words)
  • Onboarding Buddies

Onboarding & Early Days

When you think about streamlining developer onboarding, you probably only think about it in the context of a new hire. While you’re not wrong – I want you to also think about the engineers that switch projects as well. We’ll discuss the latter after this callout.

This is someone’s first experience with your organization. Onboarding needs to be purposefully put together and not an afterthought.

Switching Projects

As a software engineer and a consultant that has switched projects multiple times in my career, this is an often overlooked piece of the puzzle.

Thinking back to previous engagements, there was a lot of time spent on calls with other team members learning how systems operated. How to get access to logs. Who to talk to about security requirements. And so on…

Documentation

It’s an equally exciting time for a new hire and a company to begin work. Whether it’s a DevOps Engineer, a Front-end engineer, or somewhere in between – streamlining the developer onboarding process should begin before the new employee’s first day. It’s also very exciting to switch gears and join a pre-existing project.

If this is a new hire – you want to ensure that you are sending them comms not only about how to access the office (if you’re in person), but also how to access the systems that they’ll need. If the approval process for tooling is long – start this in advance to the individual starting. Ideally, their account is provisioned and you can make the request on behalf of them.

If this someone joining a new project or a new hire – I’ve seen onboarding be successful where there is a 1-pager for what to expect during their first week. This document serves as their reference guide with an array of links to short guides on how to request access to tooling, core repositories for a project, key points of contact, links to accurate systems diagrams, and more. Keep it 1-page or less.

Every engineer has been here before. Especially when you think about small startups building fast & scrappy or even large orgs. Keeping tabs on architecture decisions, technical debt, and other items that should be documented are often the first things to get disregarded (followed by unit tests).

There needs to be a culture of keeping documentation up to date. It needs to be clear and accessible for all internal tooling, services, and development processes. Spending a hackathon or a half-day improving your docs can go a long way.

Developer Portals & Tooling Access

We’ve got a lot of background in automating tooling access and building out Developer Portals. So, we may have a bit of bias in saying that this is the most important way to streamline developer onboarding.

Not only do modern developer portals centralize and host documentation, they can now also provide a testbed for API Endpoints (i.e. mock requests + responses), view monitoring & logging of critical systems, track deployment statuses, and much more. There should also be a shortlist of Golden Path deployment strategies that outline how the Continuous Integration and Continuous Delivery pipelines work. We’ve also seen early promising results with hosting Mermaid Diagrams of system architecture to better outline the interconnectedness of systems. Finally, another importance piece of this Developer Platform should be to clearly articulate what the standard tools + development practices are. Automated enforcement of these standards go a long way to ensure the longevity of the software being delivered.

Investing the time and money into standing up and creating the tailwinds to gain adoption for the internal developer portal can be one of the best investments for an organization. Certainly, it depends on the size of the engineering org, but we’ve seen increased developer happiness, increased developer productivity, decreased support tickets on specific repositories, and a massive increase in self-service.

The primary goal of the developer portal should be to centralize information and allow for self-service access to tooling / environments.

Automated Development Environment Setup

This could be anything from a shared bash script to how to provision an entire machine (if you’re managing that).

For the sake of keeping this brief, the simplest way would be to create a bash script that clones and sets up the most important repositories on the individual’s machine. This could be their personal machine or a machine that the org has provided for them (orgs should allow Bring Your Own Device).

If developing on a local machine is more difficult, you could spend time to ensure that a tool like GitHub Codespaces or another Cloud IDE works.

Create Centralized Access Portals

This is more than the aforementioned Developer Portal. This should also include access to common Human Resources tooling – like individual’s paystubs, benefits guides, etc. Why stop at just streamlining the technical onboarding? Ideally, there is a way to Single Sign On (SSO) into these tools, but the first step could be as simple as a Wiki page with links.

Buddy Program

This is really a failsafe to ensure that the new engineer or existing engineer has time with someone from the project. It also requires an organization to be a bit more mature. This Buddy Program should allow the individual a place to “ask dumb questions” after consuming Documentation, have someone authorize their access tooling, or anything else. This Buddy should know the in’s and out’s of the org to point the individual in the proper direction.

If the individual is junior level, buddy programs can be a great mentorship tool. Whether it is for helping them push to production in the first week or for a longer-term relationship at the company, it help build up your internal talent.

To Wrap It Up

Streamline your developer onboarding by focusing on a few key areas. Start with clear documentation that provides easy access to tools and systems. Automate environment setup to get new hires coding quickly, and centralize all resources with a developer portal that offers self-service options. These portals can include everything from mock API requests to system diagrams, making it easier for developers to navigate and get productive fast.

Incorporate a buddy system to provide hands-on guidance and support, ensuring new developers have someone to ask questions as they settle in. By simplifying access to both technical and HR tools, and establishing consistent deployment processes, you create a smoother onboarding experience that boosts productivity and keeps your team happy.