---
type: "blog-post"
title: "Advancing career"
description: "This blog post reflects on the author's career journey in software engineering, detailing the various roles they have held and the challenges they faced. The author shares their realization that they need to take a more deliberate approach to their career growth and decide on a particular area of expertise. They also discuss their experiences as an inexperienced senior developer, including their decision not to fight for a higher title and salary, and the subsequent career limitations that resulted from this choice. The post concludes with the author's decision to transition into platform engineering and the benefits and challenges of this move. Overall, the post highlights the importance of intentional career planning and the potential career limitations that can result from not advocating for oneself."
draft: false
date: "2023-04-01"
authors:
- "kjuulh"
tags:
- '#blog'
---

# Introduction

My current challenge is figuring out how to advance my career, which directions
to take, and what options to consider. During my studies and at the start of my
career, I wanted to discover what type of work I enjoyed and was suited for.
Although nothing is set in stone and there's no perfect choice, I explored
various areas to find my niche.

I've already tried several things, including software engineering roles such as
mainframe development, cryptography. I've also been a tech lead for feature
teams, focusing on cryptography-related areas such as authentication for complex
systems like OpenID Connect, Webauthn, and custom signature protocols. I've
worked as a senior platform engineer, focused on developer tooling and general
operations tooling, and as a data platform engineer, maintaining and creating
strategies for sustainable data platforms. Additionally, I've contributed to a
variety of open-source projects over the years.

These experiences have given me different perspectives and helped me identify
what I want to pursue on a deeper level. Until now, I've simply taken the
opportunities available to me in various companies, regardless of how good or
bad they were. I consider myself an agreeable person, and I've been fortunate to
have had many opportunities come my way. However, this approach hasn't been
ideal for my career growth, which is why I'm writing this blog post to reflect
on my approach.

Until now, my goal was to gain experience in different areas of product
development and software engineering by learning from experienced peers.
However, I realize that it's time to decide on a career path and focus on a
particular area of expertise. Although I've enjoyed most of the staff-type roles
I've had, I didn't prepare for them, and I wasn't always compensated for them.
Therefore, I need to take a more deliberate approach to advance my career.

Fortunately, I have a willing mentor, supportive peers, and an understanding
manager who I can be transparent with. So, it's an excellent time for me to
tackle this issue.

If you're not interested in my history, feel free to skip to "Deciding on a
career path."

## Immature senior

I have a unique situation, and I consider myself lucky with how things turned
out. Right after completing my bachelor's degree, I got the opportunity to
continue working for the company I had interned with as a student worker. They
moved me to a new team as an Associate software engineer, which was essentially
a Junior software engineer position.

Although I enjoyed working as a mainframe programmer, the outdated and defective
tools made the experience unpleasant. Therefore, when I began working with C#
and Typescript, I was thrilled. However, the new paradigm took some getting used
to since I was accustomed to systems development in C and PL1. Within a few
months, I was asked to join a new project, which I accepted despite having just
moved to a new team.

The project was a greenfield project on a new internal infrastructure platform
built on openshift (Redhat kubernetes), with a backend in Dotnet and a frontend
in React. I was assigned to a split team that already had some developers
working on it and a tech lead. Due to various reasons, I found myself taking
over the reins of the React and Dotnet work. Even though my title was still
Associate developer, I ended up doing the same job as a senior developer.

We hired interns and student workers at this point, and I also mentored them.
However, being a fresh graduate myself, it was challenging to teach someone else
the ropes without having much experience or forming my own opinions.

As time passed, I became increasingly involved in the project, taking on more
leadership responsibilities. I also did some hardcore architecting to get the
project audited and approved, along with a few other skilled team members. The
project was launched and received positive feedback, despite being built by
relatively inexperienced people. It passed various audits, pentests, and
refinement over a year, and we even received compensation for the extra effort.
However, I didn't want a higher title, as I didn't want to be perceived as an
inexperienced senior, even though that's what I was.

This decision turned out to be a mistake because I had to switch jobs before the
project was put in maintenance mode due to some other circumstances. My new job
only recognized me as a software engineer, and I was placed in a position that I
didn't care much for, given my years of experience as an engineer.

This was my first significant internal conflict as an engineer, and it was a
result of my inexperience as a senior developer. I had the expertise and was
used to taking on a certain level of responsibility, but I lacked basic skills
in other areas. Instead of fighting for a senior role, I took a software
engineer role, which was not a good career choice. I should have sought a pay
raise when switching jobs, especially since I have the ability to pick up
various responsibilities quickly. I ended up doing the work of a senior
developer for a standard software engineer salary.

In summary, a senior developer can independently maintain, operate and iterate
on a product while providing guidance and consulting for other developers in the
nearest teams. However, due to my inexperience in certain areas, I ended up
doing the work of a senior developer while being paid as a regular software
engineer.

## Move to platform engineering

I was becoming tired of working on feature teams as it lacked the depth I was
seeking. Handling tickets day in and day out was burning me out, and my
motivation was waning. My top priority was being excited about going to work.

After a great conversation with my current manager, I decided to accept an
internal transfer to the platform engineering team. This move is a step up in my
career, and it feels like platform engineers are more specialized and operate at
a different level than other types of engineers who deal with product
development more closely.

I love the work of creating products for other developers, getting feedback, and
having a close feedback loop. Usually, I come up with ideas, create a tool, use
it myself for a few weeks, work out the bugs, release it, and get feedback.

