Creating and Tailoring a Skills Grid for a New Engineering Group

Problem

"I opened a new engineering group in a new country. We started slowly, learning the local expectations, establishing trust, and finding the first key employees. (Cross-cultural management is a topic for another story – or many more stories). We were pursuing a very different thesis with this engineering group, so our existing training approach and compensation plans were not relevant. We needed to start from scratch. As we ramped up hiring, we needed to:

• Clarify for engineers what was expected.
• Provide a clear set of goals for what would make them successful at the company.
• Be fair and transparent."

Actions taken

"I developed a matrix, each key skill being a row, and the columns showing increasing levels of both measurements (e.g. tests or certifications as appropriate) as well as work examples (e.g. 'Can architect large features' [with an example from our work]). We had a new 'basic training' program developed and exiting that, an engineer would start at the first level. This level was unique in that it contained a note indicating that we expected the first level to be temporary, and outlining two timespans: one was a 'good' timeframe and another was 'acceptable.' That is, at review after the 'good' timeframe, moving to the second level would be a good result. In order to further underscore the self-driving nature of the levels, we also provided reference training materials that would help move along the lower levels. The skills/criterion themselves were pulled from both existing understanding of skills required for the work, but also in tuning to the specifics of the country, we included other critical skills that weren't as common in this country as they were elsewhere. This matrix was shared publicly with everyone and it was explained during onboarding as well as explained to new hires prior to them accepting a position. The compensation band were listed, tied to each level. And to ensure that the hard measures were fair, I benchmarked them myself in addition to the data I had from our pool of candidates."

Lessons learned

"First, as with most efforts requiring thought and expanding into new territory: the work itself yielded good learning. Insight was gained from deciding what skills were truly critical, which ones should be included as they supported the critical ones (and their inclusion helps the engineers). In the latter case, think of a professional athlete: they are measured on specific skills but time in a gym, while not a measured goal, supported success in the measures that matter. If your company already has an established ladder, ask yourself what might be missing – particularly in terms of supporting activities. How can you clarify and communicate these to your team?

Second: Get and use data. Use available industry data, survey your corporate peers, and act on that. When running one of our hoped-for metrics, I realized it wasn't as indicative as we would have liked. I adjusted which level it was tied to and added a supplemental/replacement measure (that was better, but required more difficult to administer).

Third: Specific to ladders: establish them early. You can change them – though you need to communicate clearly any change. Think of such changes like you might approach API changes: you have to be very careful about 'breaking changes,' want to be fully backwards compatible when practical, and you need to communicate the changes long before they affect people."