Onboarding Developers in Omaha

Onboarding Developers in Omaha

Dear Sloan,

Here’s the summary: I need to onboard a few hundred developers to a new tool that will help with software supply chain security. The problems: it’s a big change for developers, and the tool is only valuable if they actually use it! How can I encourage my developers to use the new tooling, and quickly?

Sincerely,

Onboarding Developers in Omaha

Dear Onboarding Developers in Omaha,

That’s a very good question. You’re right – you really do need devs (developers) to use the tool you provide because software supply chain security is important! But change can be scary, and a rough onboarding will scare devs away.

Unfortunately, there’s no secret strategy that will painlessly get your developers onboarded. But here are three tips that will help make the process as smooth as possible.

Onboarding Starts with Education

Every successful onboarding starts with education. You can’t skip this part; developers need to know how to use the tool you’re introducing. Make this your top priority.

I bet that new tool comes with some educational resources like videos, guides, documentation, or courses. Find and vet some, grab the links, and share them somewhere internal, like a wiki or Confluence page. Ask your devs to start by reviewing those resources. This ensures good usage, builds confidence with the tool, and prompts devs to go straight to the source if they need more education or a refresher.

For developers in particular, demos and sample workflows are key. A big part of onboarding is telling your developers what to expect, and when to expect it. Demos and workflows are the best way to do that. Include them in your internal wiki. Devs can use it as reference material, or to help onboard other developers as required.

Communicate your Goals, and Listen

Question-asker, you need this tool to help secure your software supply chain, right? Be sure to tell your developers that, point-blank. Onboarding will be smoother if devs know there’s a good reason to use the tool. Think of it like this: would you wait in line if you didn’t know what the line was for? Neither would devs.

If there are metrics you need to hit, talk about them. For example, if you need to see a 25% reduction in vulnerable components in your software by the end of the year, say that explicitly. Developers can’t help you achieve your goals if they don’t know what those goals are.

But communication is a two-way street. Listen to feedback. Ask developers what they need to achieve those goals. Maybe they need it to be less noisy, less time-consuming, or less distracting. Adjust your onboarding procedure accordingly.

Bonus advice: if developers say the tool is too complicated, read my first tip again!

Onboard through a Pilot Program

The last tip is to think about a pilot program. Start onboarding with a team of high-performing developers. Tailor the process to their needs, let them use the tooling for a few weeks, and then get some feedback over lunch or a cup of coffee. What did they find easy? What did they find difficult? Use that feedback to make further adjustments.

The idea here is that what you think developers will do and what they actually do are two different things. Don’t assume anything. Instead, let the real experiences of your pilot team guide you.

Regardless of how the pilot program went, take the time to celebrate success. Other developer teams will be more likely to “bite” if they see other developers being successful.

That should get you started. Thanks for the question, and good luck!

Signed,

Sloan