The vast majority of my writing is around the act of leadership and generally how I tend to manage the humans in my organisation.
I enjoy writing about being a manager and everything it entails, but I am 100% convinced that you should only start managing humans after you have spent years building things and pushing them to customers. Now, I fully understand that the above is quite a sweeping statement and it likely depends on a whole number of factors in your workplace and/or life.
However, my experience of this tech industry is that the craft of programming changes so often that you soon get caught out and completely miss out on a ton of things if you aren’t looking.
I started working as a software developer in 2006 (jeez) and since then, I’ve worked in numerous organisations which all had different levels and structures. One of the biggest shifts I personally noticed, and still to this day make sure engineers are aware of, are the jumps in a career that feel slightly bigger than others. I would love to sit here and say all jumps in my career were the same but in my experience, they weren’t. I’ve also noticed this as I’ve seen others in my teams make similar jumps.
Now if you want to go and read an awesome book on all of these jumps I will gladly push you towards The Managers Path (https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth-ebook/dp/B06XP3GJ7F) which should give more detail but I wanted to talk about one specific role which I think does need a little more of your attention; the Senior Engineer.
(Small Ben Related Disclaimer…)
If I was to change one thing about my career so far, I would have stayed a snr eng for longer. I would have built bigger things. I would have solved harder problems in different settings. I would have learned how to be a manager from working under a ton of different ones. I would have broken things on a bigger scale.
The IC Path
Back when I was a graduate… I always imagined Senior Engineers as these battle-worn white dudes who would rub their beards and sneer at my every suggestion. My bias is likely down to a number of stereotypes and my own experiences in media and communities, so please don’t be offended! (I am a battle-worn white dude with a beard after all) Fast forward 15 or so years and I can happily say that my idea of a snr eng has been well and truly shattered; thankfully.
I’ve had the pleasure of working in a number of different orgs and every snr eng I’ve worked with have come in different shapes, sizes and backgrounds.
How these folk became to be a snr eng differs but to generalise how most org ladders/frameworks tend to work, the general path to snr eng looks a little like this;
There are loads of open source career frameworks by companies such as Monzo and Rent the Runway but to once again generalise and to add my own spin on things… most snr engs tend to come from that above rough path.
Now, that won’t cater for the thousands of possibilities that folks now have in front of them, and the plethora of job roles that we can now take. I’ve seen a snr eng come from Product. I’ve hired career changers who came from other industries. I’ve seen folks come from different disciplines and go up/down frameworks based on their experience with a new codebase.
The possibilities are endless and that’s AWESOME.
The fact that in a lot of companies these days, you can try a role out to see if it fits you and your style is amazeballs and should be celebrated. There is nothing worse than a manager who no longer wants to be one but feels like they have to be.
The Role of a Senior
When thinking about how a snr eng fits into a technical organisation, it strikes me that we don’t give a ton of support for aspiring engineers to show them what good looks like. The manager path is quite well documented with a ton of books, courses, and guidance on how to be a strong leader.
What about a snr eng? What does good look like? Who should they aspire to be?
So if I sit back, as a manager in an org, and write down what a role model snr eng in my org looks like; what are her common traits?
- She is a positive influence on the team but is still grounded in reality.
- They coach just as much as they code… my expectation is that they become a multiplier in the team, not the bottleneck or the superhero.
- She actively mentors other engineers who aren’t in her team.
- They know when it’s time to speak; coming into the discussion first and biasing the discussion is one of the smells of a poorly performing colleague.
- She has a keen interest in scalability, observability, and availability.
- They have an interest in management and how projects are run; ‘estimate’ isn’t a bad word.
- She is actively looking at what got her here and what will get her to the next step.
- She knows that software needs tests.
- They prioritise code reviews of the team over their own work.
- She constantly questions if this is the most impactful thing we could be spending our time on.
- She wants to lead or at least help with documentation and design.
- They don’t burn the midnight oil frequently but on the rare occasion that the team needs a push, they lead from the front.
I’ve personally felt for a long time that the role of a snr eng is likely the hardest in the tech industry. The amount of pressure, impact and overall focus that lands on the role of the senior engineers in your company are something you should spend serious time thinking about with your teams.
How are you growing and supporting engineers who just got promoted to senior? How are you highlighting the positive role models in your organisation for others to aspire to be?
‘Make before you manage’ is without a doubt the biggest bit of advice I repeat on a weekly basis to anyone who is thinking of becoming a manager at some point. The humans will continue to be there but the tech may in fact change every 3-5 year cycle depending on which field or area you are in. So the next time you have an engineer who is looking at becoming a manager ask them one simple question; ‘what’s the biggest thing you’ve ever broken?’