Effective Principal Software Engineer
How to overcome the most challenging tasks as a Principal Software Engineer
The role of a Principal Software Engineer differs greatly depending on the company you work for. (If you want to get an insight about the differences with the role and how it fits in the IC track, make sure to check the previous post on the IC track.)
But even if it is so hard to standardise it, there are a set of expectations required that can be more challenging than others.
As a Principal Software Engineer, one main difference you will encounter is on the scope and impact of your work. You will work on organisational programs, across teams and departments. Sometimes, you will be required to go deep into implementing a solution, but it may not be the most impactful way to invest your time. There are plenty of challenges which may sound counter-intuitive at first, and are contributing towards making this role more difficult.
Becoming an Effective Principal Software Engineer
I thought about how I could use my experience to help, so I decided to create and share a list of the most impactful actions that I took to become more effective as a Principal Software Engineer.
Have a priority list
As a Principal Software Engineer you will tend to work on initiatives that expand beyond a single quarter. And you will most likely have more work than what you can do at any given point. This is a common situation to be in, similarly to what happens with a team and its backlog. It is important to be strict with your list of priorities and align them with the organisation objectives regularly.
Manage your focus time
You will be expected to engage with multiple teams and stakeholders. The risk here is to spend all your time in sessions and meetings and not have enough time during the week to focus on the actual work you need to do.
I will go to standups or team sessions when I actually have an update to share, or I want to get context about the work that is going on, but I will not attend every meeting always.
Influence
Influence does not mean you are telling others what to do or how to do it. It is about getting alignment and recommendations by having discussions on RFCs or technical sessions. To be able to influence, you need to build trust, and the rest of Software Engineers need to see you as an expert. This point is hard to achieve because it takes time to build trust and have the necessary impact in an organisation for others to accept and take your advice.
Work on the most difficult problems
This is challenging, but the most rewarding part of being a Principal Software Engineer in my opinion. You will have the chance to start working on problems that have high impact and many unknowns early on. I enjoy working on those types of problems, and I think it is a great skill to develop as a Software Engineer which will help you go further and grow faster.
Before diving in, think if you can delegate it
As an Individual Contributor you may be inclined to jump into a problem and start to work to get a solution. This may work and will be rewarding as a Software Engineer, but being a Principal Software Engineer means that you need to focus on problems no one else can focus on. So even if you want to implement the logic, if you have higher priorities and you know the work can be worked by a team and maybe help a Senior Software Engineer to grow, then you may be better off delegating it.
Keep up to date on teams’ work
You need to keep up to date with decisions and pain points across engineering. You need to allow teams to make their own technical decisions, making sure that dependencies with other teams are considered and that the technical decisions will be aligned with longer-term roadmaps. Personally, what works best for me is reviewing RFCs, PR’s and engaging in technical conversations. You need to be aware of the current problems.
Help unblocking teams
There will be times when teams will struggle to deliver. It may be because of lack of experience, not being familiar with the technology or not understanding how to integrate with external services. It may be because of a slow company process, or because they are waiting on help from other teams. In those situations help them to become unblocked. This is one of the best ways to be a force multiplier.
Have 1 to 1 with Software Engineers and Managers
Principal Software Engineer is a senior leadership position that is taking care of Software Engineers in the organisation (among other things). Of course, a Manager will give insights and work on their career progression but you can also help them by providing feedback and getting insights about their work and concerns. You should work with Managers and talk about potential areas of work that can help Software Engineers get the most of their personal growth.
Mentor
Mentoring other Software Engineers and Managers is a great time investment. Not only you would learn about helping others, giving career guidance and transferring skills but you will also be investing in the future of the organisation by coaching future leaders as well.
Help with interviews
Invest time to understand how the interview process works, and help describe the pipelines and technical sessions. Create technical exercises with their documented solutions and define templates to score them. Help define the role when opening a new hiring position.
Manage expectations with other departments
As a Principal Software Engineer, you may need to engage with other departments such as commercial, sales, finance, etc. A Product Owner may be taking care of understanding their requirements, but you need to balance their expectations with what is possible to achieve.
Be the Software Engineer sponsor at C-level sessions
You will be one of the most senior IC engineers in the company and you will need to make sure that all voices across the Software Engineering organisation are represented when discussing initiatives in leadership sessions. Having the right time to work on tech debt, training, observability, incidents and software engineering standards are important initiatives that require time to drive them. Be the Software Engineer sponsor when defining the company objectives.
Closing thoughts
The list presented is just a subset of all the work that a Principal Software Engineer position entails but it has been really useful for me to navigate and manage the unknown expectations of the role. Like many other positions, there is no real training available and the majority of those learnings have come from experience, mentorship and reading.
What is your experience on being an Effective Principal Software Engineer? Please leave a comment below
If you liked this post, consider subscribing, thanks!