Energy, Attention, and Judgment

The Broken Scoreboard

There is a particular kind of exhaustion that engineers describe after big projects — not physical tiredness, but something harder to name. The project shipped, maybe it even shipped on time, but somewhere around month four they stopped trusting their own thinking. Decisions that should have taken an hour took three days. Simple trade-offs felt unresolvable. They were present in every meeting but not really there.

This isn't a character flaw. It's the predictable outcome of treating execution like a pure scheduling problem — as if you're a machine that just needs tasks assigned to it and it will produce output at a steady rate forever.

You are not a machine. You have a metabolic rate for complex cognitive work, and when you run past it, the quality of your thinking degrades before you notice it. What makes this dangerous is that bad thinking feels exactly like good thinking from the inside. When you're tired and overwhelmed, the decision you make feels reasoned and justified — because the part of your brain that would flag "wait, this feels off" is the same part that's depleted.

The scoreboard most engineers use — tasks done, meetings attended, hours logged — is measuring the wrong thing. It measures activity. What you actually need to measure is whether the project is less ambiguous, less risky, and closer to done than it was yesterday. And producing that movement requires something beyond showing up: it requires showing up with the right mental resources available.

The goal isn't to work more hours. The goal is to make the project move every day, and to be in good enough cognitive shape to make the right calls when it matters.

Execution Is Resource Allocation

Think about a large project the way an economist thinks about a factory. A factory has inputs — raw materials, labor, machinery — and it converts them into outputs. The factory runs well when the inputs are matched appropriately to the tasks. It runs badly when there's a bottleneck: the right material in the wrong place, the machine running at 10% capacity because of a missing part.

Your execution as a principal engineer has inputs too. Most people think the only input is time. But time is just the container. What fills the container is:

The reason this matters for project execution is not philosophical — it's completely practical. On a complex ambiguous project, the most important work you do every week isn't writing code or filling out status updates. It's making the handful of decisions that nobody else can make: what the right architecture is, which trade-off to take, how to break through the blocker with team X. Those decisions require judgment. Judgment requires attention. Attention requires energy. Energy requires management.

Miss any link in that chain and you end up making those important decisions while running on empty — and you won't know that you did until three months later when you're debugging the consequences.

Why Time Alone Doesn't Explain Project Failure

Here is a thing that happens on almost every struggling project: the team has plenty of calendar time, and the work still doesn't get done. Fourteen-hour days produce less than six-hour days did a month ago. More meetings to "align" produce less alignment. More people added to the project produce more coordination overhead and slower velocity.

Frederick Brooks wrote about the people problem in The Mythical Man-Month in 1975. His insight was that adding people to a late project makes it later, because the cost of communication grows quadratically while the capacity grows linearly. That's still true. But the energy/attention/judgment problem is different and less discussed: even a single engineer, working alone on a piece of the project, can hit diminishing returns not because of communication overhead but because their cognitive resources are being spent on the wrong things.

An engineer who spends the morning in four back-to-back meetings about scope and the afternoon trying to debug a hard architectural problem will solve that debugging problem much more slowly and poorly than an engineer who blocked their afternoon and started it fresh. The hours in both cases are the same. The quality of thinking is not.

Quality Hours vs. Clock Hours

Let's make this concrete. A "clock hour" is any 60 minutes on a calendar. A "quality hour" is 60 minutes spent on deep, focused work when you have the energy and attention to actually do it well. The difference between a good day and a bad day is not the number of clock hours — it's the number of quality hours.

The bad day is recognizable to almost every engineer. What's less recognized is that you can have strings of bad days — even weeks — without noticing, because the activity looks the same from the outside. You were at your desk, you were in the meetings, you replied to messages. But the actual work moved much slower than it should have, and more importantly, the decisions you made during the bad days were lower quality.

The Context-Switching Tax

Context switching — moving your attention from one task to a different, unrelated task — has a cost. This is not new information. What is less understood is why it's so expensive on complex engineering work specifically, and how much you pay compared to simpler tasks.

The Mental Model Problem

When you work on a complex system — designing an architecture, untangling a gnarly bug, planning a migration across four services — you build a mental model. This model lives in your working memory: the service relationships, the failure modes you're guarding against, the open questions you're holding, the constraint from team B that changes how you design this interface.

The mental model is not stored in a document. It lives in your head. And it is expensive to build — it can take 20 to 30 minutes of uninterrupted focus before you've loaded enough context to think at full depth on a hard problem. Neuroscientists sometimes call this reaching "flow state," but from an engineering perspective it's simpler than that: you need all the relevant pieces in working memory at the same time before you can reason about how they interact.

When you switch context — even for five minutes to look at something unrelated — you don't pause the mental model. You destroy it. Not permanently; you can rebuild it. But rebuilding it costs another 20 to 30 minutes. This is why an hour of interrupted work produces less than 30 minutes of uninterrupted work. The interruption doesn't just steal the five minutes it takes. It steals the entire re-loading cost on the other side.

What a Switch Actually Costs

