The True Secret of Career Growth as a Software Engineer
No, it’s not AI.
Career growth has always been an elusive topic for many software engineers. It’s not something that is taught in computer science classes or coding bootcamps.
It’s also not something that is made overly clear in most technology organizations. You join a company, you do your work, and, at some point, you get promoted.
Sometimes, the promotion seems reasonable and logical. You’ve been getting good performance reviews, completing your tasks, being praised. So you get promoted from a junior developer to an intermediate, level 2 to level 3, or in accordance with whatever role scale exists within your organization.
But, more often than not, you seem to be doing all the right things and yet not getting promoted. You’ve been working long hours, helping your team, taking on every “stretch” assignment imaginable under the sun. Yet, you don’t seem to be any closer to promotion than you were a year ago.
When asking your manager, all you get is “just keep doing what you are doing” or “you’re almost there”.
But that doesn’t help, does it?
I’ve been through it. I know how it feels. Frustrating and disempowering. You feel that you’ve hit a career bottleneck without an obvious cause — boxed into your current level.
The problem is that most software engineers don’t realize that there is a hidden reality underneath their performance reviews, work, and ability to advance in their career.
That hidden reality consists of two parts: influence and value.
Let’s talk about both. Because knowing how to navigate them is what unlocks career growth.
The first part is:
Influence
Influence is something that you might associate with management and executive roles. Development managers, directors, VPs, and C-Level leaders.
It’s true that these roles exert influence over their respective teams and within the vicinity of their immediate departments. The higher the role, the more influence it wields over the organization.
That’s something that most understand and accept.
What most don’t realize is that influence is a key skill for, not only those in people leader roles, but also software engineers, architects, and other individual contributors.
The difference between the influence of those in leadership roles and those who are individual contributors (ICs) is that while leaders have direct influence, ICs wield a kind of influence that is indirect. That indirect influence can often be even more powerful when coupled with the right approach and mindset.
Below is a general view of how different levels of software engineering roles differ in their level of influence from both a technical and non-technical perspective.
These can be thought of as the “circles of influence” of any particular role.
Technical Influence
Non-Technical Influence
These can differ slightly between organizations and teams. However, they are, more or less, attuned to the general reality of software engineers’ roles in the industry.
Now here’s the key.
Even the smaller of the circles above — the role of the junior developer has influence. It may not be as wide as the higher level roles, but it isn’t 0. Far from it.
In fact, as demonstrated in the image below, each level has an amount of influence over some part of the organization.
Now, you might ask — what does all that have to do with career growth?
The answer is: everything.
Because career growth happens at the intersection between these circles of influence.
You grow in your career when you push the boundaries of your current circle and into the one that envelopes it.
Most importantly, the three types of circles above are intertwined: the technical, non-technical, and organizational are typically expanding at the same time.
Often, when great software engineers and architects get stuck, it is because they are pushing the boundaries of one circle, but not all three.
Let’s demonstrate this with a concrete example.
You are a senior software engineer and you want to move into your next role. Let’s say that in your organization, it’s the role of an architect (no “staff” level at your company).
You are currently well respected within your team and your circles of influence look as follows:
Technical
- You are responsible for major segments of the codebase, and you own most of the feature functionality.
- You own the system design and architecture of your app.
- You co-own the deployment of the application with the DevOps team and the cloud infrastructure, at least in part, with the platform or cloud team.
Non-Technical
- You mentor less experienced developers
- You help establish and run team processes (code reviews, for example)
- You also help others when needed with their tasks by guiding them and also getting involved in assisting them with system design and coding
Organizational
- You are well regarded as a competent technical SME (Subject Matter Expert).
- You participate in team meetings and are vocal about the things that you think should be changed to better the team
- You act as a sounding board for your manager, non-tech stakeholders, and your peers for technical topics, project progress, and other key matters.
Now imagine the following:
- You begin looking into how your system fits within the overall ecosystem of the wider organization and you identify some potential areas of improvement. You propose those changes.
- You convince your manager of the benefits these improvements will bring and you reach out to other teams who integrate with your application and begin collaborating with them on these.
- You establish communication with stakeholders outside of your typical environment and get their support to pursue the implementation of the improvements that you have suggested.
Notice how with each of these points above, your circles of influence expand — technically, non-technically, and organizationally.
Growing from a junior software engineer to a director-level architect and coaching many others through similar career growth, I’ve noticed that this is the path that most often works.
Of course, there are nuances to it, and there is personal and organizational context. However, in general, of the thousands of folks who I’ve worked with over the years, and many of whom I’ve seen grow or directly helped them grow, every time, it was a process similar to this.
There is another piece to the pie though.
In addition to Influence, there is also the element of Value.
It is worthwhile to explore this element as well since it isn’t frequently voiced and is even less frequently understood.
Value
If I were to sum up how career growth works as a general rule — this would probably be how:
“Your career growth is directly correlated and proportional to the perception of value that your work brings”
Let’s break it down.
What does “perception of value” mean in this context and who is the one perceiving?
Put simply, “value” here is the positive impact that your work brings to the organization.
“Perception of value” means that the value has to be acknowledged by someone.
It isn’t enough to simply provide value. If you want to grow in your career — that value needs to be perceived, acknowledged, and appreciated.
By whom?
The person or people who hold the keys to your promotion or who can directly or indirectly influence it. Typically, that would be your direct manager (director, VP and so on) - though not only. It could be a project manager, your manager’s manager, a high-level individual contributor — anyone who has any kind of influence over your career growth.
That’s where 90% of skilled, smart, capable, and hard working individual contributors get stuck.
Remember the the topic of Technical Influence we have discussed above? Imagine that you would only expand your circle of technical influence we talked about earlier. You might introduce a new library or a new framework that makes the application faster to respond. You might fix a bunch of critical bugs that no one else has noticed.
But even though these things provide value — if no one sees, understands, and appreciates that value — it isn’t going to help you in your career one bit.
Many technologists shy away from what they think is “bragging”. That’s understandable. We don’t like bragging about what we do — even if we know that our work has brought great value.
But making your contributions known is not necessarily bragging. In fact, you might even be doing a disservice to your team as if no one knows about that great thing you have implemented, how would others benefit from it?
Some common ways to make your contributions known:
- Maintaining an “achievements” list that you can share with your direct manager — what was done and how it benefited the team
- Scheduling team meetings to share knowledge (knowledge transfer or knowledge enrichment sessions).
- Documenting the work that was done and sending it out to the team
- Making a mention of the work and its value during a skip-level meeting
Summary
So let’s recap.
Career growth for software developers/engineers, architects, and other technologists has two major components, both are seldom understood or discussed.
Influence — To grow in one’s career, it is imperative to expand one’s circles of influence. For software professionals, there are three main such types of circles: technical, non-technical, and organizational.
It helps greatly to work towards breaking into the next layer within each of the circles simultaneously.
Value — Critical element for career growth, it has to do with how those with decision making power over your career growth (or with influence over direct decision makers) perceive the value that your work brings.
Often, even if one brings tremendous value to the team and/or organization, if that value is not properly seen, understood, or appreciated by decision makers, career growth will be stymied.
Unlocking your career, therefore, requires the expansion of the value you bring to the next layer within the circle of influence.
If you are a software engineer or architect looking to grow in your career, I wrote several guides for folks just like you. These go deep into how engineers and architects can grow and become successful in their careers.
Based on my own 25 years of career progression from a junior software engineer to director of architecture, executive consultant, and career coach.
If this resonates, you may want to check these guides out.
👉 Unlocking Your Software Engineering Career: Intermediate to Senior
👉 Unlocking the Career of a Software Architect in the Age of AI
The True Secret of Career Growth as a Software Engineer or Architect was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
