PETALs in Engineering Management
Principal Engineers That Approve Leave, or how Engineering Managers end up not managing engineers.
At an old job my title was Software Engineering Team Lead, or SETL. In most other organisations I would have been titled Engineering Manager. This was the bottom rung of the Engineering Management track[1].
In this organisation the technical counterpart to my role was Principal Engineer[2]. The Engineering department here rated technical skills far above all others, and had a habit of promoting engineers to Principal primarily because that Engineer was good at shipping code. Many staff had long tenure and the organisation ran out of Principal Engineer roles, so when faced with a Senior Engineer who needed promotion (usually because of them shipping code, but often because they had stuck around long enough to earn it) the organisation would often create a Team Lead role for him[3]. This meant you often ended up with Engineering Managers[4] who insisted on being the smartest coder in the room and who cared more about peer reviews, writing code and spending all day in their IDE. There were many cases where these EM’s didn’t even do 1:1’s and weren’t expected to—they only performed the very basics of line management.
Unfortunately this came to define what “good” looked like in the role: strong technical skills, no work put into unnecessary people skills, and (almost exclusively) male-presenting. This mix of attributes led to toxic behaviour towards women. Ignoring valuable-to-the-team people skills, poor coaching, and biased interview practices led to women being treated poorly as individual contributors, and explicitly not promoted to Team Lead roles because they “weren’t technical enough” (from all the other opportunities they had been denied).
I call these kinds of managers PETALs, or Principal Engineers That Approve Leave. Firstly because SETL (settle) and PETAL rhyme, obviously![5] But mainly because this model often leads to a fragile sort of toxically masculine[6] approach to engineering management, squeezing out and discounting the vitality in what is usually the domain of the “soft” (human) skills.
Sadly this is a model I’ve seen play out in multiple organisations. Strong engineers are “promoted”[7] into Engineering Manager roles because they’re “good engineers”, and absent strong leadership, they stick to their engineering work and forgo good management practice. The organisation often supports this because they are busy and want to (need to) ship features, so what they value most are coders. In these leadership-poor organisations managers like this stick, are promoted, have impact and reinforce that toxic tech-first, diversity-last culture.
Yes, there is room in teams for PETALs—some teams need strong technical leadership and minimal people management because there is support outside the team. This is a useful variant for structuring some kinds of teams. You can tell that this variant will work when the organisation has a strong culture of people management and puts work into developing people skills in leaders of any discipline.
But when you see a large group of PETALs you have a solid red flag that this organisation believes coders are for coding and don’t understand the care a good Engineering Manager brings. It can’t imagine that supporting leadership and management development inside of the individual contributor engineer track unpacks the value of diversity in a team, and loses out on the benefits those strong human skills bring to the whole team in ways more lines of code never could.
Endnotes
1: I say “track”: A minority of sub-departments had two layers, Software Engineering Team Lead and Engineering Manager (to use the common terms Engineering Manager and Senior Engineering Manager). The majority of sub-departments had SETL as the only step on the EM ladder—these Team Leads generally reporting directly to a Product Manager. ↩
2: This is that common pairing you see in engineering departments: Strong Tech and Strong People working closely together. ↩
3: I am throwing shade here because 94% of Team Leads (reminder, the first rung on the Engineering Management ladder) in this company were male identifying. ↩
4: And this happened even with the role above meant for Senior Engineering Managers. I saw too many people with long service, no direct reports and sitting with what were meant to be senior people management roles because they’d built some vital system a decade ago. ↩
5: 
↩
6: You don’t have to be male-presenting to be a PETAL, that’s just the majority of my experience. ↩
7: Instead of seeing it for what it is: a lateral move into another track with some overlap. ↩