If you've ever worked on a feature team, you know that it can take months to
years before a product is ready for consumers.

Working with open-source software and building a great product has resulted in
some great synergies. I have also been working on outreach and a whole host of
other things that have helped me grow as an engineer.

Although I still maintain a few products on the side, one of the things holding
me back from working on a team is the bureaucracy in teams and organizations. I
have found that it is hindering my progress as I need approval for everything.
Currently, I am working with my mentor to find a balance.

## Dataplatform fixing

Due to some circumstances, our data platform team was let go, and my manager
asked me if I wanted to work on getting the data platform back on track and work
on it for a few months. I accepted, and together with an SRE, we worked on it
for the past few months. We have just winded down the project, and it was a
great success.

## Deciding on a career path

As such, I have completed what I set out to do - I've explored all the major
software engineering areas that interest me, and now I have to decide on my next
step. While I'm not interested in the management route, there are several
options available to me as an individual contributor.

### Category

When deciding on my path forward, I need to consider what role I want to work in
and how I want to collaborate with a team and products. At a higher level of
seniority, these factors are intertwined and more complicated.

Some recent posts have categorized senior roles into different types such as
Fixer, Right hand man, Tech lead, Architect, and so on. However, these
categories are on a spectrum and there may be other options that better suit me
or my organization.

In particular, I am interested in two roles: Fixer and Tech lead. Although I
currently work as a Fixer, I have also worked as a Tech lead before. To better
understand these roles, a brief description of each would be helpful.

#### Fixer

A fixer is a person who is called upon to solve critical issues within a
particular area of expertise. For example, an expert in server infrastructure
may help teams with problematic projects or specific business goals on a
case-by-case basis.

While the term "fixer" might conjure up the image of a 10x engineer who can
solve any problem, it's important to note that this is not always the case.
Rather, a fixer is simply someone with a great deal of experience and deep
knowledge who can guide a team to solve the problem at hand.

Once the issue is resolved, the fixer will move on to the next project, leaving
the team to continue their work.

#### Tech lead

The tech lead role is typically more static than the fixer role. A tech lead is
responsible for the technical strategy of a single team or area, and has a
variety of mentoring capabilities to guide the team in the right direction and
be of service to the team. This person typically possesses a mix of development
skills, architecture skills, management skills, and more.

The tech lead role, along with the architect role, can be problematic as they
share names with roles often found in a company. However, it's important to
focus on the idea of the role itself rather than any specific title.

As the name suggests, the tech lead is a leader of technology, and all the rules
of leadership can apply here. This can include being an active or passive
leader, a servant leader, a conductor, and so on.

### Speciality

When it comes to choosing a specialization, there are two main factors to
consider: the technology or business domain you want to focus on, and the level
of specificity you're comfortable with.

The more specialized you become, the more the balance will swing towards
compensation, but the fewer job opportunities you might find. On the other hand,
the less specialized you are, the more job options you'll have, but the
compensation might be lower.

It's important to find a balance that works for you. However, there's also an
"uncanny valley" to consider. At a certain level of seniority, if you have a
very niche specialization and high compensation expectations, you might become
unattractive to most companies.

For example, if you have the experience of a CTO and specialize in database core
contributions, it might be challenging to find job opportunities in the general
business market. In this case, you might need to get in early in a database
company or make yourself more attractive to other teams.

## Decision

Currently, I find the fixer role more enjoyable because of its spontaneity and
because it aligns with the work I have done throughout my career. However, to
advance my career, I need to decide whether to specialize for a company or for a
technology, which may or may not be compatible.

For instance, as a fixer for Hashicorp, specializing in Golang and developer
tools would work well. But for other commercial companies, specialization may be
required in specific technologies or in business domains such as payments or
card infrastructure, which could limit my job prospects.

I am interested in a wide spectrum of technologies, but my interests lean
heavily towards pure technological capabilities. This will limit my earning
potential and may make it difficult to find a job, but it is a sacrifice I am
willing to make because I am comfortable with my current job and growth
trajectory. I am willing to build my network and wait for the right opportunity.

Therefore, my aim is to become a fixer specializing in platform engineering,
with expertise in Rust, Golang, Linux, PostgreSQL, cloud native enablement, and
infrastructure. In this role, I can solve platform-level problems often found in
the backbone of tech companies and focus on enhancing the effectiveness of
interacting with the platform, while also being able to solve business-critical
problems that affect the security, productivity, or availability of the
platform.

My pitch for this role is that I am an engineer who can solve common pain-points
associated with the platform and be of service in solving business-critical
problems.

### How to get there

To achieve my goal of becoming a fixer specializing in platform engineering, I
plan to pursue multiple avenues:

- _Work_: I will seek out tasks and projects at my current job that are related
  to my goal, and work with my manager to create a plan to get there.
- _Home_: I will dedicate time outside of work to specialize in the different
  areas of platform engineering and deepen my knowledge of them.
- _Events_: I will attend industry events and participate in speaking
  opportunities or publishing work to expand my network and establish
  credibility as an expert in my field.
- _Open Source_: I will contribute to open source projects to gain practical
  experience and establish a presence in the community.

While I don't expect to reach my goal quickly, I want to start taking steps in
the right direction. Removing any obstacles at work that hinder my progress is
currently my top priority.
