A few weeks ago I did a presentation to my engineering team which covered what their career would look like at Athenian.
I wanted everyone on the team to walk away with a clear understanding of the different roles, scenarios, and career path possibilities at Athenian and how these different roles coexist.
Most importantly, I wanted them to understand that when you go into a management position, it will be a completely different job from being a software engineer. It requires a different skill set, mindset, and approach to work.
What I’ve realized in my own journey as Head of Engineering at Athenian, is that, often, when you come from being an IC, you don’t have visibility into the reality of being a manager. It’s been a challenge for me and it’s something I honestly still struggle with today.
It’s also why I decided to put some of that presentation into words, for software engineers who are braving through this path, or not sure what their next career move should be. And for engineering leaders, who, like me, want to empower their teams with as much transparency as possible.
So today I will go into:
👉 The IC to Manager pipeline
👉 The mindset shift that managers need to have
👉 Engineering salary as you advance in your career
👉 The different engineering career paths you can choose from
The opportunity.
When you’re an IC, promotions come automatically. You reach a certain level of technical expertise, and you get promoted by the manager. In an ideal world, this is a business impact-driven promotion. But tech expertise often unlocks the potential for bigger impact.
Becoming a manager doesn’t happen the same way.
First, you need an opportunity: a team to manage. This can happen when part of the engineering org, let’s say, the web application team, suddenly starts growing. At that point, someone will come to the team and say “We now need someone to fully manage this team. Who among you is willing to step up?”
I would like the person who puts their hand up to already have a clear understanding of what it means to be a manager and to be interested in stepping into this role before the opportunity arrives. This way I can put them on that path and they can be more effective, and ultimately happier in the role.
👉 One of my current goals is to make sure team members are put on this path early on (if they show interest). This way when the time comes, I can walk into the room and already know who is, not only willing, but ready to step up.
The existential crisis.
Before I became Head of Engineering at Athenian, I believed that someone who is leading the engineering team is still mostly coding, and, when needed, coordinating the team.
I was wrong.
I realized that when you become a full-time manager, it’s a completely different game. You’re no longer expected to code, and, for someone who comes from a software engineering background, this can lead to an existential crisis of “maybe I’m not an engineer anymore.”
And I want my team to be aware of this struggle so that when they have to decide between growing as a developer or becoming a manager, they know what to expect.
The best software developer on the team won’t necessarily be the best manager. This is why when that moment comes, it’s so important that both the team and the engineering leaders have a clear understanding of what it means to be a manager, and who has the predisposition to take on the role.
💡 The Case for The Mediocre Athlete
A great way to illustrate how the best engineers don’t always make the best engineering leaders or managers is by looking at professional sports. Here’s an excerpt from the Developing Leadership podcast, where Jason Warner goes into the sports analogy:
“If you look at the mediocre athlete to head coach pipeline, it's actually quite strong. But the hall of fame athlete to successful head coach pipeline is pretty small. And the reason why, I have always surmised, is that the mediocre athlete has to understand way more about the game early on. On the other hand, the hall of fame athlete doesn’t really have to understand many situations”
Case and point:
The mindset shift.
In the early days of Athenian, when we were a five-person team, I was still coding, and spending 50/50 of my time between coding and managing the team - but this split was not constant.
There were a few weeks a year where I would really take on that managerial role, especially when opening and closing the quarters when there had to be alignment with the company goals and with the leadership team.
And in these moments, coming from being an IC, it can feel like you’re not being productive because you’re not building.
An essential mindset shift needs to happen when you go from developer to manager, which is: “My productivity is no longer measured by what I’m building but how much I’m helping others succeed and continuously improve.”
Ultimately when you become a manager you need to appreciate the output of what others are building thanks to how you empowered them.
Eiso Kant recently said on the podcast: “Every engineering leader was at some point building and writing code. And if we go all the way back to that very initial moment when we first started programming, it was because of the love and magic of being able to build something out of nothing.”
I really resonate with this, and I think it helps to understand the struggle of taking those first steps as a manager. I had to come to terms with no longer building - and understand that I’m now an enabler of great things to be built.
It’s not an easy thing to interiorize.
💡 What can help with this mindset shift?
Talking to someone who has already been through this path is really important when stepping into a leadership or management role.
When José Caldeira joined Athenian, my conversations with him really helped, because he went through an extraordinary path at Outsystems, where he started as an IC and became VP of Engineering to a 200+ team of engineers 10 years later. I asked him a lot of questions.
Questions to ask experienced Engineering Leaders:
- How did the transition/opportunity happen? (your decision vs thrown into it)
- What did you struggle with initially?
- What do you still struggle with today?
- What really drives you? (building vs mentoring/coaching)
- How do you manage more Senior Engineers?
- What goals and challenges do you set for yourself?
- How do these goals translate into your day-to-day life?
- Would you ever go back to being a builder?
At the end of the day, you need to understand what drives you: Coaching or Building?
👉 Coaching vs Mentoring: “I would define coaching as helping someone figure out their own way forward. Mentoring is more where you're giving advice based on what you've experienced, but I think coaching is the skill that really levels a manager up and allows them to scale. Because, if you can coach, you can help someone who is different from you.” - Meri Williams, Developing Leadership ep.24
The salary myth.
When the time comes to decide whether you want to become a manager or continue to be a developer, it’s important to note that a manager and IC can have the same compensation, level by level (up to the point of VP/CTO).
Although this is what happens in most companies and in most other functions, it’s a misconception that an engineering manager will make more money than an IC.
👉 You will understand why our salary evolution takes this Y shape, instead of the classic ladder, in the next section. But it’s important to note that some companies do not have this Y ladder.
At Athenian, we believe that there’s no need to become an engineering manager to get higher compensation. Instead, you need to choose your career path based on what you want to be doing, not because of how much money you will make.
The best result in terms of commitment, performance, accountability, and involvement will arise from the overlap of responsibilities and passion, and not from the overlap of responsibilities and money.
So let’s look at how you can make this decision.
Choosing a path.
To start thinking about what software engineering career path makes more sense to you, start by choosing which of the four types of responsibilities below appeal most to you:
🪄 Tech mastery (expertise in some domain and/or framework)
Master craftsman.
🧙 Tech management (architecture, best practices, etc.)
Tech owners are the default go-to for bigger areas (it doesn’t imply being a master craftsman of all areas).
🤝 People management (mentorship, career progression, etc.)
Leaders who want to take care of and shield their team. They are more focused on happiness and motivation.
🏁 Execution management (planning and prioritization, delivery, etc.)
Leaders who are looking for the right processes and organizational setup. Their goal is to answer the question, “how can we deliver?” They have an “executive first” mindset.
Depending on the reality of a company, Tech and Management can be split like this:
What this illustrates is that, when you’re at the beginning of your journey as a business, you might have one person taking over these different roles. However, as you grow, you need to have different leaders for each path.
Examples of possible (temporary) exceptions are:
Small teams: cannot afford more fine-grained responsibilities split (mix between tech and management)
Very highly experienced managers: able to handle multiple responsibilities even at scale (not optimal).
These should happen only during transition periods or if you have unicorn engineering leaders (but this is very rare).
The mapping of the career paths based on responsibilities also depends on the context of the company and how they value an IC and a Manager.
Some companies only have ICs, Team Leads, and Managers.
This depends on how technical the company is.
A company that is highly technical will probably have a balance of career ladders between managers and ICs (the Y ladder), valuing them the same way. In contrast, a company that is not highly technical will have a classic career ladder.
🏎 The F1 team:
If you go to a Formula 1 Garage, you have people who are very skilled at aerodynamics, those more skilled at electronics, and some focused on the engine. These would be the Tech Masters because they are specialized in a specific component of the stack.
Then you have the principal mechanic, who is able to connect all these pieces together. That’s The Architect. He’s not touching any of the pieces himself, but he is much more in tune with the context from a technical point of view and is able to bring it all together.
The People Manager, on the other hand, is the one that cares about mentorship and helping the team stay motivated, work harder, and make sure everyone is feeling prepared before the races.
Finally, the Execution Manager is the one responsible for making sure the car is actually ready to run the race - and win. 🏁
Life as a manager.
Now that I’ve gone through management expectations, mindset, and career path options in software engineering, here’s what my days look like as a manager.
Keep in mind that we are still a small team, so I’m currently doing a mix of tech, people, and execution management.
1) Preparing the engineering org. for scale
- Looking for and interviewing the right candidates, as they will become pillars of our engineering team
- Preparing interested team members for management positions
- Increasing and retaining the level of accountability in the team
- Knowledge-sharing from my time as IC/Manager
- Speaking to all team leads 1:1 every two weeks and making sure everything is running smoothly, and everyone is happy and aligned
2) Execution management
- Working closely with the Head of Product and Head of Engineering Success, as well as other leaders, to make sure we’re aligned on time allocation for customer support, feature prioritization, and company goals
- Iterating on the development workflow: Scaling the team also requires rethinking collaboration and communication processes
- Working closely with customer success to handle incidents and requests as they happen
- Ensure we keep hitting our speed of development and quality goals - this is where Athenian really helps
3) Tech Management
- Brainstorming solutions based on the company objectives
- Making sure we’re building the features that we need at the moment while planning for the future
- Making sure we don’t overengineer, but without doing it blindly by keeping an eye on future needs (i.e. don’t build a car if we need a bike)
Important: You can’t drive your team in the right direction if you’re not aligned with the rest of the executives. This is why my day-to-day at the moment has a lot of moving pieces, and my calendar is filled with calls!
Here’s what a typical week looks like:
I’m very lucky to be working with such a senior leadership team at Athenian, where the quality bar on all functions (from Product to Operations, to Marketing) is really high, and everyone is extremely supportive.
Being in an environment that is not “poisoned” by politics and where people care about your progression is what makes me want to be a better leader, and it really cements the feeling of working towards a shared vision for the company.
Although the path of Engineering Leader is still not 100% clear for myself, I’m experimenting. I have decided to start this quarter with a challenge: “Ok, Marvin, for the next quarter let’s try not to code, and let’s see how that turns out!”
Maybe I’ll come back here for part 2 of this post, to tell you how that goes!
