Principal Manifesto

Edit: in 2020, Will Larson published Staff Engineer, the first book that properly reasons about Staff+ roles. I cannot recommend the book, the articles, and the podcast enough. You can find all about them at staffeng.com.

To extend the tech career ladder, a number of roles have been introduced in the tech community over the past years. Depending on the company and related role and level fragmentation, they might go by different labels such as “Principal Engineer”, “VP Engineer”, “Distinguished Engineer”, “Staff Engineer”, “Fellow”, “Architect” or sometimes, in small environments, simply “Tech Lead”. Such roles are intended to allow progression and recognition for the company’s most senior staff giving individuals the ability to grow above a senior level which is becoming more and more mainstream these days and while whose responsibilities may vary, it is too often labeled as expert programmer with a solid tech background and decent experience on the CV.

Senior engineers might progress their career towards a managerial path (people management) or prefer to stay focused on the tech side of things (the above roles). I have seen people being very good in the roles mentioned above as natural technical leaders: such individuals were great engineers on their own, well respected by the engineers around them, worked well within teams, understood how software should be designed, built and shipped, and often had a decent sense for making the right kinds of product tradeoffs. Such engineers were willing to do enough project management and people development to keep the team/project humming along. Engineers in these roles usually remain pretty connected with the details of the project and successfully manage/influence from within rather than from outside the project.

As a Principal Engineer, I sometimes found describing my role and my responsibilities being too vague at times, with tasks dipping into various topics, especially depending on the need of the company at a particular point in time. For such reason, I list here the expectations and responsibilities of the Principal role in the way I’ve experienced it in my career so far. The document, therefore, represents the Principal Manifesto I stand by.

Principal Engineers should be expected to:

1. Define tech vision 1-2 years ahead, plan accordingly with the teams and promote it across the business.
2. Define and gradually execute a tech roadmap that aligns with the business requirements and demands and have Tech/Delivery/Product managers supporting it.
3. Persuade teams to do the right thing and align on processes whenever possible. Work with them whenever necessary in a collaborative way and with an eye on the status of the progress across the team.
4. Be able to manage expectations with stakeholders and not over-promise.
5. Help to establish a consensus between the engineering group on architecture, patterns and practices.
6. Understand how software should be designed at both high and low-level, built and shipped, considering maintainability and costs.
7. Understand the company tech platform as a whole.
8. Introduce evolutive, safe, and sound changes both from a technical point of view and a tooling & standards point of view.
9. Collaborate across teams when necessary to move projects forward and smooth the edges when a project is dragging.
10. Identify small course corrections to avoid long term debt or failing projects.
11. Call out good work and highlight poor work to line managers.
12. Be identified as professionals ‘to go to’ and be a respected authority on specific projects/areas/technologies by other engineers but also by management.
13. Being trusted in deciding on what to work on and what projects demands dedicated attention.
14. Be able to solve complex problems both small and large and manage projects of all sizes in isolation and in a team.
15. Be able to make sensible and rational decisions (both technical and not).
16. Successfully own investigations of issues impacting the platform and discuss with the relevant teams to aim for a resolution.
17. Coach, inspire and share knowledge with other engineers.
18. Be great at leading by example by being a top contributor to the platform delivering top standards of quality at all stages of the software development life cycle.
19. Promote the company externally cultivating white papers, blogs posts, and public talks.
20. Be a respected authority in the community: open-source contributor, writing blogs posts, books and other material, public talks.
21. Have a proven and recognized history of success.

Similar articles: