The Software Engineer’s Career - Beyond Senior
The mythical post-senior stage of an engineering career and how to prepare for it
The software engineering career path is fairly straightforward at the beginning of the career trajectory, from intern or junior up to senior engineer. It also tends to be similar across different organizations. It is in the post-senior engineering career that things start to get fuzzier. For many years, the unfortunate state of the industry was that the most viable long-term option was a foray into management. While this is an interesting and rewarding route, it is not for everyone. More than that, pushing everyone in that direction is detrimental both for the individual and organization as whole. The push toward management can either be direct (the only viable path in the organization) or indirect (for example, by not emphasizing the importance of the engineering path or by having an unreasonable pay gap between the engineering and management paths). Let's explore what the post-senior engineering path looks like and how you can prepare for what’s to come.
This article covers a few angles:
Post-senior career trajectories
Skills needed for post-senior career advancement and how they differ from pre-senior roles expectations
A distinction between engineering and people management trajectories (with references to infamous tech skills vs soft skills debate that pops out every now and then).
I’ve previously covered bits & pieces of this topic, from an organizational perspective, in articles related to building an internal engineering career framework - part 1 and part 2. Here, I will focus on this phenomenon predominantly from the individual’s perspective.
Before I do that though, let's dissect the engineering career path at pre-senior stages so we can more clearly appreciate just how different a post-senior path is from what went on before.
Path up to senior level
In most companies there are few levels that precede senior roles. Typically these are:
Software Engineer Intern (aka Intern)
Junior Software Engineer (aka Junior)
Software Engineer (aka Mid)
These roles are usually followed by Senior, Staff (typically level above Senior) and Principal (depending on the organization it might be one or several levels above Staff).
Intern, Junior and Mid might be named differently like L2-L4 or E2-E4, but these are really just codenames for the same thing (big tech apparently likes codenames more than the rest of the industry). The actual sophistication or experience expectation at a given level differ from company to company but main underlying themes remain similar:
Scope, need for supervision and area of key focus undergoes an intuitive evolution as the seniority of engineer grows: scope and focus of daily activities expands and there is less supervision needed.
An interesting aspect however is not captured explicitly above. This aspect is a matter of uncertainty that engineers need to deal with. Growing uncertainty is indeed the factor that many engineers struggle and feel uncomfortable with before they become fluent and capable with it. We can visualize it as below:
You typically expect Juniors to be given in-depth descriptions of problems, often coupled with decent descriptions of the desired solution. For instance there is usually some form of more or less detailed business expectation described (if my experience is any indication - usually less).
If you work in the retail industry, the bug might contain the following description: "The generated invoice doesn't have the promoted line item with $0 value. Whenever we give a customer a gift due to promotion it should be the last item on the invoice with the price equal to $0". This actually forms a problem statement (missing line item) and a business solution (line item with $0 as the last position on the invoice). Usually what follows next is a conversation with a more senior engineer who might even tell the Junior which part of the system to look at and what is likely to be changed. This is part of the technical solution (where the change should be added). In short, the remaining work is the implementation, and even this is probably already roughly known by a more senior engineer.
The situation is a little more complex for mid-level engineers. They might get something similar to what’s above but, more frequently, the pointers to the actual implementation - where and how to modify code base - are less explicit or non-existent. After all, Mid-level engineers usually have the experience to use their own judgment and find the optimal implementation themselves.
Frequently, even a solution is not clearly given. What might happen is a problem statement such as: "This invoice doesn't seem right. Customer should have the promotion item highlighted somehow on it." Usually an engineer wouldn't have any idea what it should look like, but they'll extract some pointers to people who might know ("Talk with Mike from accounting, he might know"). In short, more communication outside of the direct engineering team area is needed and, to a significant extent, this communication is left in the hands of the engineer. This situation often becomes the ‘daily bread and butter’ for a senior engineer.
Beyond Senior engineers, the situation can become even more complex. The problem statement may be less clear, and it might even be expected that Staff (and higher-level) engineers help direct the organization toward the right problems to solve. While it may not typically be a business problem, it could certainly involve technical or organizational challenges, especially when these issues impact the effectiveness of the engineering part of the organization. Over time, problems often become a blend of business, financial, technological, and organizational factors. In larger organizations, many big problems exceed the boundaries of being purely technical.
One common example, highlighting the intersection of technical and business considerations, is deciding that some error conditions are too costly to prevent upfront, making occasional manual intervention more economically viable (e.g., Support contacting a customer to reverse an order). A notable anecdote from years ago is Amazon’s decision that it was more cost-effective to send an extra item in cases when a customer removed the item from their shopping cart just before finalizing the purchase (due to technical issue, the item was very rarely not correctly removed from the cart, even though customer didn’t pay for it), then actually technically preventing it happening.
And the further up the engineering ladder you go, the greater the uncertainty. Anyone who works successfully at Staff and Principal level eventually learns to live with it. As they say: it comes with the territory. Still, it takes time for most engineers to get used to it.
Post senior world
The traditional view is that engineers need to move into management after a certain number of years in industry. The tech world moves fast and, after a while, they cannot catch up and lose their edge. Or so the story goes. If my experience is any indication, some of the best engineers I've met are in their late forties, fifties or even sixties.
Sure, the way their work is performed usually changes. As the crowd wisdom goes - when you are young you have time but don't have money, and when you are older you have money (hopefully), but you value your time more. Similarly here: 20-year-old loose cannons can survive on coke and pizza in a 24h release crunch - which is still a necessity in certain areas of our industry or even a badge of honor for some. On the other hand, engineers in their fifties make it up with knowledge and experience (which might have even made the aforementioned crunch unnecessary in the first place 🤷).
Big tech got that right early on. In most of these companies, there are usually long career ladder branches for both management and technical disciplines. Here is part of the engineering career ladder from Google. It shows that engineering can be a lifetime career, spanning several decades.
This state of affairs is not evenly distributed across the industry. In many organisations, the engineering branch is significantly shorter than the management one. However, the situation is improving - perhaps due to the increased importance of technology in most companies these days - and the rest is also catching up.
When it comes to the management career path, a simple version might look like this:
At times, there might be a few steps in-between (Senior Engineering Manager, for example) or CTO might not be treated as a managerial role (CTO is a bit odd, some organizations treat it as the most-senior individual role, where the management aspect is handled by the VP of Engineering). It’s still pretty straightforward though.
Things aren’t that simple for the engineering roles. While building the Engineering Progression framework at VirtusLab, we realized that the engineering path up to Senior is intuitively simple. After that things become complicated as a variety of career trajectories emerge.
Here are some of them:
Tech lead - an engineer responsible for a particular area of software from a technology perspective (no people management as such). This might be either a service (or bunch of micro-services if this name still means anything) or a component. In many organizations Tech Lead might be mixed with Team Lead. Whereas this is certainly possible, it doesn’t have to be that way (I personally like to think of Team Lead as a first step in the Management career, rather than one of the steps on the Engineering ladder).
Subject matter expert - an engineer having deep expertise in one of the areas important for the organization. This might be a technical area (e.g. streaming) or a particular crossing of technology and business domain (e.g. the Insurtech ecosystem). Depending on the organization, these areas can be as narrow or wide as needed (e.g. Insurtech is a field wide enough to have individual experts focused on a particular area within the field).
Architect - the days of white bearded architects sitting for eons in their ivory towers, only to finally come back to enlighten pariah engineers with voluminous tomes of UML diagrams, are pretty much over. These days, design and architecture is a team sport and requires a hands on approach. Still, there are engineers who are better at big picture thinking and architecture than others, and they might gravitate towards the architect’s trajectory.
Process engineer - most tech organizations require processes spanning multiple teams or even entire organization. These processes might be engineering recruitment, development lifecycle standardization or improving software quality across the board and many others. The VP of Engineering is usually accountable for this domain (or CTO, if the organization lacks a VP of Engineering), and they often have Staff or a Principal engineer responsible for specific initiatives. Engineers that thrive while building such processes (which involves system thinking, tactical approach and generating organization buy-in) might be called process engineers (or organizational engineers).
Presales engineer - these are engineers who excel in customer facing situations, such as helping sales with new customers or existing customers with their problems or cross-sell opportunities. Engineers on this trajectory need to have solid engineering skills, knowledge of the product (or tech domain) and outstanding communication and presentation skills.
The list above is not exhaustive - there are certainly others. For instance, DevRel (or Dev Advocate) engineer is a role that’s emerged in the past decade. Ultimately, trajectories depend on the specifics and needs of each organization.
To wrap up, we have at least two typical career branches for post-senior engineers: Management and Engineering. Both present rich and rewarding career options. Whereas management is typically straightforward, the engineering path might expand into plenty of trajectories (I discuss some of them in one of previous articles, along with real world examples from other organizations).
Is moving up a necessity?
There is another option, the third one, which is rarely mentioned but is worth emphasizing. The third option is to stay at the senior level. This might come as a surprise, because the outside world often tries to convince us that we need to progress (or grow) at every stage of our professional career. I don’t think this is true and I specifically believe the option to pause is especially compelling at the Senior level.
Think of it. By the time engineers are senior, they usually make a decent salary. And, due to the time it typically takes to reach that level, many start having (or already have) families or other obligations. I think there is nothing wrong with choosing to put your career on the back burner while you focus on other things. Just go to the office (or just your desk at home), work for 8 hours, don’t think too much about it afterwards and maybe read a book or an article about new technology every now and then. In contrast, post-senior roles usually require more involvement than this. Often, it is difficult to squeeze them into a typical 8 hour day. Calls with other teams across the Atlantic during non-work hours, might be more frequent. Both responsibilities and stress rise and there is an expectation that you keep your edge. As a result, continuing to progress may actually make you less happy.
Additionally, the senior level in many organizations seems to be the last level where you spend a lot of time hands-on coding. Sure, you already have a lot of other responsibilities - you might need to coach juniors, participate in calls with people from other departments (like Sales or, speaking generically, business people 😱) or draft a design doc. Nonetheless, plenty of your work still has a focus on building software. This is the luxury that many post-senior engineers don’t have. In many organizations, between helping with organizational processes, preparing risk assessments for the board, reviewing docs, and participating in committees of various kinds, they don’t have much time left to do any actual coding. Oh, and you have to deal with the politics. If spending a bulk of time on coding is what you love to do, staying on the senior level might be a good option.
Staying at the same level might not have been an option earlier on. In many organizations, both intern and junior levels are considered an “investment”. This means, some organizations perceive engineers on this level costing more (in terms of salary but predominantly in the form of time spent by more senior engineers) than the value of work they deliver. As such these roles are often perceived to be “up-or-out”. Up-or-out is a term taken from typical partnership firms, such as legal, architecture (buildings, not software) or medical practices. Essentially, it means that there is a period of time during which an individual must progress to the next level, otherwise they will be pushed out of the organization. In many classic partnership firms these conditions are explicit, whereas in tech companies it tends to be implicit i.e. at some point there starts to be a problem on the performance review cycle if you stay on these roles for too long (imagine being Intern for 5 years).
Technically speaking, one can choose to stay on Mid level. It is certainly possible. However, Senior is usually a natural extension of Mid (as the job responsibilities and expectations follow a similar pattern) and it has a better pay grade. With that in mind, the senior engineering level seems to be a good balance - an inflection point before the type of work shifts away from predominantly hands-on coding.
Speaking of change, let's focus on pre-senior vs. post-senior in terms of expectations and factors that might help you cross the chasm and move forward.
In this section I want to focus on some of the key attributes or skills that will help you progress your career in the post-senior phase. Now, you may notice that I've left out technical skills completely. That doesn't mean they're no longer important - they very much are. The degree of importance and angle you need to take for further development of technical skills depends on the engineering trajectory you pick (that is to say that e.g. Process Engineer might need different skills than Presales Engineer). You surely cannot go wrong with levelling up competencies in area of software architecture (and generally designing software), understanding tech landscape or full software development lifecycle (SDLC) processes etc.
The thing however is that Engineers by the time they are Seniors, already got accustomed to expanding their technical skills. Yes, further development of technical skills is still important, but it alone won’t be enough anymore.
Let's look at the less obvious characteristics of the post-senior career path and the skills you’ll need to hone along the way.
Necessary vs sufficient conditions
Progressing from Junior to Mid is relatively straightforward. There are certain conditions (typically specified in the company’s engineering progression) that you must fulfill. As soon as you have fulfilled them, you may get promoted (well, technically you might need to wait for the next performance review cycle, etc.). At least that used to be the norm. In the newer, post-ZIRP world, many organisations are struggling with budgets (budgets that were overly-inflated in the ZIRP world) and this is having an impact on promotions. In this situation, it is often a question of salary increases rather than levelling up. This means that while your level may have increased, your salary may have lagged behind 🤷♂️. This situation becomes more complex in the post-senior world where multiple angles must be taken into account.
First, an extreme example just to make a point: the promotion to CTO. Whereas it is straightforward to be promoted from Junior to Mid, the situation here is more complicated. Unless your organisation is growing rapidly and has roles for different CTOs (e.g. field CTOs or CTO of a region or technology or domain area), which is rare, it is highly unlikely that you will get the role if the CTO is already there in your organisation. The window of opportunity may open when the CTO leaves. Even then, there is likely to be only one vacancy and the next person in line will often have to wait several years before the window opens again.
The bottom line is this: on one end, promotions from junior to pre-senior positions depends on you meeting the expectations. On the other end, promotion to CTO additionally requires an open window of opportunity; a factor beyond your direct control. Everything in-between senior and CTO is shades of gray in this respect. Naturally there are more spots (even theoretically unlimited) for e.g. Staff Engineer than VP of Engineering, but constraints may exist. For instance, promotion process may involve more scrutiny, whereas the promotion from Junior to Mid might have been the sole decision of your manager. Or there may be a company-wide committee responsible for promotions to Principal (a sort of bar-raisers), or it could be vetoed by your manager's peers or their boss (more on this later).
Enablers
Roles below Senior are clearly individual contributor roles. Engineers participate in the larger scheme of things by contributing their efforts to the equation. We can visualize their work as a part of a sum (technically called a summand):
(Naturally, that’s an oversimplified model yet I hope it will help drive the point).
Managers, even if they contribute significantly to the overall work (they have a summand element) also have a bigger effect on the work of the entire team. That is, assuming they do their work well, they are an “enabling” element. Unfortunately, this means that they also can become blocking (or obstructive) to the whole team. This is intuitive to anyone who has spent a few years in the industry. Good managers can get a mediocre team to achieve great results, bad managers can get a great team to achieve mediocre results (or worse, get all their great players to quit).
Here are some ways managers may improve or hamper the team’s effectiveness:
Good managers set clear goals and expectations for the team (e.g. by managing external stakeholders well). Bad managers allow priorities to change often without a single coherent vision.
Good managers ensure that required resources are allocated for the team (e.g. compute cluster time is available when needed). Bad managers don’t have sufficient organizational influence and are never able to provide resources the team needs.
Good managers foster a healthy team atmosphere where people can freely criticise ideas and problems in order to find better solutions. Bad managers emphasize individual achievements, where teamwork is always secondary and any root cause analysis turns quickly into a blame game.
In a way, a significant part of the managers work is to be a “multiplier” (or factor in mathematical terms) in our simplified equation:
In fact, this is true for all leadership roles - not only pure management. The more we go into leadership roles, the more impactful the “factor” element in the equation is (for better or worse, as mentioned earlier).
There is an interesting point one may argue about here, namely the fact that “Not every Manager is a Leader, and not every Leader is a Manager” (you can read more about it here). I am not going to argue with the former part. Many organizations use the name Leadership as a synonym for Management (e.g. Leadership Career Path). We would most likely all agree that all Managers should at least aspire to be Leaders. I do believe that the second part - that “Not every Leader is a Manager” - is a crucial part in the context of this paragraph. Specifically I’d argue that Leadership becomes an increasingly important part of the role in the post-Senior stages of an engineering career. I made that point earlier in one of my previous articles. In fact, one could argue that the Leadership component of post-senior engineering roles is in a way even more demanding, than in Management roles. This is due to the fact that Engineering path usually doesn’t involve traditional direct reporting lines. For example, Staff Engineers working to improve the security of an organisation's software supply chain, or to improve the effectiveness of the technical recruitment process, may need to influence many teams across the organisation and generate buy-in without a direct reporting structure. Not to mention, they are often responsible for mentoring more junior engineers or setting an example in the organisation. In short, much of the work of the post-senior is an empowerment style of working.
The bottom line is that post-engineering roles require the development (and use) of leadership skills. These include competencies such as communication, decision-making, strategic thinking, accountability, mentoring, conflict resolution, influencing and emotional intelligence. Each and every one of these is a learnable skill (up to a point) and engineers aspiring to post-senior roles will do well investing in developing them.
Communication
I mentioned communication earlier but, based on how important it is for post-senior engineers, I believe it deserves a dedicated section. By the time engineers become Staff-level, they’ve already likely authored or co-authored many design docs and other types of engineering documents. This is both useful (in terms of the function these docs serve) and educational (in terms of honing communication skills).
However, I am talking about communication more broadly, including:
Written - design docs, guidelines, wiki pages, emails and Slack (or whatever communicator you are using)
Spoken - direct 1-1 or speaking within a group of people
Hybrid - usually presentations.
Of these above, I believe that written communication is the most important. A few famous companies, amongst the many that rely heavily on outstanding written communication, are: Shopify, Hashicorp, 37signals or Stripe. In general, it is fair to say the written form represents the majority of communication within most modern day tech companies. Especially so, if we consider emails and instant messaging tools (Slack, Teams etc). And consider them we must, since they are the main communication media. When it comes to working with senior managers, directors and executives, the difference between a sloppy and well-written email may cause the initiative you are advocating being pushed through, entirely blocked or (most-common) not considered important enough to be granted sufficient budget. It is that serious.
I won’t dive into how to write well in the business context. Josh Bernoff already did it extensively in his book: Writing Without Bullshit. It is roughly 300 pages long and, since it will be relevant for anyone moving beyond Senior, I just recommend reading it instead.
One of the key concept covered by Josh is his ROAM framework which stands for:
Readers - who is your audience (What is their understanding of the topic? What are their goals? How much time would they invest in reading your text? etc)
Objective - what change in the reader do you expect your text to make? (Will they change their mind regarding the topic? Will they determine they got all the information regarding the decision to make?)
Action - what action do you expect the reader to do after reading your text (What desired action should the reader do afterwards? What would you consider to be a success after the reader reads your text?)
iMpression - what impression will your text instill in a reader? (in other words - how would they perceive you after reading the text? Would they think you are professional? Would they think you valued their time by presenting the information clearly and succinctly?)
Here is an example:
After reading this email, my VP of Engineering, who is involved in many performance reviews at this time of the year [reader], will understand the risks involved with keeping the legacy payment component in place [objective] and agree with my proposal of spending 2 weeks of engineering effort in replacing it with a new version [action]. They would also value my thorough, unbiased and professional analysis of pros&cons, that helped them go through the proposal effectively [impression].
You can read an extract about this sole idea here. That’s one of the concepts that I found extremely useful on a daily basis. There are many more in the book. Do yourself a favor, and read it.
Team Work
Nearly all technology organizations doing complex work rely on teams, instead of individuals. You might have great players, but in most growing companies, it is a team effort that counts. As work of engineers beyond seniors has a growing enabling component (which I covered earlier) its inevitable part is effective team work.
Key skills in this area include:
communication - covered more extensively earlier,
adaptability / open-mindedness - ability of being flexible to changing circumstances,
empathy - ability to understand others’ feelings,
conflict resolution - ability of resolving conflicts (or even difference of opinions) peacefully and effectively,
conscientiousness - doing your work with responsibility and diligence, being reliable
and agreeableness - ability of being compassionate, cooperative and friendly (which doesn’t mean you need to agree to everything).
Sure, some of them - like high levels of empathy - are given, you are born with them or you developed them in your early years. Still, all of them can be significantly improved with deliberate practice or even just self awareness. Bottom line is - as Steve Jobs famously said - “Great things in business are never done by one person, they are done by a team of people”. Investing in skills to increase effective team work is a sure bet that will pay off.
Ownership and limits of your sphere of control
This phenomenon comes up in conversations so often, I thought it deserved its own section. As already discussed above, most larger initiatives require team effort. In the life of a post-senior engineer these teams might be informal, temporary and part-time (e.g. working groups assembled to improve tech recruitment process), but they are teams nonetheless.
Staff and Principal engineers might be put in charge of such teams. As such, their area of ownership (or as some call it - accountability) expands. An ownership is an important word here - because this ownership may expand beyond the areas you are directly responsible for. A particular area might be a responsibility of someone from the working group, but you are still accountable for it.
All this is pretty much daily bread and butter for engineers who have moved up the management career ladder. Yet, it seems to come as a surprise for many following the engineering career progression.
The first step is to accept and understand the phenomenon of ownership going beyond your direct work. The second step is to learn at least a little bit about management, and especially delegation. Yes, you are on an engineering career trajectory, but the management skills are still relevant, just to a lesser extent than on the management path. In this subject, you cannot go wrong with High Output Management - the seminal work about management, by legendary Intel CEO - Andy Grove.
Business understanding
I’ve used the phrase “business understanding” to emphasize that it goes way beyond “business domain”. The phrase encompasses areas like:
Business domain
Organization priorities
The key stakeholders and influencers, together with their priorities. These may range from slightly different from the organization’s priorities to completely misaligned (sorry to break it to you, but the latter might happen more than anyone involved would like to admit!)
Creating business software is inextricably tied to achieving some business results. These results might range from increasing revenue, decreasing costs, increasing customer satisfaction, lowering the business risks and so on. The key is that there are some concrete business goals. Real world organizations are rarely as laser-focused as depicted in business books. Often the reality is that there’s more than one business priority that needs fulfilling. Five or more is not uncommon and the key stakeholders might not clearly articulate which are more important than others. It may sound sub-optimal, but its a situation you’ll need to deal with.
Understanding the goals and priorities of the software you are working on is paramount. In general, software architecture should be built around business needs and characteristics. It is difficult to build software or design organisational processes that support technology well without at least some understanding of it.
Likewise, understanding who is pulling the strings, what kind of influence particular stakeholders (individuals or organizations) have on the project, is also important. Being effective in any organization means generating buy-in from the right people or parties and it is very difficult to move the needle without understanding these matters.
This may sound like borderline being involved with organization politics, and that’s generally correct. However I do not suggest immersing yourself entirely in politics. People who do that to a large extent and (!) enjoy it, usually come with a package of additional questionable traits. What I do advise is to be aware of its existence and not ignoring it.
Network
Last but not least there is an interesting subject of building your work relationship and network.
First of all, as mentioned earlier, the post-senior promotion process is usually more involved than at the earlier levels. It may require acceptance from your manager or even an entire committee (usually your manager’s peers or more senior engineers - e.g. Staff or Principals). Sometimes, there is a strict budget or other limit for promotions in higher-level positions. As such a good rule of thumb is to build a good relationship, not only with your manager, but also their peers, their manager and most senior engineers in the organization. Generally, the higher up the chain the better. Usually, your reach has vertical limits and stretching it starts to seem dishonest (the work of the director 3 levels above your manager might be too detached from your area of work anyway). The rule of thumb above is a good tradeoff. If you want to improve your luck, try to ensure you have some exposure to these people. Sure, you might try to create a casual encounter in the kitchen and strike up a conversation about common interests —perhaps discovering that you both enjoy playing squash, pickleball, or whatever the next trendy activity might be. Some might see this as perfectly fine, while others could view it as bordering on "sucking up" - depending on the character and cultural environment. Also, social endeavors like this may just not be your thing. That’s actually fine as a far better and more reliable option is just to get involved in the practical, work initiatives with exposure to the right people. Perhaps there is an initiative looking for volunteers that you could apply for? This may be participating in an organization-wide initiative of unifying APIs, improving tech recruitment processes or helping to update engineering progression guidelines. Opportunities abound, if you look for them. Nothing helps people remember you (build your “internal brand”) better than showing professionally done work.
The second thing is building a network outside the organization. This comes from a simple fact of life: as you grow in your seniority, the number of people who could coach or mentor you quickly decreases. This could be intuitively visualized by juxtaposing junior engineer and CTO. Junior engineer, a role which is pretty much entry level, still has a lot to learn in their career and, more importantly, has many more senior engineers around them. At least, hopefully that’s the case. If they don’t then that’s a problem on its own. These senior engineers are not only capable, but also incentivized (again, hopefully!) to mentor more junior engineers.
Now, let’s take the other extreme: CTO. As the most senior person in the engineering organization, they might not have anyone nearby with experience in the scope of their role, or generally, a more senior engineering leader. Moreover, engineers typically work with other peer engineers (on the same level, or more or less senior) and a CTO’s typical group of peers is composed of a CFO, COO or CMO. At best, they might have a peer CIO (Chief Information Officer) or one of the more modern roles like CDO (Chief Data Officer), though such settings are rare. I’m not saying that a CTO cannot learn from someone in their engineering organization (either direct or indirect reports). Sure, the organization probably has people more skilled and experienced in specific areas, but there is likely no one who wore the boots of CTO before.
So, comparing a junior engineer (the most junior technical position) with a CTO (the most senior technical position) gives us an extreme example. The roles in between fall on a spectrum spanning these extremes. Staff engineers work less frequently and less directly with more experienced engineers than junior engineers.
Ultimately, the solution is to mix internal mentors and coaches with external ones. This might be a group of peers that you know from previous companies. Or it might be a network group that you built yourself over your career. An external group has a lot of benefits such as being emotionally detached, having an unbiased perspective and a different set of experiences.
If you don’t have such group, there are some paid options:
Luca Rossi organizes a lightweight version via his Refactoring Community (a companion to his Refactoring newsletter).
CTO Craft organizes lightweight (Slack based) access to other industry tech leaders, as well as more structured (and priced higher) monthly round tables with a smaller, more intimate group. I’ve been part of it for 2 years, and I highly recommend it if you can afford it.
I’ve heard some good opinions about Plato Community - including it’s 1-1 - but never have tried it myself.
Structured/facilitated options are in my opinion better for discussing concrete challenges. The problem is the price, which might easily go north of $1,000 a year, though some companies might reimburse the fee for more senior employees.
There are likely many other options available, including ones local to where you live (face-to-face beats Zoom calls when it comes to support groups).
Wrap up
We have covered a lot of ground in this article, depicting the characteristics of the engineering roles beyond senior level, potential career paths and the skills needed.
One additional thing that’s worth noting: choosing a path (e.g. Management) that eventually turns out not to be in line with your vocation, is not usually a grave mistake. Most organizations allow lateral movement between Engineering and Management paths (often with none or minimal negative effect on salary - depending on the depth of their engineering career track).
My personal experience is that such a temporary foray into management might be beneficial for a post-senior engineering career. Charity Majors even wrote a whole article about the idea of switching back and forth between engineering and management - The Engineer/Manager Pendulum. There is nothing better than direct experience on the other side to cure some of the detachment that happens between Engineering & Management in some organization. The grass is always greener on the other side.
As a closing note I am linking some great book resources that might help you in post-senior engineering roles:
Writing Without Bullshit by Josh Bernoff - hands down best book about effective business writing.
Staff Engineer: Leadership Beyond The Management Track by Will Larson - great book focusing on first beyond-senior role - Staff Engineer
The Software Engineer’s Guidebook by Gergely Orosz - covers the role and skills for senior engineers, the foray into team leadership and into post-senior roles
The Manager’s Path by Camille Fournier - isn’t related exactly to the career of post-senior engineer as it covers Engineering Management path - from Team Lead to CTO. However it might give you a good overview of how life on the management path looks like.
High-Output Management by Andy Grove - absolute classic when it comes to management books. As mentioned earlier, some management skills are needed anyway on the engineering path and this book provides the basics, bundled with an interesting story.
As always, don’t hesitate to reach out to me if you are interested in any of the areas outlined in the article. You can find my contact details here.
Till next time 👊