I wrote before about two of my onboarding experiences and how they shaped my view of the company I was starting at. Those were remote, senior-level software development roles. In this post, I’m going to write about improving onboarding for roles that were not remote, senior, or for software development.

Once upon a time, I worked for a company that surveyed railroads to provide “maps”¹ of the track. Doing the survey required our GIS technicians to physically traverse the track with our survey equipment. Afterwards, the technicians would return to the office with the data they had gathered, process it, and produce the needed data.

The surveys were done using a mix of custom hardware and software, some built on top of standard industry tools like ArcGIS. The hardware was the easiest part to learn. Most of the custom software was built for processing our specific data formats, according to our specialized workflows, for an unusual niche. It would be impossible for a GIS technician to have any experience or knowledge of our internal tools. It was rare enough to find techs that had worked in railroads.

New technicians needed to learn about railroads, about the track data niche we occupied in railroading, about our processes, and about our tools. Doing that all on-the-job meant it took months of training for a new tech to be able to function with any independence. Besides the long timeline, their knowledge was heavily dependent on what projects had been in what phases during their early learning period. In other words, we took a long time to train them and accidentally pushed them into specializations.

Once upon a time, we had two experienced techs and zero inexperienced techs. We were pursuing contracts that would be far more than the two techs we had², or two techs and our engineering/leadership staff³, could handle. We knew we needed to increase our capacity.

So we did what made sense at the time: we hired a bunch of GIS technicians, explained a bunch of stuff to them, gave them some tasks they could handle, and made ourselves available to answer questions. Some of these techs were pretty experienced in off-the-shelf GIS tools. They were all pretty sharp.

It did not work out well. They did not learn a a lot. Their progress was uneven. Things didn’t get done right, deadlines were missed, important steps were forgotten. All of that led to a lot of frustration everywhere. Long-timers in the GIS department were frustrated with the new techs’ lack of progress and lack of productivity. The new techs were frustrated that they couldn’t make progress, at the expectations that were placed on them, and that “this isn’t what this job is at other companies.” A batch of three technicians hired in April were all gone by August. It was all our fault.

It was not a great return on the investment in hiring and training.

This is where I was brought in more actively⁴.

We reviewed the outcomes we were after. We asked ourselves why we had GIS technicians in the first place, what we needed from them at different stages of their development with the company, and what would show us they could be trusted to work independently.

With an improved understanding of what the GIS technician job was at our company, we revised the job description we posted. We made it much more clear that we were looking for a combination of field and office technician and that a lot of their work would be with custom tools. After all, if we set the expectation early, maybe even “scaring away” techs that might not want to do all of that, we’d put ourselves in a better place—even if it took longer to hire. We posted the job and started to interview candidates.

Concurrently with interviews, we sketched out a 3-6 month training plan with very specific learning modules, labs, and evaluations⁵. In a technician’s early days with the company, we would not expect “productive” work. They needed to learn. We would also reserve time from our senior techs and GIS Director to train them. We were very transparent about the objectives and would be very clear about when a technician did not reach the level they needed to “qualify” in a competency area.

In short, we completely overhauled our original onboarding and our expectations. We started with ad hoc training, trying to train in between “productive” work, with an unclear roadmap. We ended with an onboarding process that started with the very first interview as we set expectations, going through a well-defined training plan with clear goals. We could make empirical measurements of progress and prescribed next steps for each technician (e.g., “Alice qualified on railroad feature identification basics. Bob did not. So next week, Alice is going on to her first error correction lab. Bob will re-take the feature identification module with extra assistance from Carol.”). The training wasn’t made up or slapped together; every module built toward being a fully trained technician.

The results were stark. Over the next couple of months, we hired a new batch of technicians. It was more difficult; more candidates washed out on the more difficult interviews we were conducting, and several candidates we extended offers to turned us down because they didn’t want to do everything we would ask them to do. Of the next batch of technicians we hired, every one lasted at least two years. Some still work for the company, 5+ years later. They all fully qualified within six months. Any specializations were by choice and skill. The onboarding process and training have continued to be used for future techs, while being regularly improved—in part by that very batch of techs.

Both senior techs we had at the time have moved on in their careers and are no longer with that company. But the onboarding process we designed made it fairly easy for the company to survive the loss of skills. One of the techs in that first batch that was hired and trained by the new process is, I believe, leading the technician team. If we hadn’t hired well and trained well, that would probably not be the case.

The point: onboarding isn’t just for fancy remote software development jobs. Good onboarding is a deliberate practice to get the right people the skills and knowledge to do their jobs well. Good onboarding leads to improved retention, improved productivity, and a better feel around the office⁶. Good onboarding is a deliberate investment into the people your company is bringing in. Good onboarding takes work. Whether it’s worth the effort is up to you.

1. Technically, data files in AAR S-9501 and AAR S-9503 Positive Train control track data formats were the primary outputs. Maps, track charts, elevation profiles, and additional data like cellular coverage analysis were optional extras. [↩]
2. both senior, and both excellent [↩]
3. we had designed the internal tools and processes, and trained the current (senior) techs [↩]
4. At the time I was focused mostly on software teams developing PTC Back Office Server software and, if I remember right, tools for validating track data. [↩]
5. I’d been away from the day-to-day GIS work for long enough that even though I could rough out the plan, the senior techs and GIS director had to make some adjustments and fill in all the details. They did great work coming up with labs that pushed the limits of the new techs’ growing knowledge. [↩]
6. real or virtual [↩]