The MVP Who Sits Out
Why the Best Principal Leaders Dont Play the 4th Quarter
I was looking at the box scores for the Thunder recently, and Shai Gilgeous-Alexander’s averaging over 30 points per game, he’s leading the league in steals, and he’s shooting with an efficiency that defies modern usage rates.
Now, don’t get me wrong - I am a die-hard Lakers fan. It physically hurts me to write this. But after watching the Thunder absolutely destroy us a few weeks ago, I had to put my pride aside and respect what I was seeing. It wasn’t just a win; it was a clinic.
And if you dig deeper into the play-by-play data of those blowouts, you find the most impressive stat of all:
In their biggest wins, SGA barely touches the floor in the 4th quarter.
He isn’t injured. He isn’t in foul trouble. He’s sitting on the bench, towel around his shoulders, watching the rookies close out the game against my Lakers.
Why?
Because his dominance isn’t about hero ball in the final seconds. It’s about systemic control in the first three quarters. He disrupts the defense so thoroughly, creates so many easy looks for his teammates, and builds such an insurmountable lead that by the time “crunch time” arrives, the game is already won.
He doesn’t need to hit the buzzer-beater because he ensured the buzzer wouldn’t matter.
Now, flip the camera to our world.
We have a completely backward view of what “Principal” level leadership looks like in Engineering, Product Manager and Data Science roles.
We tend to glorify the “Hero Principal.” You know the archetype: The system is crashing at 2 AM, the deadline is looming, and the Principal Engineer swoops in, writes 2,000 lines of complex code, fixes the bug, and saves the launch. We applaud them. We give them bonuses. We say, “Thank god we have them”.
But I’m going to tell you the uncomfortable truth I’ve learned from watching truly elite organizations:
If your Principal Engineer has to save the day in the 4th quarter, they have failed.
True Principal leadership - whether you are an engineer, a data scientist, or an architect - isn’t about heroics. It’s about obsolescence. It’s about playing the game so well in the early stages that the 4th quarter becomes a victory lap for the team, not a rescue mission for the leader.
I’ve been thinking deeply about this transition. Moving from “Senior” to “Principal” is not just a promotion; it’s a paradigm shift. It’s moving from being the best player on the court to changing the geometry of the game itself.
I see this shift happening across three distinct dimensions.
Dimension 1 - They Lead by Example
In his book Staff Engineer, Will Larson talks about the “Solver” archetype. But there’s a nuance here that often gets missed.
A lot of leaders stop “doing” when they get promoted. They retreat to PowerPoint and architecture diagrams. They become “Ivory Tower” architects who suggest impossible designs.
The best Principal Engineers, Product Managers and Data Scientists do the opposite. They get more hands-on, but selectively. They don’t take the easy tickets; they take the hardest, messiest problem, and they solve it with such terrifying elegance that it raises the bar for everyone else.
They lead by example.
From Business to Architecture: They don’t just ask for requirements; they understand the P&L better than the PM, and they design systems that solve the business problem, not just the technical one.
From Empathy to Excellence: They show what “customer empathy” looks like in code. They show what “clean documentation” looks like by actually writing it.
They are the “Gold Standard.” When a Junior Engineer asks, “How good does this need to be?” they don’t point to a wiki page. They point to the Principal’s last PR.
They prove it’s possible. They break the 4-minute mile so the rest of the team knows they can run it too.
Dimension 2 - They Lead by Creating the Environment
Here is a rule of thumb I use: A Senior Engineer solves a problem. A Principal Engineer solves a class of problems.
If a Principal Data Scientist is manually fixing a data pipeline error for the third time, they are failing.
The core of this dimension is creating the environment and the process - what Tanya Reilly brilliantly calls “Glue Work” in The Staff Engineer’s Path - but elevating it to system design.
Think about it. It is incredibly hard for a team to “do everything right” while trying to grow and ship fast. If the process is heavy, or the tools are broken, your team burns out.
The Principal leader realizes that their output isn’t code; their output is leverage.
They don’t just fix the bug; they build the linter that prevents the bug.
They don’t just run the model; they build the MLOps platform that lets any analyst run the model.
They delegate not by dumping tasks, but by building guardrails that make it safe for others to fail.
They lead by creating an environment where the “right thing” is also the “easiest thing”. They are the ones clearing the brush so the team can sprint.
Dimension 3 - Force Multiplier that Makes Others Better
This is the most important dimension, and it brings us back to SGA.
SGA is leading the league in steals, but look at his assists. Look at the open looks his teammates get. When he drives, the defense collapses, and suddenly everyone else on the floor has space to operate.
In the leadership world, Liz Wiseman calls this the difference between a “Diminisher” and a “Multiplier“.
The Diminisher is the genius in the room who makes everyone else feel small. They have to be the one to solve the hard problem to validate their own ego.
The Multiplier is the genius who makes everyone else smarter.
In the Principal World (PE/PPM/PDS), this is the ultimate metric - making people around them better!
Most of their responsibilities are actually about transferring their superpower to the team.
It’s sitting with a Senior Engineer and refactoring code together, not to fix it, but to teach them how to see the patterns.
It’s working long hours with a Staff Data Scientists, not to take over their ADD (architecture design doc), but cut down the feedback loop and let them learn and refine the design.
It’s letting the team present the win to the stakeholders while they sit in the back.
It’s absorbing the chaos and ambiguity so the team can focus on execution.
The “SGA Effect” in engineering is when a Principal Engineer can go on vacation for two weeks, and the team’s velocity doesn’t drop. That means they have successfully transferred their context, their standards, and their confidence to the group.
The Question to You
We need to stop rewarding the arsonist firefighters - the leaders who let projects burn until the 4th quarter so they can be the hero.
The true hero is the one sitting calmly on the bench in the 4th quarter, cheering on a team that is winning by 20 points because of the foundation they built in the first three.
So, here is my question to you:
Look at your current “star players” (or look in the mirror). Are they playing for the buzzer-beater, or are they building a team that doesn’t need one?
#Leadership #PrincipalEngineer #DataScience #StaffPlus #TeamCulture #Management #Multipliers #NBA #SGA #OKCThunder #GoLakers