This is not a leadership philosophy piece. I don’t have a natural gift for managing people, and I’m not going to pretend I’ve solved it. What I had, a few months into managing a team for the first time, was a smaller problem, and an easier one to fix: I was still doing my old job, just with a new title. So I did what any engineer does when something doesn’t work - I looked for the model behind it.

The equation

My manager at the time gave me a book called High Output Management, written by Andy Grove, who used to run Intel. Early in the book is one idea that changed how I thought about the job:

Manager’s Output = Your Output + Your Team’s Output + Output of the People You Influence

• the core idea behind Andy Grove’s High Output Management

Broken into pieces, it looks like this:

That’s the whole shift. My old job only had one input. This one has three. The extra tasks I’d stacked on top of my old job - 1:1s, approvals, trying to be a good boss - were real, but they weren’t the job itself. The job is growing the whole right side of that equation, and my own work is just one small piece of it.

Same 40 hours, different lever

Nobody gets extra hours when they get promoted. Five days a week, about eight hours a day - same as everyone else, with some exceptions by industry. What changes is how you use those hours. As an individual contributor, I only had one lever: my own time. As a manager, I have three levers. But I only fully control one of them.

So the real question isn’t “what should I work on.” It’s “my time affects the most people on this team - so what’s the best use of the next hour.” The answer changes depending on the week.

The fork: war mode or build mode

Some weeks the answer is easy: do the work yourself. If something is due tomorrow, and the person who owns it isn’t ready for it yet, that’s not a moment for coaching - that’s a fire. The best move is to jump in, get it done, and talk about it afterward.

But most weeks are not on fire. Most weeks are about medium-term goals - things that only get done if the team works well together, without me watching every task. On those weeks, the best use of my time is something boring: sitting down and setting the goals properly.

Worked example: splitting a goal without splitting the team

Here’s what this looks like in real life. Say my goal is number of sales. That number depends on many things, and I don’t control all of them. I can’t just give my team the goal “grow number of sales” - it’s too vague to act on. So I break it into smaller parts. For example, I split it into two teams: one team handles traffic, the other handles conversion.

This looks clean on paper. But in real life, it leaks. If the traffic team brings in a lot of low-quality visitors just to hit their number, the conversion team’s numbers will drop - even though it isn’t their fault. One team’s decision quietly hurts the other team’s KPI.

The straightforward fix is to add “traffic quality” to the traffic team’s goal, so volume alone isn’t enough to win. This is the right idea. But it also costs more. Now someone has to define what “quality” means, measure it well, and defend that definition when people disagree. So before doing this, I ask myself: do we actually have the time and people to measure this well? Is this the best use of our time right now?

Sometimes, the honest answer may be no - not yet with the currently limited resources we have. If that were the case, a practical choice would be: accept that the two goals depend on each other. Don’t pretend the numbers are more accurate than they really are. Instead, use two simpler tools - a general sense of whether things are moving in the right direction, even without a perfect number, and regular check-ins between the two teams, so problems get caught early instead of at the end of the quarter. Bigger companies can usually afford more precise measurement. Smaller ones usually can’t. Forcing precision you can’t afford just wastes the time you were trying to save.

One check I always run: if every team hits their number exactly, does the overall goal actually get reached? If I can't answer "yes" with confidence, the breakdown is incomplete - there's a gap I haven't accounted for. That gap is worth finding before the work starts, not after.

One more caveat: this example assumed traffic and conversion both report to me. In practice they often don't - one might sit in marketing, the other in product. Getting a peer's team to act on something you can't assign to them is a different skill than running your own team.

Say it until they don't need you to

None of this matters if it stays in my head. Once the plan is set, my job becomes mostly repetition: say the goal, say it early, and say it again - to my direct reports, to their reports, and to other teams whose work touches mine. Again and again, until people can state both what the goal is, and what it isn’t, on their own.

Repeating the goal only proves people can say it back. It doesn't prove they understand it. And usually, you can't tell the difference. People get by on habit, or on copying whatever worked last time, and it looks exactly like understanding, right up until something ambiguous shows up. A new situation, a tradeoff nobody’s hit before. There's nothing to copy from anymore. That’s the actual test: can someone take an option they’re weighing and tell you, unprompted, whether it moves the goal or not? If they can’t yet, sometimes a question is enough - “does this move the goal?” Sometimes it isn’t, and I have to sit down and walk through the comparison myself, out loud, so they see the reasoning, not just the answer.

