It might be a stereotype, but software engineers are commonly archetypal introverts. There often seems to be an inverse correlation between the technical brilliance of the developer and an aversion towards speaking in front of large audiences.
Unfortunately, as you start to climb the ladder of seniority, the responsibility to spread your knowledge and influence grows more widely. This means that a lot of introverted-but-brilliant developers can find themselves plateauing once they reach a certain point in their careers.
Well, I’ve got some good news. If you consider yourself someone who fits into this category, then this is the blog for you!
Let’s talk about how to gain recognition as a developer, even if you’re not comfortable speaking in public or shouting about your achievements.
Some people are so hungry for a feeling of importance
If you’re a software engineer and find yourself stuck, it can be common to come to one of two realisations.
The first is that you’ve hit the ceiling of what’s possible as a software engineer. Despite wanting to “stay technical”, this usually results in the decision to either become an architect or to reluctantly go into management1. Neither of these are technical in the same sense as being a developer. This misconception is particularly true of architecture, which is far more about bringing people along on the journey than it is about designing solutions. Both management and architecture revolve more around people than code: that makes them very different skill sets from engineering. And these are skill sets that you may not have or want to use if you’ve spent years honing your craft as a coder.
The second realisation is that you need to start presenting what you’re doing publicly, more often and more widely. If you’re a life-long introvert this can be a nerve-wracking prospect. Maybe it’s something that makes you deeply uncomfortable or maybe you’re just not that good at it yet, but either way this route can take a long time to get used to. This doesn’t mean you’re not a good engineer, it just means that public speaking isn’t your strong suit.
The one thing that both of these routes share is that they both require speaking confidently in front of reasonably-sized groups of people. I don’t know about you, but this wasn’t really something I signed up for when I became a developer - I was drawn in by difficult challenges to solve, designing creative solutions, and turning ideas into reality.
It can be very easy to see the clearer career progression of becoming a manager or an architect as your only next step. But there is another, less frequented path.
The rare individual who unselfishly tries to serve others
You may have come across the titles “staff+” or “principal engineer”. Despite a reasonable number of people knowing these terms, there’s a strange phenomenon in which a lot of developers reach the status of “senior”2, then entirely forget that the terms exist.
The public definition of a principal engineer is someone with influence, not only within their company, but within the wider industry at large. I think this can often feel like a completely unattainable goal for a lot of developers. It doesn’t help that senior engineers may be extremely experienced within their one area and not have much influence within their entire company as a whole, let alone the entire tech industry. This gap makes the leap to principal engineer seem ginormous, leading many engineers to discount it altogether as a possible career path.
So how do you bridge that gap if big presentations aren’t your thing?
By building influence one person at a time – forging smaller, personal relationships.
If you’re not one for speaking publicly, then the key is in forging many smaller personal relationships. Become dependable. Spread ideas through one-to-one interactions. For example, instead of giving a talk on clean code, pair with a junior engineer and show them how you’d refactor a messy function.
When we think of being influential, it’s very easy to conjure up images of grandiose gestures and large-scale presentations. Occasionally these kinds of spectacles will meaningfully land important messages with a large number of people. But more often, these presentations have a widespread but weak effect instead. Impactful influence comes from deep, personal interactions with people in small groups or one-on-one. It’s only when you can hear the nuance of someone’s situation that you can truly provide useful advice and help them internalise it in a way that’s meaningful for them.
If you’re a skilled-but-introverted software engineer, then you likely have a wealth of knowledge and understanding locked away that you’ve built up through years of experience. That experience can’t be distilled into a punchy fifteen-minute presentation. Through personal, one-to-one conversations with your more junior peers3, you’ll find ways to impart your experience that are right for the person you’re speaking to, rather than via generic, watered-down theatrics4.
Winning friends begins with friendliness
Helping others directly is all well and good, but how exactly does that relate to being recognised as a more senior engineer?
Reputation grows organically.
You don’t grow your reputation as an established engineer by forcing yourself onto people or by shouting the loudest. If your ideas are truly valuable to enough people, this might work. But the reality for most is that this fosters apathy at best, or at worst, resentment. Real recognition takes time and patience5.
Word of mouth is a very powerful tool. When you take the time to help someone, not only do you make their life easier, you also cement yourself in their consciousness as someone they can turn to when they need a hand. Next time they have a problem, they might come to you. More importantly though, next time someone comes to them with a problem that they can’t solve, they might suggest to that person that they talk to you instead.
This viral form of growth also has the benefit of providing a built-in means of assessing yourself. If more people are coming to you out of the blue and asking for help, you’ve probably done a good job of helping others6: lots of recommendations mean that your assistance was valuable. Be aware though, this kind of organic growth doesn’t follow a linear curve - it’s far closer to exponential growth. This means that, whilst early on you won’t see much benefit, later down the line things can escalate very quickly.
You’ll also find that taking an open approach to helping others comes with a few beneficial side effects too. When you get into IT, everyone assumes for some reason that you know how to fix a printer. This ends up becoming a self-fulfilling prophecy, as you get asked to do it so much that you just get really good at it. Helping others works in the same way; it’s awkward at first, but eventually you’ll get used to being exposed to unfamiliar contexts and quickly assimilating the information you need. It’s a valuable skill that’ll often help you with debugging your own issues – particularly the more unexpected or challenging ones.
Only knowledge that is used sticks in your mind
I’ve spoken in this post as if I arrived at this approach to working life via some machiavellian plan. But the truth is that I found myself here through luck more than judgement, and I only really understood the mechanics of what I’d done via the benefit of hindsight.
However saccharine it may sound, when I joined the company I currently work for, I promised myself that I’d do my utmost to stay out of any self-serving politics (whether that be started by others or of my own making). I was determined that I’d be loyal to those I work with, and that I’d approach ever interaction assuming best intent.
My sole mission was, and still remains, to make the lives of those around me a little bit better each day.
Through this lens, it’s easy to see how I stumbled into my current approach to career progression. Of course I want to be recognised for the work that I put in, but climbing the ladder was never the goal it just happened to be a by-product7. However, along the way it became clear that this approach felt far more gratifying than putting my energies into promoting myself. I also found a lot of solace in the idea of measuring my progress via how many people I helped, rather than in how well known I was. It always felt more within my control. And if I fail, it’s far easier to make peace with if it’s down to my own shortcomings.
Influence doesn’t have to mean grand speeches or flashy titles. As an introvert, your quiet consistency and desire to help can leave a deeper mark than you realise. It isn’t just a great way to increase your reputation – it’s somewhere you can find a more personal fulfilment within your day-to-day job role by genuinely being there for those around you.
-
It is possible in certain companies to take on a hybrid role, either as a developer/architect or developer/team lead. This kind of thing may be a good chance to dip your toes into the water when it comes to more people-focussed roles. That said, they aren’t really a good way to stay technical, as they act more like a plaster on the problem of plateauing career progression than a solution to it. You will get to spend half of your time being a developer, but doing the other role will likely gain you more kudos career-wise, and you’ll be strongly incentivised to dedicate more time to it. In the end, you’ll just be making the same decision again when it comes to your next step up the ladder. ↩︎
-
As an aside, I do find a lot of developers that are willing to give themselves the title of senior way before (in my humble opinion) they are really due it. I get it. In the age of LinkedIn and all of the job-title-related chest puffing that it brings out of people, it can be tempting to inflate your own seniority. As a regular interviewer, I can tell you first-hand that nothing makes someone seem less senior than them calling themselves senior (or intermediate) on their CV when they’re clearly not. As a rule of thumb, I always stuck to simply “software engineer” until I found a number of other people regularly referring to me as senior. Broad feedback from other people is by far the best way to gauge your own worth. ↩︎
-
When you find yourself in the mode of “imparting knowledge” to someone more junior, it can be easy to switch off the side of your brain dedicated to learning. Just because you’re actively trying to help someone with less experience than you, it doesn’t mean you can’t learn from them. Software development is an infinitely complex and nuanced space that is always changing. No matter who you’re speaking to or what subject you’re discussing, there are always lessons to be learnt. ↩︎
-
Just to be clear, there’s nothing wrong with a more extroverted approach to influence. It’s just not my personal style. ↩︎
-
Anyone that has read my previous blogs may already know my feelings on over-zealous career progression. If you don’t, but are interested, you can find another post on the subject here. ↩︎
-
This can get out of hand eventually. If so many people are coming to you that you become a bottleneck or can’t get your own work done, then it’s time to start looking at ways to reduce those dependencies on you (after all, you don’t want to become a “cruise ship”). Doing this well is an article for another day, but my preferred method is to find other people that want to progress, and are deserving of doing so, and pay it forward to them. If you are going to do this, make sure the person you’re delegating to knows that you are, knows why you are, and is comfortable with the extra workload. ↩︎
-
Perhaps you choose not to believe this. That’s okay with me. I’ve never been that motivated by extrinsic means though. A certain amount of financial stability is needed to live comfortably, but beyond that I find far more fulfilment in creative expression or in helping others. I do at least need a computer and an internet connection though, I’ll admit that. ↩︎