Let's trace the actual cost of a single interruption on a complex project. You are 25 minutes into a hard problem — you've built the mental model, you're starting to see the shape of the solution. Your phone buzzes with a Slack notification. You glance at it. Team C has a question about the API contract. It takes you five minutes to answer. You go back to the problem.

What it costs you: the five minutes, plus the 20 minutes to rebuild the mental model, plus — and this is the part people miss — the quality degradation of the thinking that follows. You rebuild the model slightly differently the second time. You might miss a consideration you'd been holding. The solution you arrive at might be slightly worse without you knowing it.

Now multiply that by a typical day. Ten interruptions at 25 minutes each (5 min for the interruption, 20 min to rebuild) is 250 minutes — over four hours — of productive thinking time destroyed by interruptions that collectively took 50 minutes.

Complex ambiguous work — the kind of work that defines a principal engineer's role on a large project — has the most expensive context-switching cost of any category of work. It's expensive because the mental model is large, fragile, and slow to rebuild.

Protecting Your Mental Model

The practical response to this isn't to become unreachable or to refuse meetings. It's to structure your time so that your highest-context work gets uninterrupted blocks, and everything else — the answers, the reviews, the coordination — gets batched into time you've deliberately set aside for it.

Three tactics that work in practice:

The second tactic — batching responses — is the one that generates the most resistance. People feel guilty about not being instantly responsive. In some organizations there is genuine pressure to reply to Slack within minutes. If that's your situation, this is a conversation worth having explicitly with your manager. The argument is simple: a 3-hour response time on low-priority questions costs the project almost nothing. An engineer who can't build or hold deep context because they're perpetually context-switching costs the project dearly.

The Daily Habit of Making It Move

Here is a useful mental model for project execution: every day, the project should be objectively more done, less ambiguous, or less risky than it was the day before. That's it. That's the standard.

"More done" is obvious — code written, features shipped. "Less ambiguous" means you've resolved an unknown: you know now which approach works, or that the API from team B will have the shape you need, or that the compliance requirement doesn't apply to this data. "Less risky" means you've de-risked something: you've validated the assumption, you've done the spike that proved feasibility, you've caught the dependency problem before it becomes a blocker.

If you can say, at the end of the day, that at least one of those three things happened — you've done your job. If you can say none of them happened, then regardless of how busy you were, the project stalled today.

The Forward Motion Test

A useful daily habit is what I call the Forward Motion Test. At the end of each working day, spend two minutes asking: "What is different about this project right now compared to 9 this morning?" Then write a one-sentence answer.

If the answer is genuinely nothing — and this will happen, especially on meeting-heavy days — that's important to know. Not because you should feel guilty, but because two or three days in a row of "nothing changed" is a signal that something structural is wrong. Either the work is blocked and you haven't surfaced the blocker, or you're spending all your capacity on coordination overhead and none on actual progress, or the project has silently stalled.

The test is also useful because it forces you to be honest about what "busy" actually produced. It is very easy to have a full day of meetings and activity and feel productive, but have the project in exactly the same state at 6pm as it was at 9am. The Forward Motion Test catches this.

The Five Daily Moves

On any given day, there are five categories of actions that produce forward motion on a complex project. Knowing which one to focus on is half the job.

The mistake most engineers make is to default to "Build Something" because it feels like the most legitimate form of work. Writing code feels productive. It's visible, it's concrete, and it gives you the dopamine hit of completion. But on a complex project, spending three days building the wrong thing — because you didn't take one day to resolve the unknown that would have told you which thing was right — is common and costly.

The highest-value move at any given moment depends on where the project is. Early on, most of your days should be "Resolve an Unknown." Mid-project, it shifts toward "Remove Blockers" and "Build." Near launch, it's "Reduce Risk" and "Align." The daily discipline is asking "which of these five is the most valuable thing I can do right now?" — not just defaulting to whatever feels most natural.

The Tuesday Problem

Here's a scenario that happens constantly on large projects. It's Tuesday. There are no meetings until 2pm. You sit down at 9am with the intention of making progress on the architectural design. An hour later you've replied to twelve Slack messages, triaged your email, reviewed a PR that wasn't blocking anything, and looked at some dashboards. It's 10am. You start the design doc. By 11:30 you've written a page and a half, which is okay but not the two or three pages you were hoping for. Lunch. 1pm. Another hour of Slack and small tasks. Then meetings from 2pm to 5pm. Day over.

What happened? The block of free time was real. The intentions were real. But the morning was consumed by small tasks that weren't urgent and weren't valuable — they just existed and were easy to do. The design work started late, without full focus, and ran into the natural energy dip of late morning. And then meetings consumed the afternoon.

This is the Tuesday Problem. It's not laziness and it's not incompetence. It's the absence of a deliberate energy and attention management practice. Without one, your time fills with whatever is loudest, most recent, or most comfortable — not whatever is most important.

When to Push Hard vs. When to Think

One of the most important judgment calls in project execution is knowing when to push harder and when to slow down. Most engineers default to one mode or the other based on personality — the "just ship it" person who always wants to push, and the "let's make sure we understand this" person who always wants to think. Both defaults are wrong in certain situations.

