Principal Engineer

I'm a Staff Engineer in the satellite telecommunications industry where I am responsible for the strategic success of the software products in my department. My organizational responsibilities and weekly calendar align almost perfectly with the . I'm sure that it will come as a surprise to no one that getting to this point in my career was an intense and conscientious journey. I am self-taught, I fell in love with programming as a child, and I have never attended a University. Things are not even close to perfect, but I am happy with my career so far.

My day-to-day work does not involve much programming, but I spend the vast majority of my time communicating with Tech Leads, Scrum Masters, PMs, TPMs, EMs, etc. to coordinate and accomplish different tasks. The rest of my time is split between communicating and aligning with high-level product stakeholders, such as my boss, and mentoring engineers. When I do code, it is because there is some experiment I want to run, i.e., I might create a prototype of a new product or feature that could massively impact a departmental OKR.

Outside of my day-to-day work, I dedicate as much time as I can to learning and practicing new technical (programming, cloud), professional (LinkedIn Learning), and domain-specific (satellites, AI) skills. I also consume a lot of content here on Taro and I often participate in company and community programs that I believe in (change maker programs, diversity and inclusion programs, etc. as a participant or as a coach).

I would love to have input on this aspect of my career as a Staff Engineer who would like to be a Fellow one day. As I make progress in my career, I find that (obviously) the expectations others have of me, in regard to being at the forefront of technology and really knowing what I am talking about in domain-specific (science-heavy, business-heavy) topics, have grown exponentially. I've already adapted my approach to developing domain-specific skills, for instance, instead of relying solely on MOOCs, I also now have regular sessions with domain experts (business folks with advanced industry-relevant university degrees), something my boss encourages and expects me to continue to do. I have now also considered the prospect of going to university myself, something my employer would sponsor.

So the question is, how can I best invest my personal development time so that as I progress in my career I can continue to meet, or even surpass, exponentially growing expectations?

I'm sure someone will have a great idea of how to approach this challenge. Also, there is a quote I appreciate from Alex Chiou that gives me hope that I can do it.

It wasn't due to natural talent or anything - I'm honestly not that smart.

How does it differ from an entry level engineer to the head of engineering level at each of the levels, given the scope grows as well at each level?

• Software Engineer
• Senior Software Engineer
• Tech Lead
• Staff Software Engineer
• Principal Engineer
• Head of Engineering
• Director of Engineering
• Vice President
• CTO

How do each of the levels ensure they are onboarded as quickly as possible to have maximum impact ?

I just joined Target at a Principal level. My manager is spread very thin and wants me to take initiatives and has told me to start networking heavily in the first few weeks. My plan is to create an Onboarding doc and share it with my manager. I'm going to use this doc to manage expectations and use it to review together 3 months down the line. How can I structure this doc? What pieces of information are more relevant/vital for such a doc. Any pointers?

1. How do pull requests and pull request comments look like with an increasing level of seniority?
2. Are pull requests for senior engineers not expected to have any comments for improvements? If yes, then what kind of comments should be there?
3. Also, have seen some principal engineers not sharing their pull requests as they are quite high in seniority and merging it directly. Do you recommend that? If not, who should review PRs for very senior engineers if the team does not have engineers at that level?

I've been debating this though for a while. Is it worth it to go for a principal role (61 -> 62 -> 63 -> 64) or just go and build something your own