Our Engineering leadership team believes that hiring and retaining great people is the most important thing we do. Great people do great things; it’s why our company has been so successful.
However, until about three years ago, we were not providing career options to our staff that would allow them to continue to be great while also feeling fulfilled and rewarded, with a career progression that played to their strengths.
Basically, at a certain level, you either moved into management, or you were at a dead end.
There is nothing wrong with management: I sold my soul to the “management devil” years ago (I confess that I often long for the days of being a developer and creating software, but I digress…)
Yet management is certainly not for everyone, and we needed another way. Our best technical talent was hemmed in, and we did not want them forced to take a job that they would be ‘ok’ at when they could continue to add amazing value in other ways.
We also wanted to recognize that management is a professional discipline just like development, quality assurance, project management, etc. It is not something that most people can get into and just intuit how to be great. It takes learning, training, and collaboration with peers just like any other discipline. Some people are great at it, others find it can be a struggle.
Our goal was to create a set of career paths that clearly articulated the value someone brought to the organization, regardless of what the org chart says.
On paper, that was pretty easy. We created a ‘Principal’ track for each of the disciplines (scrum masters, product owners, software engineers, etc.) and communicated the ‘level’ of those positions relative to the value they brought to Engineering, in some cases up to the VP level (e.g. Enterprise Architect).
We offered the opportunity for some of our best technical talent to move into a leadership role as an individual contributor, so they could focus on what they were best at. Most of them took that opportunity without looking back.
But codifying a “value hierarchy” on paper is one thing, actually putting it into practice is another thing altogether. We knew that if we were going to make this move, our actions needed to back up the message we had given.
So we have our Principal Software Engineers not only driving the architectural roadmap for their products, but also sitting at the table discussing the product strategy with the Engineering Director and the Director of Product Management (their peers).
When presentations are given, the Principals stand with the Directors. When we have Leadership meetings, we invite everyone at the appropriate value-level. For instance we have “Senior Staff” which includes managers, Tech Leads and Principals. And, of course, we level compensation and put the money where our mouth is, which even means there are occasions when an individual contributor makes more than his or her manager.
As a result of these and many other day-to-day actions, our team gets the clear signal that while the org chart exists for a reason (everyone has to have a manager and we need a scalable organization), what we value is the contribution a person makes to our success.
We do not want an average Manager when we could have an amazing Tech Lead, or a Director who is so-so when we could have a Principal who is shaping the future of our technology.
I am proud of how this has worked out. People within our Engineering organization tend to not worry about the org chart. Rather, they think about having great ideas and seeing them through. It is empowering to know that you are valued for the skills and talent you bring to the organization, and this structure has provided that to some of our best.