Two Kinds of Slow

Before you can make this call correctly, you need to distinguish between two completely different reasons why a project might feel like it's moving slowly.

Type 1: Execution slow. The path is clear, the approach is known, and things aren't moving because of capacity, prioritization, or coordination friction. The problem is not understanding — it's throughput. In this situation, pushing harder is the right answer. You need more velocity, not more thinking.

Type 2: Understanding slow. Things aren't moving because there's genuine ambiguity — about the right approach, about the requirements, about a technical feasibility question, about how a key stakeholder will respond. Pushing harder here doesn't help. You'll generate a lot of motion but not in the right direction. What you need is clarity, not speed.

The trap — and it catches experienced engineers too — is treating Type 2 slow as Type 1. You push harder, you produce more, and you discover three weeks later that you were moving fast in the wrong direction. Now you have to undo the work and go back to the point where you needed to think, plus you've spent three weeks of goodwill and team energy getting there.

The Decision Heuristic

A practical heuristic: push when you're in execution mode, think when you're in discovery mode. The challenge is knowing which one you're actually in.

You're in execution mode when all three of these are true: (1) you know what done looks like, (2) you know how to get there, (3) the blockers are capacity or coordination, not understanding. In this mode, the problem is throughput. Push.

You're in discovery mode when any of these are true: (1) there's disagreement about what done looks like, (2) you're not confident you know the right approach, (3) the blockers are technical uncertainty or missing information. In this mode, the problem is clarity. Think.

Most large projects oscillate between these modes. The early stages are heavily discovery. The middle stages are a mix. The end stages — if you've done the earlier work well — are mostly execution. Part of what makes a principal engineer effective is recognizing which mode the project is in and resisting the temptation to apply the wrong response.

The Danger of Momentum

There's a particular failure mode worth naming explicitly: the project that is moving fast in the wrong direction. Momentum feels good. When a team is shipping code every day, deployments are going out, and the Jira board is moving, it feels like the project is on track. Stakeholders feel good. Engineers feel good. Everyone feels good.

But fast movement in the wrong direction is worse than slow movement in the right direction. The reason is that momentum creates attachment. When a team has shipped ten weeks of work on approach A, and you discover that approach A has a fundamental flaw that means it won't work at the scale you need, the rational decision is to stop and pivot. But ten weeks of investment makes that pivoting conversation extraordinarily difficult — politically, emotionally, and practically.

The engineers who shipped those ten weeks feel that their work is being invalidated. The stakeholders who were shown demos feel that they were misled. The team lead who gave the status updates feels accountable. The sunk cost fallacy takes hold and the project keeps going in the wrong direction because stopping feels too painful.

The principal engineer's job is to protect the project from this. The way you do it is by front-loading the thinking — resolving the critical unknowns before building toward them. This is the purpose of spikes, prototypes, and early technical validation. Not because you're afraid to commit, but because you're protecting the team from the waste of building something that doesn't work.

Protecting Your Judgment

Judgment — the ability to make good decisions under uncertainty — is what you're being paid for as a principal engineer. Writing code is table stakes. The reason you're at the level you're at is that you can be handed ambiguous, high-stakes decisions and produce the right call more often than most. That's the job.

The problem is that judgment is extremely sensitive to the conditions you're operating in. It degrades under fatigue, stress, information overload, time pressure, and social pressure. And unlike physical fatigue, which you can feel directly, judgment degradation is mostly invisible to you while it's happening.

Think about a time you made a decision under severe time pressure that you later regretted. Or a decision you made after a brutal 14-hour day that turned out to be wrong in an obvious way you would have caught if you'd slept on it. This is judgment under duress — and while everyone agrees in principle that it happens, almost nobody actively manages against it.

The Five Judgment Killers

Five conditions reliably degrade judgment on large projects. Recognizing them is the first step to managing around them.

Building a Defense

There isn't a single technique that protects your judgment against all five of these. But there are three practices that together form a reasonable defense.

Sleep like it's your job. This is not a lifestyle suggestion — it's a professional one. The number of important project decisions you will be asked to make over the course of a six-month engagement is substantial. Each of those decisions has a better and worse version. The better version requires good judgment. Good judgment requires a rested brain. Treating sleep as expendable on a hard project is like a surgeon deciding to work through hand tremors because the patient is on the table. The patient needs them right now, yes — but the surgeon needs their hands.

Separate thinking from deciding. For any non-trivial decision, do your thinking at a separate time from your deciding. Think in the morning. Write down what you think and why. Then, separately — often later that day or the next morning — make the call. This gap is not indecision. It's protecting against the judgment killers that are operating in the moment of analysis. You'll catch things in the second pass that you missed in the first.

Write before you talk. Before any important meeting where a consequential decision will be made, write down your view independently. Not a polished document — a scrappy, honest paragraph. "I think the right answer is X because of Y, and the main risk I see is Z." Then go into the meeting. The act of writing protects you from social pressure because you've formed a view that exists outside the conversation. You can update it when you hear new information — and you should — but you're less likely to be socially steered away from a correct position if it's already written down.