6 ms·

This 13-step, 150-day program that offloads responsibility on the engineer instead of the team that's accepting them is a tired repetition of the trope that mak

This 13-step, 150-day program that offloads responsibility on the engineer instead of the team that's accepting them is a tired repetition of the trope that makes the onboarding person miserable. The graphics look good on the webpage, but a practical result of this running helter-skelter and trying to check things off the 457-line Google Sheet with mismatched fonts that they have been given. It doesn't work. This means you don't have a process, and are making the new employee (who is happy to have a job, and doesn't want to offend) often work extra hours to compensate for your lack of knowing how to onboard. Here's my alternative 2 cents – actively build in-house software for this. There is a lot of room for what the software can do since it interacts with your systems – it should be, for instance, possible to write a playbook that simulates an interaction with a copy of production data, so you can see real-world use cases that you will be working to address. Construct a set of coherent steps for how your new employees will learn, and enforce those in software.

mattcwilson 5y ago
Sounds legit. Do you have a more detailed writeup of how to go about this? Not just from a technical standpoint, but how to campaign with stakeholders that the value is there, that it’s a good use of team time? And how to campaign with the team to buy them in on establishing and maintaining this onboarding software? One of the practical realities I face often in management is that a weak-but-available solution is at least progress, where big ideas without a clear plan suffer heavy inertia.
- quadrifoliate 5y ago
  No, but it doesn't have to be all or nothing. Some ideas that you could start with: - A repo that builds a toy version of your company's application. New hires have to write tests for some of the components and present a mergeable patch (which is never actually merged). - A set of scripts that verify that the new hire has access to everything they will need. The script should clearly display current access level and what is remaining.
stjohnswarts 5y ago
The right way is to have them mentor with someone even if that slows down the mentor (and it will). Don't assign them to a curmudgeon either. If you don't have the "manpower" then just let them have a couple of months to adjust (assuming they're really hired on and not a consultant) and take it all in, they're already stressed and tacking on a thousand (paper cuts) points of improvement is going to make them feel awful.

mattcwilson 5y ago

Sounds legit. Do you have a more detailed writeup of how to go about this? Not just from a technical standpoint, but how to campaign with stakeholders that the value is there, that it’s a good use of team time? And how to campaign with the team to buy them in on establishing and maintaining this onboarding software? One of the practical realities I face often in management is that a weak-but-available solution is at least progress, where big ideas without a clear plan suffer heavy inertia.

quadrifoliate 5y ago
No, but it doesn't have to be all or nothing. Some ideas that you could start with: - A repo that builds a toy version of your company's application. New hires have to write tests for some of the components and present a mergeable patch (which is never actually merged). - A set of scripts that verify that the new hire has access to everything they will need. The script should clearly display current access level and what is remaining.

stjohnswarts 5y ago

The right way is to have them mentor with someone even if that slows down the mentor (and it will). Don't assign them to a curmudgeon either. If you don't have the "manpower" then just let them have a couple of months to adjust (assuming they're really hired on and not a consultant) and take it all in, they're already stressed and tacking on a thousand (paper cuts) points of improvement is going to make them feel awful.