Issue 2: Promotion Season
I was officially promoted to “Senior Software Engineer I” at work this week. It took a while to get to this (I’ve held Senior Eng roles before joining my current organization), and I have thoughts about the process and the role.
Also, my G key is working on my keyboard again. I guess it was ghosts, I dunno.
The Process
The funny thing about “talent cycles” is that you have to be working at the level of the role you want, at the compensation and recognition of the role you have, and you have to do it for months.
To be clear: I’m not complaining here. I don’t know how to improve that part of the career development process. We have clearly defined expectations for each level in our engineering org, and I’ve been taking on responsibilities and delivering impact at a senior level for a while now, in preparation for this promotion. It makes sense to have someone show that they’re capable of handling the demands of the role they’re striving for, but it still somehow feels a bit suboptimal as an overall process.
The next level is Senior Software Engineer II, and there’s a very valid question of when I should start delivering at that level. Do I start right away? A month or two before the next talent review cycle? If I’m doing that work, shouldn’t I already have the title (and comp bump)?
Promotions based on potential are equally risky. If my manager nominates me for promotion without evidence that I can handle the demands, that sets me up for failure. I don’t think I’d want to be promoted and then find I’m struggling to deliver.
(And that would be especially true for the step after in my person career plan, Engineering Manager.)
How is this managed at your organization? Let me know!
The Role
For now, though, the focus is on SSE1 work, alongside my duties as engineering lead for my team.
While there are certainly technical-delivery expectations for the role, what I’m more interested in is the human aspect. Leading cross-functional projects means I get to learn from folks on different teams and different domains. I’ve already learned so much more about marketing and product decisions, for example, that go into shipping a feature. I’ve discovered the ways that other teams handle their work planning and agile ceremonies. It’s all endlessly fascinating to me to see how people come together to work on a project.
And the other human aspect at this level is the expectation of coaching and mentoring. This is my favourite part of the job; I had the privilege of acting as mentor to our team’s intern late last year, and it was so rewarding. I’m looking forward to doing more.
I’ve said this before, and still strongly believe this: you should not consider yourself a senior engineer if you’re not spending a material part of your time mentoring and coaching.
I’ll even go one step further: bring the concept of apprenticeship to software development. Here in Canada, “real engineers” have to work under someone with a PE designation before they can write their exams. When I was an undergrad in engineering school, it was my mentor that presented me with my Iron Ring. I’m still forming my thoughts on this, but too many junior software devs can’t find work and too many senior devs are stuck working on junior-level tasks. Requiring the mentoring of juniors as part of your senior developer job description makes sense for everyone.
I’ll write more on this topic in a future issue, but I’d love to hear your thoughts too!