Transitioning from middle management to individual contributor
This post is a personal retrospective of my journey as an individual contributor (IC) software engineer, getting into engineering management, and transitioning back into an IC role. I also highlighted several inflection points in engineering/management career paths in small/medium-sized companies. You might find valuable bits here and there if you’re also working in software and debating between IC and management roles. However, this is highly subjective and circumstantial, so your experience might vastly differ.
Why is this my first post?
Ironically, when I created this blog, I assumed I would write many posts on related engineering management topics, such as people management, hiring, and designing career ladders. Eventually, when I become a Director or a VP, I will expand the content to strategic tasks and long-term vision setting and manage several managers.
That didn’t happen.
The most obvious warning sign that indicated that my original idea was not going to work was the lack of content on this blog. Below is the very first WIP post placeholder that I have just deleted:
The placeholder for the very first post was nothing about managing people but about building things.
How did we get here?
Getting into management
After completing my undergraduate study, I worked in various engineering roles as an IC. I went from a complete junior in 2010 to working part-time between 2012 and 2014 while completing my Master’s degree. From 2014 to 2016, I worked as a mid-level engineer. In 2016, I joined an accelerator programme called Entrepreneurs First in London. After a few unsuccessful attempts of “starting working on an idea” – I think this deserves a future post at some point – I joined a start-up as their first employee, becoming officially an “Engineering Lead”, a title that had several different meanings during my stay there.
Misconceptions on career trajectory and seniority
At this point, up to 2016 or so, the first significant misconception I had was that I thought I was above the senior level with all the experience under my belt. I will not dwell deeply into this as it’s a complicated subject. What is a “senior” engineer? Is it relative to every engineer in every organisation? Does being a senior for too long mean many missed opportunities and limiting someone’s financials?
My second major misconception was that the management track was the only viable career path for a software engineer beyond the senior level. I still believe that technical management is the only growth opportunity for a senior engineer in a company where the engineering organisation is small. There might be exceptions when a company is exceptionally technical and has multiple specialisations where post-senior IC roles exist. However, for most companies, separating the technical and the management tracks does not make any sense financially and operationally.
I don’t blame myself for having these misconceptions in 2016. Back then, I had never worked for companies with a large technical organisation, which limited my understanding of how the industry worked. In hindsight, I should have joined a few larger companies earlier in my career to have a more balanced view of the career progressions possible in software engineering.
Early stages - What am I?
The beauty of working at a start-up as the first employee is having more freedom to define your role until the company grows to a specific size. When I started at the early-stage company in 2016, at least for the first couple of months, little management was needed. There were a lot of challenges to be solved, a minimal budget, and very tight time constraints. There were constant puzzle-solving activities but a very minimal amount of management activities. There was no money to hire anyone, so even though I had a manager-ish title, I was more like a highly influential engineer.
Subsequently, some funding came along, and hiring became part of the puzzle. At this point, life in engineering with fancy titles of an early-stage start-up became interesting. I was still expected to personally make sure that “things” were working (note that I’m not calling them “systems”; I think calling software “systems” built at a start-up within the first few months is a massive overstatement), and at the same time, I was expected to start interviewing people and hiring them. The problem was that I had a limited amount of mental energy. I had to channel most of it into technical work to ensure things got done. However, the people I hired had rightfully wanted me to spend more time providing them with learning and growth opportunities. Unfortunately, I had to focus most of my energy on building things and couldn’t give enough support to the people I hired.
It was quite a schizophrenic situation, and I made some terrible mistakes that I’m still regretting. Eventually, I realised that managers could affect people’s careers (especially when they are more junior), and even with coaching – unless you report to a seasoned people manager – you will mess things up.
The pressure builds up in the middle
Once a company reaches a certain level of maturity and size, mid-level engineering management becomes available. Starting as a mid-level manager is much easier when someone joins an established company where management has laid the groundwork. When someone has witnessed a company grow from just a bunch of people sitting around a desk into this level from the inside, they may face some challenges. At this stage, companies, especially VC-funded ones, prefer to hire directors and VPs with a particular pedigree. Consequently, early-stage employees usually end up on the technical lead or manager level, and the founders/board will hire the upper layers of leadership externally, which might lead to resentment and a temporarily unstable political environment until the mid-level roles are adequately structured.
When someone gets to this stage with an engineering background, there can be quite a lot of struggle of how much time should be spent on technical tasks (e.g., Why is this technology used? Why is this designed this way? Surely we can improve this thing!), versus people-related challenges (e.g., Do we have enough people? Do we have too many people? Who do we need to let go? Who do we need to promote?). To add to the complexity, sometimes product- and project-management-related problems creep in (e.g., When is this thing needed for customer A? Can customer A be satisfied with something less complicated? Delay this and that! We need to talk to this integration provider!). Finally, even some operational challenges can appear (e.g., We need to coordinate these external people! A standard requires us to do it this way and comply with some new regulations!).
This mix of responsibilities is challenging. Sometimes, there are not enough people to take ownership of some areas, and as a middle manager, it’s your job to keep things running. At the same time, you must be careful not to put yourself on the critical path for any crucial deliverables. In larger organisations, there are separate middle managers for all the above, and even in smaller organisations, people help out with many operational and project management tasks. Still, the responsibilities of a middle manager will be much fuzzier than a senior engineering role.
Climbing the management ladder
Above middle management, things get a lot less technical and more political. Managing managers also means working on organisational structures and team composition, coordinating with upper management on mid- and long-term strategies, understanding legal and financial obligations, etc. It also involves regularly updating the CEO/CTO/board on the organisation’s health.
Someone other than me should write about these responsibilities. I only had a glimpse into them throughout my career so far. I experienced that on this level, technical skills are the most effectively utilised as a filter to understand where the short/mid/long term focus should be and as an additional layer of trust so the mandates given to the engineering teams are not questioned.
What do I enjoy? An honest self-reflection
“What do I enjoy doing?” I forgot to ask myself. As I assumed more and more managerial responsibilities, I felt less enjoyment of our team’s successes. Every win became a responsibility, and I constantly thought of how to communicate to ensure everyone involved was recognised and rewarded. When there was an opportunity to grow the team, I got anxious instead of celebrating the increased scope and responsibilities. I could only see the new liabilities with an increased team size.
These are the responsibilities of a manager; however, I could only get a little enjoyment out of them. I enjoyed seeing people grow and even mentoring people. However, I felt a hole inside me that kept growing more expansive, and every day, I had to muster even more energy to continue working.
All of these symptoms sound like a classic burnout. Burnouts, however, are like any other illness - they differ in shape, and the underlying symptoms can be vastly different from person to person. I was fortunate and had the support to receive professional coaching where I could work with my coach to understand what was happening in my head. After several sessions of mental excavation work, I had a lightbulb moment. I did a meticulous internal accounting exercise, taking a 37-year walk down memory lane, collecting all the instances where I felt thrilled and satisfied with what I achieved, and eventually filtering down to activities related to solving problems.
The pattern I discovered – matching with even some very early memories – is that I felt tremendous enjoyment from solving problems with tools. These moments, of course, involved working with people and helping people. As a software engineer, I had great satisfaction talking to potential customers, understanding their problems and then coming up with a technical solution. The critical element is that I used, designed, or understood tools to develop a solution for problems in these scenarios. Once I realised this, I knew I wanted to return to the IC track and work as an engineer.
Exercises like this can be pretty brutal. They make you question yourself, your values, and your integrity: At any particular time, were you communicating your values and goals according to what you are? Of course, we can’t be ultimately ourselves in our professional life. We are all wearing several masks to function in a work setting. Getting out of our comfort zone and doing things we don’t like is sometimes necessary for professional integrity and progress, and there is nothing wrong with it. However, if someone completely stops wearing a mask that plays a vital role in getting satisfaction, they will not be able to perform well after a while. With sufficient help (a coach or an experienced mentor), exercises like this are worth it. Sometimes, people need self-alignment and calibration to re-discover what truly works for them.
The path forward
There is a lot of overlap between senior engineering and management. There are several books written on this topic, both management 1, and engineering 2 3 4 focused ones. People also change over time, and who knows if I might get back into management one day, but perhaps approaching it from a slightly different angle. However, I’m delighted that I’m diving deep into technical work again.