POST: People, Operations, Strategy, Technology
A model of software leadership strengths
Jocelyn Goldfein taught me a model for thinking about software leadership strengths which I’ve found useful for many years. Though no model is perfect, mental models give us a framework by which to anchor ideas. Models can shift our perspective, helping us see solutions or opportunities more readily. I’ve found the POST model of engineering leadership enduringly useful.
Engineering leaders can be strong in at least four domains:
People
Operations
Strategy
Technology
The idea isn’t to try to be bulletproof on all of these. Instead, leaders excel when they’re very good at even one of these domains. In fact, one might argue careers go much further when a leader is disproportionately strong relative to their peers in one of these domains as opposed to passably competent in all of them.
People
This involves:
Who to hire / who to fire. Deciding who to hire is increasingly difficult the higher up the position you’re filling. Figuring out whether an SDE II should be hired or fired is relatively easy because the metrics by which they should be judged are clear and the lines connecting actions to results are direct. Choosing whether to hire or fire a VP Eng is far more difficult because the lines connecting actions to results are highly indirected. The more senior a role, the harder it is to know whether a team succeeded because of their leader or despite.
Attracting the best talent. It’s already hard enough to have an accurate sense who to hire… but truly great leaders have an ability to attract top people. This goes far beyond compensation, since the best people rarely think about compensation as a key criteria for what to work on. It’s about the ability to instill a belief in a compelling vision, the leader’s capability to realize that vision, and the possibility of joining other superstars.
Motivating coherent action. Paraphrasing Eisenhower: “Leadership is the art of getting people to want to do what you know must be done.” Great leadership is about inspiring action towards a shared goal.
Resolving conflict. Whenever you assemble enough people together, there will be kerfuffles, and perhaps even the occasional fisticuffs. Deescalating and resolving these is a skill all its own.
Giving impactful feedback. Great leaders can identify and articulate what’s blocking someone’s growth. Furthermore, they convey that truth in a way that’s accepted by the recipient.
Leaders who are good at this are essentially People Whisperers. It’s art, not science. Basic competence here can be taught, but to be a true outlier in People requires innate talent.
Operations
Organizations are complex machinery. Making them run well requires a skillset that runs deep and takes decades to master because so much of operating well requires business process insights rarely written down. A knack for operations thus often presupposes years of experience. Even so, some leaders are much better at this than others.
Operations involve:
Second-order thinking. Great operators are good at “building the machine that builds the machine.” They are root-cause thinkers. They think in systems, not by individual cases.
Principles and prioritization. Because great operators think in systems, they guide their decisions by principles and not by anecdote. Uniformity and regularity become paramount to scaling. Clarity in prioritization further smooths operations.
An orientation toward details and metrics. Leaders who excel at operating focus on numbers. They’re the type of people who believe, “You can’t manage what you don’t measure.” Operating well is not a matter of vibes; it’s a matter of quantifiable metrics.
A knack for aligning incentives. What happens when engineers carry pagers? You suddenly get much more reliable services. What happens when your legal team is rewarded based on how many lawsuits they help you avoid, and not on how quickly they help you ship features customers love? You hit impediments at every step, a “No” or a “Don’t” to every inquiry.
Managing rhythm and heartbeat. You can’t be a great operator if every single team activity is novel, completely dissociated from all prior experiences. Great operators know how to regularize actions into repeatable units, and are good at drum-beating in order to lead the dance.
We valorize visionaries and often pooh-pooh the value of great operators. New features and new product launches get all the glory, but people rarely think about how essential smooth operations are to the ultimate success of any business. At some point, every business eventually needs to Get Paid™. A prerequisite for doing so always involves competent operations.
The ability to operate well can be taught, and can also be learned through reflective observation and experience.
Strategy
Just as every designer thinks they’re Steve Jobs, most aspiring leaders think they’re great at strategy — an empiric observation in my experience for which I don’t have a good explanation. Perhaps neither design nor strategy afford assessing counterfactuals: you can claim your phone design would have been better than Steve’s, but we’ll never know; you can claim freemium pricing would have saved the business, but we’ll never know.
There are at least two domains in which an engineering leader can be good at strategy:
Business strategy.
“We’ll offshore dev ops and engineering on the FooFoo project, giving us a cost edge over Acme that should bleed them dry in a year.”
“Let’s use more tokens now, despite losses, because extrapolation of token pricing patterns suggests the same design will be profitable within 6 months.”
Technical strategy.
“We should build on React Native not because it’s necessarily the newest cross-platform solution, but because its robust ecosystem of packages will let us launch sooner.”
“Let’s evolve the backend piecemeal by first narrowing the interfaces between our services and then upgrading one component at a time from the bottommost layer up.”
“Let’s cut corners on shipping Daikatana since we’re unsure whether users will flock to it. If adoption starts taking off, we’ll rearchitect it for scale.”
People great at strategy are rare. However, lots of people perceive themselves strong at strategy since it’s such a valorized leadership ability. Many aspects of strategic thinking are learnable, but it’s hard to learn strategy efficiently because many attributions of clever strategy often boil down to post-hoc analysis and curve-fitting by business publications like Fast Company and Business Insider.
Technology
Not much needs to be said about this because engineers already intuit what great technology leadership looks like. It includes things such as:
Choosing the right platforms and architectures
Making tradeoffs between competing approaches
Balancing technical debt with business goals and competitive landscape
Inventing novel solutions to difficult problems
Though it’s easy to spot someone with strengths in this leadership domain, I’m not sure what to suggest to someone who wants to become exceptional at this. Becoming merely competent is easier: study and keep up with developments in technology, read others’ war stories to learn key insights, reflect on one’s own experience by observing consequences of one’s past technical decisions. But to become truly great at this is not something I know how to teach.
What to Do with POST
Perhaps the POST model of engineering leadership helps articulate something you’ve always felt you were good at. Suppose you identify strongly with Operations leadership. If so, double-down on that and become not only a good engineering operator, but a great one.
Alternatively, perhaps the POST model suggests you’re particularly weak in Operations. This doesn’t necessarily dictate one course of action. I can in fact imagine a few possible approaches, each defensible:
Ignore it. Just become exceptionally good at one of the other domains. This is a fine way to go, and many careers have been made by focusing on becoming an outlier solely in one domain whilst ignoring all others.
Get passable. Perhaps it’s ok to not be great at Operations, but can any exceptional leader truly succeed while being absolutely terrible at Operations? An argument could be made for becoming at least passable in all four domains of POST.
Hire to fill your gap. Find and convince a great operator to join your team.
Fireside True Story™ Time: I still sometimes struggle with the POST model when applied to myself because: a) I suspect I’m not the best at self-assessing these, and b) my strengths have shifted over time.
I’m good at some aspects of Operations (e.g. detail orientation, rhythm of execution) but I don’t like focusing on it. I used to think I was good at Strategy but I now think perhaps I was just wearing black turtlenecks thinking I was Steve Jobs. I’ve never been good at Technology. I love technology, and I love working with people who are great at technology, but I’ve never been exceptionally good at it relative to peers.
People is the strength I’m most ambivalent about because I’m extremely bimodal on it. I’m exceptionally good at attracting great talent but bad at giving feedback and resolving conflict. I even once had a direct report of mine say, at the end of a tough 1:1, “Philip, you are terrible at giving feedback.”
If anything, I don’t know how best to score myself in the POST model. But I’ve found it enduringly useful as a way to think about the relative strengths of myself and others when it comes to composing a balanced leadership team.
Perhaps that final thought is most important. In addition to giving you a way to conceptualize your strengths and areas for development, the POST model of engineering leadership also helps you build a well-rounded leadership team. The best teams will comprise of leaders who are strong across all four collectively, even if no single leader is strong across all domains.



A couple of observations on this..
First is around completeness of the model. It feels like it’s missing a viable vector: alignment (A), which some may call politics but P is already taken :). This is the person who works across the organization, building relationships, securing support, and making “deals” with the people who matter. In an ideal version, they’re doing this in service of the organization rather than themselves. It overlaps somewhat with the original P, but feels distinct from building and growing a team internally. This is more about external alignment. It also overlaps somewhat with strategy and operations, but again seems distinct enough from any of these. And as you go up levels, you tend to see more and more people who fit this pattern.
Second is that the model treats the axes symmetrically, but P seems structurally different. It’s the only one that can compensate directly for weaknesses in the others. If you’re strong in hiring and growing people, you can bring in O, S, T, and even A. It’s much harder to see how strength in O, S, or T can make up for gaps in the other areas without relying on existing organizational support or someone nearby who is effectively covering those functions.
The Operations dimension is the most underrated one in AI delivery too. The retail AI PoCs that stall after the demo almost always had strong strategy and credible technology.
What they lacked was someone who thought in systems - who asked not just whether the agent worked but whether the organisation could operate it reliably at 2am on a Saturday when something breaks.
Building the machine that builds the machine is the part nobody budgets for because it does not show up in the demo.