hjf.io

Good Principal Engineering

1st Dec - 2023

Career

Career as a software engineer is an interesting topic. Largely because we all want to sling code and not cause an outage. I’ve spent a lot of time thinking about where to take mine recently, and there’s a few things at play:

  • Generative AI: Will there be roles that engineer software in the future? Is this just 2023’s NFT?

  • Remote Work: With workplaces around the country transitioning to remote or hybrid work, there are more opportunities to work in various roles without having to uproot your life.

  • My own performance: I’ve been working at a new, large, company for a while now. The feedback has been excellent, potentially opening more opportunities here.

I’ve worked in various facets of the engineering world, including Full-Stack Engineering, Cloud Engineering, Security Engineering, and leading teams. Currently, I’m a Senior Software Engineer working in a DevOps/Backend team.

At this point in every engineer’s career, there’s a fork: Stay technical or get in to management and leadership. I’ve spent some time in my career managing individuals and leading teams, so I asked myself, what would being a Principal Engineer look like?

One thing is certain: it isn’t a simple level-up. It’s not about being a “better” software engineer than someone else, and it’s not the difference between Gandalf the Grey and Gandalf the White—although it might be more appealing if we all got to wear costumes.

During my tenure at this workplace, I’ve been able to work with some excellent Principal Engineers - and some not-so-great ones too.

What is Good Principal Engineering?

Principal Engineers utilize their knowledge to establish standards and principles for the organization to follow. They may do this through documentation, drop-in sessions, or by working closely with teams.

Floating About

A Principal Engineer is a beacon of knowledge, and they act like one. They are visible and make themselves so. They float between teams, finding out what teams are up to by joining their Agile ceremonies, or liaising with engineering managers.

They operate on a push mechanism, not a pull mechanism. That is: once they understand what a team is up to, and if they can add value on feature X, they reach out to the engineers working on X and help them get it through.

Bonus points if X aligns, or could benefit from being aligned with, the standards they set out.

White-Belt Mentality

The term “white-belt mentality” refers to a white-belt in a martial art. They want to absorb all things. They’re not at the top of their game, but they oh-so want that black belt.

Principals have this. They despise walled castles and yearn to be boots-on-the-ground again. They achieve this by working with other engineers, learning from them, and imparting their knowledge.

They take you with them on a journey. If you’re working on X and they’re working on something similar, they’ll take you for a ride. If you’re working on APM for a suite of serverless functions, they’ll pull you in to look at some of the profiling techniques they’re figured out.

Skillset

Although I’d said that the different wasn’t just a level-up, you do need a breadth of skills, with some depth to be a solid Principal Engineer. They are technically excellent. This doesn’t mean you’re perfect at everything, it means you’re strong in some areas, and ok in others.

I’ve worked with some Principals with every AWS certificate under the sun. They were an expert at Terraform. Their software design? Diabolical.

Every Principal shares a couple of main skills: They are masters of communication. They leave their ego at the door. They want to spread technical excellence and reinforce that through the organization, wanting the best for the engineers in their organization.

Conclusion

Principal Engineers are chatty individuals that want to collaborate and sew seeds of technical excellence wherever they go. They want to learn and actively get involved. They don’t stay in their walled castles (unlike enterprise architects).

For me, I’m loving life as an individual contributor. I’m growing my skillset still, but I’m leaning more towards management, because I love growing other engineers.