The two things that are different but tend to get mixed up are professional growth and career progression. It does not help that the management-speak is indirect and very contextual. Let’s try to distinguish one from the other.
Professional growth
The way people usually reason about professional growth is through a sequence of titles, terminating on the topmost title that is achievable at an arbitrary company. This view is simple and easy to reason about, but it reduces all the complexity of individual’s skillset into a scalar value, and that’s a bummer.
Professional development is when someone is continuously getting better at things. There can be any number of things, each having a different threshold for proficiency. Many thing aren’t even on the job description. Glue work, for one, fits that. You might occasionally find yourself doing team ops work that doesn’t directly generate any customer value, but this work is still valuable!
One important thing is that, to be able to claim growth, it’s important to achieve a state of comfort employing that skill. So if an engineer takes over technical project management and does it well, great, we celebrate! But in order to claim growth, this needs to be happening consistently.
That’s why “completable” challenges, like running a project that can be finished, are tricky. They look tempting, because it’s then possible to clearly put your finger on them and evaluate success. But also they’re risky, because getting a thing done once does not guarantee level of proficiency good enough to be able to do it again (yet).
So one solution is to go big and continuous. Examples of big, challenging topics I’ve seen revolve around complex engineering practices and tools, for example, event-driven architecture, DDD, developer productivity, creation and adoption of internal tools. Something that is unlikely to ever fit the “done” state, and where grit and continuous improvement matter much more.
And another solution is to go small and discrete. Read a book, watch a video-course, build a project using specific tech, work with certain people.
The two can be tied together and linked to the expectations at current and next level. Helping an engineer devise a career map for themselves helps, but this topic is for the next time.
Career progression
In a nutshell, career progression is a sequence of job titles one can put on their resume. It might fit one career path in one organization, but usually does not, since majority of us work at several companies over the course of our career.
We’re talking about career progression within one organization, because you’re their manager within that organization only. This does not mean that career at large isn’t important, but you can’t really do much to support that, and I’d argue it’s much more productive to spend most of the time thinking within the company, not across companies.
The most pragmatic thing that a person reporting to you can expect in context of career progression is an “resume item append event”, — a promotion to a new role, usually the next level on the career path. This is why in most cases the expression “can support with my career progression” can be interpreted as “can get me a promotion”, and that’s perfectly rational and logically correct.
How is it connected to professional growth and what can you do about that as a manager?
We’re talking about getting to the next level when job performance displays ability to perform at that next level. In order to be able to do that, a few conditions have to be met: there should be an opportunity to perform at the next level, the results should be on par with next-level expectations (can’t approach it with brute force), and there should be a successful achievement in the end. In simple English, find a bigger project, apply skill, get it done.
The middle step, application of skill, is what matters. Professional growth is a result of accumulation of skill. If an engineer couldn’t do something before but now can, it’s not promotable per se, but it unlocks an opportunity. An opportunity that is taken successfully is promotion material. If all works well, there’s usually only a little margin left for luck and, to counterbalance, similarly little margin left for cases when unlucky circumstances take over. So can’t just wing it.
As a manager, you’re likely to be serving the engineers in their professional development and career progression. It takes time to explain how one enables the other, and how the two form a feedback loop.
A mistake I have made and other managers make is to take one for the other and overindex on one thing, which is especially risky if you focus the engineer’s attention on, for example, getting to the next level on the career path at times when putting effort into professional growth would provide more value.
In ideal world, career progression happens as an effect of professional growth, and a step up in the career path unlocks learning opportunities which, if taken, lead to professional growth. Real world is messy, formal titles don’t really transfer well between companies or sometimes even organizations within one company, and for an engineering manager, making it work for the person who depend on your ability to tell what’s going on and what to do is an essential part of the job.
