We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Creating and Tailoring a Skills Grid for a New Engineering Group

Career Path
Internal Communication
Scaling Team
Managing Expectations

27 March, 2019

Jeffrey Priebe tells us how and how he set the expectations with his newly team.

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.


Related stories

Balancing Tech Debt and Feature Development
14 September

Mason Mclead, CTO at Software.com, delves into how to take care of tech debt while pushing out new features and products.

Managing Expectations
Dev Processes
Mason Mclead

Mason Mclead

CTO at Software.com

Changing Responsibilities In an Organization Undergoing Change
14 September

Mason Mclead, CTO at Software.com, explains how a primary job of an engineering leader changes as a company grows and how he felt that merely managing people is not the role that fits his aspirations.

Career Path
Mason Mclead

Mason Mclead

CTO at Software.com

Merging a Web and Mobile Team: A Tale of Two Cultures
14 September

David La France, VP of Engineering at Kenna Security, explains how to merge two teams with different cultures, technology and operating modes.

Cross-functional collaboration
Company Culture
Internal Communication
Collaboration
Reorganization
David La France

David La France

VP Engineering at Synack

Managing a Manager for the First Time: Things I Learned the Hard Way
28 August

Catherine Miller, VP of Engineering at Flatiron, taps into her own experience of managing a manager for the first time and shares some key lessons from her concerted effort.

Managing Expectations
New Manager of Manager
Delegate
Catherine Miller

Catherine Miller

VP of Engineering at Flatiron Health

Benefits of Organizational Transparency
28 August

Anoosh Mostowfipour, Founder at ReferralsLink, recounts his experience developing and implementing operational software that helped him achieve the much-desired transparency and improve coordination and collaboration across the company.

Company Culture
Leadership
Internal Communication
Collaboration
Meetings
Anoosh Mostowfipour

Anoosh Mostowfipour

Founder at ReferralsLink

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.