Is this a fact, or a rule? — Using first principles in leading people, dealing with people, and running projects
Let me put the conclusion up front: First principles doesn't require you to be smarter; it only requires you to distinguish one thing—which constraints are innate, and which are merely what someone else told you.
That sentence sounds plain, but if you actually put it into practice, it can dismantle more than you'd expect—and also preserve less than you'd expect. This article answers only one question: when you hit a decision, a friction point, or a deadline, how do you tell which parts truly can't be moved, and which are just habit? The last section covers where things most easily go wrong, and it's also the part most worth reading first.
It's really just a line from Aristotle
In the Physics, Aristotle offered a formulation: every system of knowledge contains certain basic propositions that cannot be pushed back any further, and all other conclusions are derived from them. This later came to be called first principles—it sounds like a high-level methodology, but in essence it's just a reminder: your reasoning must have a real starting point; it can't start from someone else's conclusions.
In the modern context, it almost exclusively refers to the approach that stands in opposition to "reasoning by analogy."
| Reasoning by analogy (most people's default) | First principles | |
|---|---|---|
| Starting point | What others did, how much it cost last time | The underlying facts of the matter |
| Action | Tweak the existing approach, negotiate the price down | Break it down until it can't be broken further, then rebuild upward |
| Result | Change one number, structure stays put | May arrive at "this path doesn't need to be walked at all" |
| Risk | Treating someone else's ceiling as your own | Over-breaking, tearing down useful things too |
The battery example from Musk gets cited the most: the market price of battery packs long sat in the range of five to six hundred dollars per kilowatt-hour. By analogy reasoning, all you can do is grind the supplier on price; by first principles, you break the battery down into raw materials—nickel, aluminum, carbon, polymers—and look at their prices on the commodities market, and the calculation comes to only around eighty dollars. That middle four to five hundred dollars isn't a law of physics; it's process, yield rate, and scale.
That price gap is the whole point: it isn't a price that fell from the sky; it's the current answer to some engineering problem. And if it's the current answer, it can be rewritten.
Three steps, and really only three
Step one: write out the conclusions you've accepted by default. This step is the hardest, because defaults are usually invisible. When you blurt out in a meeting, "this has to go through the committee" or "we need to get a quote from the manufacturer," both sentences conceal unexamined assumptions.
Step two: interrogate the underlying layer, one item at a time. The posture of interrogation isn't "why"—it's: "Which category does this constraint belong to—physics, physiology, time, law, contract, or 'this is how we've always done it'?"
Step three: rebuild the plan upward only from the hard constraints that remain. Anything beyond hard constraints is optional, not a premise.
There's a clumsy but very useful trick for telling them apart: sort constraints into three categories.
- Innate: the speed of light, the human attention span, twenty-four hours in a day, material strength, regulatory requirements, contracts already signed. This category won't budge; pushing on it only wastes your credibility.
- Historical: organizational habits, industry conventions, a check that was added after some incident three years ago. This category is the disaster zone, and also where all the room for improvement lies.
- Someone's personal preference: the most common, and the most easily disguised as the second category. Someone says "the process requires it" when they mean "I'm not comfortable with it."
What's truly hard isn't the breaking down; it's knowing which category you're breaking. The scenarios below are all the same set of moves.
Managing people: first ask what problem the action is solving
Whether the weekly meeting should happen at all—don't discuss it in the meeting. The underlying needs of a meeting are just three: information sync, things that need a decision on the spot, and goal alignment. Look at those three separately and many weekly meetings lose their reason to exist—if information sync is already handled by a document anyone can read anytime, then the meeting is just reciting the document. In that case the right answer isn't "cut the weekly to thirty minutes"; it's "cancel the weekly and hold a separate short meeting that only handles items requiring a decision." A meeting isn't management itself; it's a tool for closing information gaps. Once the gap is gone, the tool should be put away.
The sentence "we're short one ops person" usually gets said too quickly. The more upstream question is: which class of failure, which class of repetitive manual labor, are we trying to eliminate? The answer often isn't "add a person" but "retire a machine," "automate a motion," or "change a process from two people handling it to one." First be clear about what you're eliminating, then decide what to eliminate it with. Do it in the reverse order and you'll find that after hiring the person, he works two hours a day and spends the rest maintaining the fact that the position exists.
People don't move for only four reasons. They don't know what to do (unclear goals), they don't know how (capability), they don't want to (motivation), or they can't (permissions, resources, blocked by another department). You have to look down through these four layers in order, because most management incentive tools only work on the third layer. If the actual block is the fourth—he doesn't have the permission, or upstream simply won't give him the data—then when you pressure him, the only move he can make is to make the numbers look better. This isn't a character problem; it's pressure being channeled into the only thing that can move.
Trust rests on only two things: predictable behavior and aligned interests. Team-building doesn't produce either. If after a dinner together the next day's division of labor is still guesswork and commitments can still change at any moment, then trust hasn't grown at all. Predictability comes from public decision rules—how a call will be made under what circumstances, stated in advance. Alignment comes from binding goals to the same verifiable outcome. Do these two and you don't need dinners; don't do them and dinners only make disappointment arrive a little later.
Dealing with people: people are persuaded by their own constraints
The first-layer breakdown of workplace friction: information asymmetry, emotional needs, real conflicts of interest. Viewed this way, more than eighty percent of friction is actually the first layer—the other party doesn't know the information you already know, or you don't know what's pressing down on him. Treat this kind of problem as an "attitude" issue and it will spin forever: both sides work hard to take a stance, and nobody closes the information gap.
Which is why reasoning often doesn't work—and the reason isn't that the reasoning is bad. People don't judge right and wrong first and then act; they arrive with a position and then look for reasons, and this process goes unnoticed even inside their own heads. What you need to find isn't a more forceful argument, but the constraint they care about: how their supervisor evaluates them, what risk they have to bear, whose eyes they need to save face in front of, whether they have the manpower on hand. Only a proposal embedded in their constraints will actually be accepted. The essence of persuasion isn't convincing the other person; it's placing a feasible option into their situation.
This cuts both ways for yourself: when you really want to win an argument about something, first ask yourself—which constraint am I protecting right now? Six or seven times out of ten, the answer is "I don't want to admit my earlier judgment was wrong." Then it's not a dispute over facts, so stop spending time hunting for arguments.
Relationship maintenance has a very unglamorous foundation: high frequency, low cost, mutual. One big favor buys you a debt of gratitude, not a relationship structure; the other person will avoid you because they owe you, not trust you because they owe you. What actually accumulates is the kind of small thing where you can ask a question anytime and it's solved in ten minutes—it's repeatable, and both sides are paying in.
Running projects: of four things, you can only move three
Don't estimate schedules by analogy. The "last similar project took three months" method is systematically optimistic, because every project believes it is the exception this time—this is the planning fallacy, and it is structural, not a matter of anyone being careless. The first-principles approach is to break the work down into work packages that can actually be pinned to "who, how many days, waiting on whom," then layer on the real resource conflicts (that person is on three projects at once). The numbers you get this way usually look worse than the analogy, but you dare to stand behind them.
When a user says they want to "export to Excel," don't start building an export right away. The real need is very likely "something presentable for the boss every week." What you should deliver, then, is an auto-generated chart plus a scheduled email, not an export button. When you hear a solution, step back to the problem itself—the user is describing the means he thought of, not his predicament.
Scope, time, cost, quality: of the four, you can only move three. This isn't a negotiation tactic; it's arithmetic. The essence of scope creep is that someone wants to stuff a new variable in without changing the other three; it is physically impossible. Saying this calmly is more useful than sitting through three coordination meetings—because it turns "can't you figure something out" into "which one do you choose?"
Don't make a list of risks. The question "what risks might this project have" is too abstract, and the answers are bound to be platitudes. Change it to: "Which single link, if it breaks, stops the entire delivery immediately?" What you're looking for is single points, not the length of a list. A project usually has only two or three true single points, and they are worth confirming yourself.
Technical judgment is the same set of moves. Whether a server's configuration is sufficient, whether a GPU can run a given model—the standard process is not to look at vendor talk, nor at "everyone configures it this way," but to lay out the numbers: VRAM, memory bandwidth, context length, measured throughput. If it can be calculated, go; if it can't, change it. Once you ground a judgment in quantities that can be checked by calculation, the argument ends by itself.
Three situations where you shouldn't use it
This section matters more than everything before it, because misusing it costs more than not using it.
One: most old rules were bought with some incident back in the day. Before tearing one down, first ask what problem it solved originally. Why do two systems that can clearly interface still insist on a manual reconciliation once a month? Very likely because five years ago there was a misposted account, a rollback, and a manual check has been there ever since—and the people who knew why have long since left. Tear it down without asking, and what you remove isn't a redundant step; it's the patch for a failure that really happened. True first principles start from the problem, not from "overturn everything." The latter is just rebellion in form.
Two: the human domain has emergent properties. Things like organizational atmosphere, morale, and tacit understanding cannot be derived from "everyone is rational." Reducing people to utility-maximizing individuals makes a tidy model, and a very wrong one. What this area calls for is observation and experience, not derivation.
Three: it's expensive. Derive every decision from scratch and people will freeze. The right way to use it is sparingly: only where the stakes are high, the conclusion is suspect, or you have already failed repeatedly—major technology choices, long-term institutions, that link that has gone wrong for the third time. For day-to-day execution, keep using experience and analogy; that isn't laziness, that's spending your budget where it counts.
Back to the question at the beginning: how do you tell which things are facts and which are just what someone told you?
There's no cleverness in the answer, only patience—lay out the constraints one by one and see whether each belongs to the natural kind or to some yesterday whose reason no one remembers. The former, accept; the latter, worth taking action on.
Most of the rules that chafe are the leftovers of a compromise no one remembers. Whether it can be torn down depends on whether you know what it was blocking back then.