I’ve published a career framework on Progression. It is based on advice I frequently give to engineers and engineering leaders at Schuberg Philis (SBP). Since I was having more such conversations than I have time for, I created this framework last year to help our coaches have more in-depth career development conversations without me.
It doesn’t work!
Disclaimer
Though I incorporated feedback from a lot of colleagues, this was never “the” SBP framework. Our company culture is as informal as it can be, with just enough structure. Making a framework such as this official is more than we need. We do not want people to think of their careers as a checklist to complete or as a ladder to climb. Instead, we suggest people mostly focus on growing their impact, picking up and mastering new competencies along the way.
Framework
The base framework is rather abstract, defining 10 coarse-grained competencies that apply to all engineering roles, such as “maintaining quality” or “planning and organizing”. The competencies have up to 7 different levels. These 10 competencies are grouped into Craftsmanship, Human, and Leadership categories.
The Progression app is organized into strict levels. To make the tool work for us, the online version of the SBP framework defines these levels too. But these are not actually used within SBP! It’s quite common to have some competencies at a very high level and others still much lower, and that’s ok with us. One common example is engineers with very highly rated craftsmanship skills but lower rated teamwork skills. The reverse also happens!
Roles
In this framework there are only three roles defined: engineers, tech leads, and technology officers.
Engineers are our individual contributors (ICs), an industry term we don’t usually use. When engineers lead others, they do so primarily by example, based on the content of their work.
Tech leads (TLs) are engineers that accept additional leadership responsibilities. Tech leads are not in charge of teams, we expect servant leadership of them.
Technology officers (TOs) are a lot like tech leads but with somewhat different leadership responsibilities. While tech lead engineers lead one specific team, our technology officers have a somewhat broader scope. They’re a bit further removed from the day-to-day engineering work, giving them time to focus on cross-team topics and to do work for which there isn’t a dedicated engineering team available, like presales.
TLs and TOs are leaders but not managers. At many companies with career ladders and levels, TLs and TOs might be considered staff or principal engineers, i.e. they are still on the “individual contributor” track. While some engineers progress by taking a TL or TO role, it’s important to realize there are engineers at a “staff” or “principal” level without a TL or TO role. Those engineers could match a different staff-plus archetype (like Solver or Architect), or just not match up with such a rigid framework at all. It’s also possible to switch from a TL or TO role to a regular engineering role.
Engineers at SBP do have additional roles at times that require additional competencies. For example, engineers can become coaches. These are not part of the framework.
Competencies
While Progression is optimized for defining pretty specific skills for pretty specific roles, this particular framework is broad and generic, and so is focused around competencies.
There are up to 7 different levels defined per competency.
While the basic competencies are the same for TLs and TOs as for engineers, our expectations of where our leaders will focus are a little different, and so for some skills there is a leadership (L) variant defined. Since Progression doesn’t support such variant definitions, there’s some overlap/copies.
Competency example: Client Orientation
SBP is an outsourcing company. Our engineers work in self-steering teams dedicated to a single customer. Because all our engineers have a lot of customer interaction, the framework is relatively heavy on communication compared to many other progression examples.
Progression for comparing roles & levels
One cool feature in Progression is how it allows you to put different roles and different levels side by side. This can help engineers think about which direction they might develop in next, though since at SBP we don’t actually use levels it’s of limited use for us.
Progression for check-ins
A recent addition to Progression is a new check-in feature that arranges a guided conversation between engineers and their managers (or in SBP its case with no line management, coaches). The idea is to agree together on career progression.
I like what they’ve built here. I imagine it’s a good way for HR departments to help beginning engineering managers have decent-quality factful conversations. But it’s not the right tool for Schuberg Philis.
It’s a great example of our “too much structure” rule kicking in. We have an internal 360-degree feedback process that is less structured than this, asking open questions instead, focusing on the important feedback conversation more and happily sacrificing some structured/detailed record-keeping in the process. Maybe when SBP is 10 times bigger that has to change?
Spreadsheet version
I created the Progression version of this framework based on my initial spreadsheet version of this career framework. I’ve found most people feel quite overwhelmed (at best) when confronted with this spreadsheet, while HR professionals appreciate the comprehensive overview.
Success!
Developing this framework helped me think through career guidance in great depth and that has helped make my advice to others clearer. I sometimes refer back to it when helping to weigh or appraise feedback, during salary discussions, or when writing job specs.
Putting the framework in Progression really helped to compare our framework to other engineering companies and to benchmark our internal levelless ranking system to common industry levels. Sometimes I can use it to explain to our younger engineers that no, they would not be ranked as principal engineers at Google, yet!
The process of iterating on the framework together was valuable. Asking and discussing feedback helped to align our leadership’s thinking about how we appraise and value our colleagues. Beyond leadership, trying to describe very different work in common terms (dev and ops, for example) helped the people involved to understand more about each other.
Our HR professionals happily adopted the framework, for example to develop and finetune our internal leadership training. For my HR colleagues relatively new to IT organizations it really helped them to see and understand both the breadth and the depth of our careers.
Failure!
This framework hasn’t helped our engineers or their coaches! My colleagues may look at it, perhaps understand it as reasonable and sensible…and then will never use it during their career planning or career development conversations.
People are unsure why, but they tell me the framework “doesn’t feel right”.
I believe one problem is that the level of abstraction is so high people don’t know how to apply it for themselves in a practical way. Making more concrete roles (like “java developer”) with more concrete skills (like “java programming”) could help, but that’s a lot of work to set up and maintain.
I believe another problem is that the setup is still too constrained: our actual appraisal system is more free-form. I imagine if we were to strictly define career levels that would then prompt more colleagues to use this framework. Especially if we linked the levels to salary ranges. And…I don’t know that would be positive. SBP tries to be a place where all our colleagues can “become who they are”, which for many colleagues can mean quite an “unbalanced” set of competencies.
The framework also hasn’t helped me! Our non-technical coaches have difficulty using the more technical competencies. You need an experienced technologist’s help to evaluate the quality of your solutions designs or implementation plans, to determine how competent you got. It sucks to have a conversation about those things with a non-technical coach.
So in the end even if my colleagues do use this framework, they will still ask for my help, and I save no time!
Fortunately, it’s the kind of conversation I love to have.
LSD::RELOAD 