What the equation doesn't measure

The equation tells you your output, right now, this year. It doesn’t tell you where that output is coming from, or whether it can keep coming.

Behind the three inputs - your output, your team’s output, output of the people you influence - sits something the equation never asks about: is your team improving or burning out? Do people trust each other, or are they quietly checked out? Are people staying, or updating their resumes? Is the way you work together getting better, or is every project reinventing the wheel?

This runs in the background all the time, this year included, and it cuts both ways. A team can push hard, ignore the strain, and still hit this year’s number - burnout and low trust don’t stop you from delivering right away, they just cost you later. The same delay applies to investment: make the team stronger, build trust, fix how you work together - sometimes that shows up in this year's numbers, sometimes it doesn't. Either way, most of the benefit - a stronger team, getting more done, without you needing to do more yourself - is more likely to show up next year than this year.

If you’re in survival mode - this year has to work, or there’s no next year - you don’t need to think about this. Hit the number. That’s the job.

If you’re playing the long game, though, there’s more to manage. The background needs to hold, not break. And separately, if you want next year’s number to be bigger, that’s where the investment goes. Neglect either one long enough, and it eventually shows up as a smaller number - but not this year, and not in a way anyone will trace back to the cause. By the time it’s visible, it just looks like the team “isn’t performing” the way it used to.

PEOPLE & PROCESS BUILD NEXT YEAR'S OUTPUT

This piece was really just about the setup - the equation, splitting goals, saying them out loud. A few things I didn’t get into:

• What actually happens day to day once the goal is set

• The people side - trust, morale, how to actually grow team members

• How to get people who don’t report to you to actually do something

Each one probably deserves its own post.

I wrote this down mainly as a reminder to myself - something to check in five years, to see if the learning still holds up.

This is not a relationship advice article. I am not qualified to give relationship advice - ask my wife. This is closer to an engineering write-up. I had a problem (I could not detect when something was wrong until it was already too late), so I did what any reasonably stubborn, mildly systems-obsessed person would do. I stopped trying to become a more emotionally intuitive person, and I built a flowchart instead.

Me, several years ago, treating my marriage like a debugging session.

The bug report

My wife is what you’d call an indirect communicator. She doesn’t like to make things awkward. She’s busy. Something bothers her, and instead of saying so, it gets filed away under “not worth bringing up right now.” Which is reasonable, individually, every single time. The problem is that “not worth bringing up” is cumulative. It compounds quietly in the background, like interest on a loan nobody told you that you took out - until one day the balance comes due all at once, and I am standing there genuinely asking what I did wrong, because as far as my own logs are concerned, nothing happened.

You’ve probably heard the old Men Are From Mars, Women Are From Venus framing - men process by gathering information, women process by connecting emotionally. It’s a useful starting point, but it’s also a population-level average being applied to one specific, particular woman, which is a bit like using the average rainfall of Southeast Asia to decide whether to bring an umbrella to one specific wedding in one specific town on one specific day. Some men are naturally good at the feelings part. I am not one of them. So instead of trying to become fluent in a language I don’t have great aptitude for, I decided to build a translator.

The algorithm, zoomed out

Before we go step by step, here’s the whole thing at a glance - the decision tree I actually run in my head now, most of it in about four seconds, standing in the kitchen pretending to check my phone while actually scanning for signal.

There’s also a permanent background process running the whole time called energy matching, which we’ll get to. Let’s go through the steps one at a time.

Step 1: Wait for calm

Never during chaos. Never mid-toddler-meltdown, never five minutes before either of us has to leave the house. I wait until the baby’s asleep and the apartment has gone quiet. I also put my phone away - not just on silent, but out of reach. I used to think I could scroll and still catch what mattered. I was wrong, every time. Deploy only in calm weather, with your full attention - starting the conversation during a storm, or while distracted, just gives the storm more material to work with.

Step 2: The scan

