In Senior Engineer to Staff Engineer, we made an argument that the change in the title signifies a change in responsibilities and requires new skillset.
In beyond Staff Engineer, we went through the differences between Staff Engineer and Senior Staff Engineer. The key takeaway from that article is that Senior Staff Engineer is like Staff but at scale.
What about the level that comes after it? Different companies have different names, but in this article, we refer to it as Principal Engineer.
The word "principal" in English means chief or foremost. It is derived from the Latin "principalis," which means first in importance or chief. This term is used in various professions to denote someone who holds a primary position or an elevated level of authority and responsibility.
Right off the bat, let’s clear out what principal engineer is NOT:
PE is not to act like a school principal and make rules or scold other engineers.
PE is not above other engineers. Using the paygrade card is a symptom of weakness and shows that all other influence techniques have failed.
PE is not a soft role where the majority of time is spent in meetings and talking to people. As engineers, PE’s have a duty to keep their technical “axe” sharp by being hands on.
Just as going from Senior Engineer to Staff Engineer required a new skill (soft skills), the Principal Engineer requires a new skill: business skills.
But what exactly is business skill? How can you master it? And why is it important for an engineer to think about business?
I’m going to use this career ladder which I helped develop:
First, a few caveats:
Theoretically the career ladder maps exactly to the skill level. In practice, however, there are many flaws:
The recruitment process is broken
The applicant's negotiation skill or the urge to recruit them (e.g. when the company is trying to steal talent from rivals) can put someone in a higher level than their skill
There's no promotion process
The promotion process is broken
The promotion committee is biased
The perceived impact is different than the actual impact
There may be personal favors or grudges at play
You may need to have for “years” even though year is not a unit of measurement for experience
The number of levels in a given ladder depends on the size of the company. While startups suffer from the title inflation phenomenon, large enterprises may not have enough titles to provide adequate resolution to signify different expectation levels.
Some companies (e.g. AWS) don’t have Staff Engineer in their career ladder and instead call it Principal Engineer. Regardless of the name, we’re talking about a level that’s 2-3 levels after Senior Engineer.
Hard, soft and business skills are not exclusive. A junior engineer may have a great sense of the business, it just may not be a key part of their job (i.e., it usually doesn’t impact their hiring). Moreover, a Principal Engineer without up-to-date hard skills (e.g., programming) is just as irrelevant.
Promotions often lag behind your demonstrated skills.
Some companies treat the career level as pay-bands not a way to set examples, expectations and responsibilities. For example, if someone’s salary expectations are higher than the Senior Staff level, they may get the Principal Engineer role even though their skill level and eventual impact is at the lower level. This happens for example when the company badly wants someone (e.g., to steal key people from competitors and temporarily cripple their ability to ship products).
Being a level above Staff Engineer, the Principal Engineer has:
Even longer strategic time horizon
Even larger organizational scope and areas of responsibility
Even higher risk of becoming ivory tower and irrelevant! 😉Preening is high visibility low-impact work. Due to the visibility of the role Principal Engineers are even more susceptible to this kind of task than Staff Engineers.
Even more need to communicate complex technical topics to non-technical audience and vice versa (communicate complex business topics to technical audience)
Even more reliance on alternative leadership methods without formal mandate
Even more T-POP 🍭
In simple terms, if the code is a technical solution to a product problem, business is how that product makes money. It involves:
The customers, their needs, alternative choices, and key metrics
Market trends, competition landscape, marketing, and the impact of external factors like economy, politics, etc.
The revenue stream, payment/subscription/sale flows
Strategic investments or decommissioning of technical solutions regardless of their engineering ingenuity 😢
The legal and compliance aspects as well as how to enforce them in technical solutions
More specifically, we’re talking about how the company makes a profit: the difference between what the customers pay and what the business has to pay to run (e.g. cost of personnel, cloud, manufacturing, equipment, tax, office space, coffee machines☕).
Most engineers aren’t concerned with either revenue or profit. Some are concerned with revenue, but only a few understand and influence the profit.
There’s nothing unique about the business skill per se, but what really gives the Principal Engineer a superpower is to connect the business to the technical solutions:
How does Principal Engineer connect business to engineering?
Being the voice of the customer in the engineering room and the voice of engineering in the business room
Aligning business strategy, product strategy, engineering strategy, and technical strategy
The ability to create new technical products that address novel customer needs
Defining the technical optimization priorities (e.g. Service Level Indicators)
Cost optimization to map the business investment into different areas to the return of investment (ROI)
Defining and refining the non-functional requirements (NFR) of different parts of an architecture (e.g. amount of load expected on an online toilet paper shop right before the pandemic)
You may argue that every engineer has these responsibilities to some extent and you are correct. Just as soft skills are not exclusive to Staff Engineer, business skills are not exclusive to Principal Engineer either.
Expanding the diagram that was used in a previous article, all career levels require that skill to some degree:
However, just as soft skills are key to being an impactful Staff Engineer, business skills are key to being an impactful Principal Engineer.
Just like any skill, business is learnable.
Some would argue that soft skill is something you’re born with, but as an introvert who works as a Senior Staff Engineer, I’d argue otherwise.
It’s about finding the right balance. You certainly don’t need to be as business heavy as someone who does it as a full-time job without having to bother with technical and engineering aspects (e.g. CEO), but you need to be much better than the average Senior or Staff Engineer.
Learn the Business Goals: Understand the company's overall strategy, target market, and financial objectives. This will help translate technical decisions into business impact. This part takes time, especially if you’re recruited as Principal Engineers instead of internal promotion. 3L is by far the best advice I got for this phase.
Business Skills Education: Take courses or attend workshops on business fundamentals like finance, marketing, and product management.
Business Reading: Stay updated on industry trends and read business publications relevant to your company's domain and industry. You may find it daunting to go too deep into this area while keeping your main advantage (technical literacy). Again, it’s about finding a balance, not being perfect in an area you’re not formally trained for.
Strategic Initiatives: Volunteer for cross-functional projects that involve both technical and business teams. Many years ago, I volunteered to build a tool for the legal team at a company, which catapulted my understanding of the legislative aspects of that business. I have to admit the initial learning curve was steep because we didn’t even have a common language at the start. 😄I was talking Markdown and Mustache, they were talking PDF and price interpolation!
Learn to Speak the Business Language: Learn to communicate technical concepts in clear, concise, and business-oriented terms. Every company has its own jargon and acronyms when talking business. Literacy in this language distinguishes someone who is struggling to make sense of how money is made vs. someone who is fluent and confident with business.
Regular Interaction: Schedule meetings with business stakeholders like high level product managers, sales, marketing, and customer support teams to understand their objectives, challenges and opportunities.
Shadowing: Shadow business leaders to observe their decision-making processes and gain insights into business priorities. As a principal engineer, you may get easier access to the C-level room or organizational leadership (depending on the size of the company). You may be invited to represent the engineers in the leadership room, but it’s an equally important opportunity to learn how “businesspeople” talk and what are the key criteria when taking decisions.
Focus on "Why" Before "How": When proposing technical solutions, explain how they address specific business problems and contribute to the overall goals. Arguably this is a skill that comes handy at much lower levels in the career ladder, but for Principal Engineer, it’s crucial to have a solid understanding of the business and use that understanding to influence technical decisions. For example, the NFR (non-functional requirements) of a given architectural problem is notoriously hard to figure out without knowing the size of the market, and external factors.
Cost-Benefit Analysis: Evaluate technical decisions considering not just technical feasibility but also factors like development time, maintenance costs, and return on investment (ROI). Again, this is something you need to think about at lower levels, but for companies that have the role of Principal Engineer, you’d expect to find solid answers from them.
Metrics and Measurement: Translate Technical Metrics into Business Impact. Align technical efforts with measurable business outcomes like customer satisfaction, revenue growth, or cost reduction. My favorite tool is Service Levels because it aligns autonomous teams in a measurable way.
Regular Reporting: Create reports that highlight how technical projects, initiatives, strategies and improvements impact business metrics. Present these findings in terms understandable to non-technical stakeholders. Personally, I find this aspect the most interesting part of working with metrics. Sometimes, the act of trying to generate a metric reveals that I was measuring the wrong thing. A good rule of thumb is to ask is it an output metric or outcome metric? Output is all about WHAT we do.
Outcomes align with WHY we do what we do. It's a layer deeper. Unfortunately, the output is often abused as a proxy metric to measure outcome because impact is hard to measure. Especially whenImpact isn't clearly defined
Impact is a delayed metric
Impact isn’t quantifiable
Leadership would rather chase a vanity metrics and have the illusion of control
Engage with End Users: Understand the customer's perspective by participating in user research (UX), customer feedback sessions, or even direct interactions like customer support calls. Regardless of if your company has a B2B or B2C model (or both), there’s someone who pays the money (stakeholder) and someone who uses the technical solution (service consumer). Being the customer’s voice is a superpower in the engineering and high-level leadership rooms. Personally, I was fortunate enough to work as a UXer early in my career which later led me to work as a front-end developer. I may not do user studies every day, but that period (and self-learning) helps me ask the right questions and confidently speak on behalf of the consumers or stakeholders when they’re not in the room. You don’t have to be a UXer, but having a basic understanding of the concepts goes a long way. My favorite book on the topic: don’t make me think
Adopt a Problem-Solving Mindset: Approach technology from the standpoint of solving customer problems, which often leads to innovations that drive business growth.
Understand Cost center vs profit center: Knowledge of how different business operations work and how technology can improve efficiency and effectiveness.
touched on that back in 2022 (paywalled).Cost optimization: optimizing workflows, reducing costs of operations (cloud anyone?), and improving service delivery through technical solutions. Like any optimization effort, cost optimization requires good data. If you don’t have data, start there. See if you can gather accurate data about the cost of running the technical solutions but also how that cost maps to the revenue generated. Once I was doing this exercise and found an entire team of consultants who’ve been paid for 10 months to maintain a system that got a grant total of ZERO request per month! The service was sunsetted, so either they didn’t get a memo or decided to keep their mouth shut and wallets full. 💸
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to days to draft, edit, rethink, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
You can support me by sparing a few bucks for a paid subscription. As a bonus you get access to my WIP book Reliability Engineering Mindset. Right now, you can get 20% off via this link.
If you can’t spare the money for whatever reason, sharing this article within your circles would also help. Thanks in advance.