icon

Transitioning from Senior to Principal

Moving from a dedicated Individual Contributor (IC) to something more senior can be challenging. It’s not always clear what IC can mean, depending on the seniority of the role. Some organizations expect a Principal Engineer to be coding 80% of the time. In contrast, others expect that to be more like 20% or even less, depending on the team.

I have moved up, down, and across the career ladder in my life-long journey of working in the tech sector. The differences across companies are always so fascinating to me, and learning how to operate in these new and unique environments is part of the fun (IMO!)

Recently, I accepted a position at a global SaaS company as a Principal Engineer working within their Infrastructure and Operations team. It is my first FTE (non-consultant) role in a company with over a thousand employees. I was initially interviewed for an entirely different position on the dedicated DevOps team within the InfraOps group. At the time, I was actively looking for more coding-heavy IC roles. After years of being the CTO/delegator at CarmaLink, I had been enjoying heads-down engineering work and getting back into the latest and greatest tech at the hands-on level. Writing good code and shipping it is just immensely satisfying. It’s also nice to shed some of the stress and pressure of having to lead teams and make big decisions that impact a lot of folks for better or worse. It was also important that my family took priority at this time - kids are only young once, and I wanted to be there to help.

There were downsides to this IC-focused approach, however. I’d still pick up on everything a leader would - but I was not in a position to change things. I would drive myself crazy trying to influence people and change the course of the “ship” through what amounted to inception - which, when done indirectly by a single person, isn’t an effective strategy for organizational change. This eventually led to burnout and my resignation in previous IC-focused roles.

The team at this new company that has hired me sat me down and said: “We have no doubt you can take the Senior role, but would you be interested in something where you could have a bigger impact?”

This offer was a pivotal moment for me. I had spent the last few years thinking I should be licking my wounds from CarmaLink’s failure and hiding in the trenches until something appealing came my way. That’s the typical advice:

  1. Lay low after your startup fails and regroup.
  2. Focus on networking.
  3. Look for ideas.
  4. ??? (Try again.)
  5. Profit.

I was confident that I was not ready to launch another tech startup at this point in my life. However, I was ready for an increase in influence (again) and wanted to work with a team that was confident in my capacity to do so.

I had previously been sitting on the sidelines watching, even calling out questionable engineering/product decisions publicly, and what the failures would look like in advance. I have even recently had individuals from previous employers say, “Do you remember what you warned us about last year? It happened this week when we tried to take the product to production, and it failed like you said it would.” Interactions like this have helped rebuild my confidence after CarmaLink’s demise and allowed me to feel prepared for a role where I am expected to get ahead of such problems.

One nice side effect of taking this more senior IC position is that I have been able to spend more time with people. I had always pegged myself as an introvert. Interacting with various stakeholders across Engineering and Product teams has been a breath of fresh air. This skill is a core value (IMO) for a top-level engineer: bringing people together and coalescing around a solution everyone can agree upon that will not sink the ship. Looking at the news, we can see how challenging it is to get anyone to agree these days - and if you have worked with engineers, you probably know they can be particularly picky :)

Much of my success here involves active listening, effective communication, and avoiding traditional power structures to enact change whenever possible. As Principal Engineers, we should focus on cross-team collaboration and building a mutual understanding of where problems lie so we can solve significant challenges before they come home to roost across entire teams. It’s one thing to be a 10x engineer, but with AI and other LLM-driven coding developments - why not focus on trying to be a 100x leader? That’s where I will focus my efforts for the foreseeable future because there’s a real need for strong technical leadership, and the impact can be massive. Whether most companies know it or not remains to be seen - but in my experience, it’s usually easy to identify those who do and those who do not see the value in strong technical leadership when looking at their internal and external technological achievements over the years.

Another nice bonus is I get to write more than just code. Writing has always been something I’ve found enjoyable, and in the Principal role, I get to do quite a bit of it! Grammarly vocab record

- Kevin