I ask how her day was. If the answer is “fine,” “okay,” or “good” - that’s not data, that’s a decoy. So I don’t stop there. I ask again from a different angle: how was the commute, how did that meeting go, did the thing with her coworker get resolved. Somewhere in there, if something’s actually wrong, it starts to leak out.

Step 3: Flag the repeat

If she brings up the same topic more than once, even in passing, even as a throwaway line - that’s the flagged signal. That’s the thing that actually matters. Everything else in the conversation can be small talk. That one gets a deep dive.

Step 4: The parrot protocol

This one needs a definition, because I didn’t know the term either until I started reading about active listening. Parroting just means reflecting her own words back to her, reworded slightly, as a question - instead of jumping straight to a response or a fix. It sounds embarrassingly simple. It also works embarrassingly well. Here’s roughly what it looks like in practice:

Her: “Work was just... a lot today.”

Him: “Sounds like today was pretty draining?”

Her: “Yeah - exactly. My manager kept adding things last minute, and...”

Notice what didn’t happen there: I didn’t offer a solution, and I didn’t share my own opinion about her manager. I just fed the sentence back to her, slightly reshaped, as a check. That’s the whole move. It signals “I heard you” without signaling “I’m already trying to fix you,” which turns out to be a very different message.

The fork: listen, or solve?

This is the part that took me the longest to learn, mostly because I got it wrong publicly, more than once. Sometimes she wants to be heard. She already knows the answer, she doesn’t need my input, she just needs to say it out loud to someone. Other times, she genuinely wants a solution. Guessing wrong in either direction goes badly - solving when she wanted to vent feels dismissive, and just nodding along when she wanted help feels unhelpful.

And if it is a solutions moment, there’s a second trap waiting right behind the first one: never give a direct order. “You should just do X” lands as a command, not help - even when X is genuinely good advice.

So before I offer anything, I run one more step first: I ask her how she’d handle it. “How would you approach it?” does two things at once - it hands the decision back to her instead of stacking my opinion on top of hers, and more often than I expected, she already had an answer, she just hadn’t said it out loud yet. If she genuinely doesn’t know, that’s my cue to offer something - but even then, the fix is small and it changes everything: frame it as your own approach, with an exit built in.

“Here’s what I would do. But I have my own strengths and weaknesses, and yours are different. The idea behind it stays the same. But the right action for you might look different from mine.”

Same advice. Completely different reception. One sounds like a verdict. The other sounds like an offer she’s free to decline. And asking how she’d do it first usually means I never even need the verdict - she gets there on her own, and my job shrinks down to just nodding along.

Bonus process: energy matching

This one runs constantly, underneath everything else. If she’s upset or excited, I can’t stay perfectly calm - a flat, low-energy response reads as not caring, even when the intent is the opposite. So I match her energy. This does not mean raising my voice, or copying her anger or anxiety - that’s the one exception to this rule. Instead, I use small signals: leaning in, nodding, saying “mm hmm,” matching how fast she talks. If I’m trying to calm things down, I stay just a little below her energy level. Not far below - just a little.

This also applies to complaining, which I learned the hard way. If she’s venting about something, matching energy sometimes means having something of your own to complain about too - even if, on that particular day, your life is genuinely fine. I have been asked, directly, “why aren’t you even complaining?” That is a real question I have been asked in my own kitchen, and I did not have a good answer ready.

Testing in production

None of this worked on the first try. Early versions of the algorithm were closer to interrogation than conversation, which - unsurprisingly - made things worse, not better. I kept iterating. Every wife runs different software, so whatever version of this you build, expect to redraw large chunks of it more than once.

The one exception that overrides everything

Here’s the part I want to be honest about, because a tidy flowchart that always works would be a lie. Some days, none of it works. You time it right, you scan, you parrot, you pick the right fork, you match the energy - and it still goes sideways, for reasons that have nothing to do with your execution. On those days, there’s exactly one rule left in the system, and it overrides all the others.

THE WIFE IS ALWAYS RIGHT

The whole fallback branch is just: import patience. Not because the flowchart failed - some days simply aren’t a logic problem, and no diagram was ever going to fix that.

Built with a whiteboard, some trial and error, and one (1) supportive but occasionally exasperated wife.