Manage Up

Some people hear "manage up" and think office politics, which is close to the opposite of what I mean. Politics is managing perception. Managing up is managing information, and it starts with learning how the person you work for actually operates.

Some bosses want the detail and some want the conclusion. Some want to hear about a problem the moment you smell smoke, and others would rather you spend a day on it and come back with options. Some want the weekly status document, and some will never open it but would happily read four sentences on the day something changes. Figuring out which one you have is part of the job, and getting it wrong is how good work turns into a rumor.

You can do excellent work and still frustrate the person you work for if they never know what is happening. Suppose you are running a large project with a dozen things in motion, and on Monday your boss asks whether it is going to make its date. You say yes, because on Monday that is true. On Thursday you find a dependency that could sink the date, so you do what a responsible person does: you call the other team, rearrange some work, and convince yourself you can still recover. You say nothing, because there is nothing to report yet. The following Wednesday your boss asks again, and the sentence that comes out of your mouth is that the date has been at risk for almost a week.

From where you sit, you spent a week protecting your boss from a problem you were already fixing. From where they sit, you spent a week sitting on something they needed. Only one of those is about the schedule.

Your boss has a job too. They may need to answer their own boss, move money, move people, or renegotiate a commitment somebody made last quarter. Information that looks like noise from your desk is sometimes the exact thing that lets them do any of that, so tell them. Not every detail, and not every minor problem, but enough that they can make decisions with something better than optimism.

The more you understand how they think, the more of this you can do before anyone asks. If you already know the questions are going to be schedule, cost, risk, and customer impact, bring the answers with you. That is all managing up really is: reducing the amount of management required to manage you.

Model Down

The other half matters just as much, and more people get it wrong, because this one cannot be faked. If people work for you, they are watching what you do and largely ignoring what you say. That is why I prefer "model down" to "manage down."

Say one of your people brings you bad news. A deployment went wrong, a customer found a serious defect, or somebody made a call that turned out badly. You can open by looking for whoever screwed up, demand an explanation on the spot, and make the meeting painful enough that everyone in the room remembers how it felt. They will remember. What they will learn from it is never to bring you bad news again. The next time something starts going sideways, they will wait, investigate a little longer, try one more fix, and quietly hope somebody else says it first, and by the time it reaches you it will be too big to hide. Then you will genuinely wonder why nobody told you sooner, when they did exactly what you trained them to do.

Run the same moment with a different response. Something breaks, and your first questions are what happened, what the impact is, what has to happen right now, and how we keep it from happening again. Accountability survives all of that. You can still expect good engineering, still fix the mistake, and still have a hard conversation later with whoever needs one. What changes is that you have demonstrated, in the only way that actually registers, that problems here get solved instead of hidden.

Teams learn their real operating rules by watching what happens when something goes wrong, not by reading the values on the wall. If you want people to admit mistakes, admit yours. If you want risks surfaced early, surface them early when you talk to your own boss. You cannot demand one culture and demonstrate another, because people copy what leadership rewards, tolerates, and does.

Help the People Beside You

Most of us think about work vertically, in terms of the person above us and the people below us. A great deal of the actual work moves sideways, through other teams, peers, people you depend on who do not report to you, and people who depend on you and cannot tell you what to do. Sideways is where organizations get quietly, expensively slow, and that request sitting in another team's queue for three weeks is usually a good illustration of why.

Here is what that ticket often says, in full: "Need API change for Project X." Technically you have made a request. What the other team has received is a research assignment: work out what Project X is, why it matters, who is affected, what the change actually involves, when it is needed, and what happens if they cannot do it. You did not hand them a request. You handed them your ambiguity, and then you get irritated that it sat there.

The fix is boring, which is probably why so few people bother with it. Tell them what you are trying to accomplish and why it matters to somebody real. Give them the context instead of making them reconstruct it. Tell them when you need it and what breaks if that date slips. If there are two or three plausible ways to solve it, say so, because they may know a cheaper one you cannot see from your side. And remember that they have their own priorities, their own deadlines, and their own boss asking them questions, so a request that is easy to say yes to has an enormous advantage over one that requires an investigation first.¹

A lot of workplace efficiency is nothing more sophisticated than not making other people reverse engineer your problem before they can help you solve it.

Work Yourself Out of a Job

The other rule I have carried for years sounds like career suicide the first time you hear it: always work yourself out of a job.

If something needs you every Tuesday morning, find out why. If you manually fix the same thing every month, stop getting better at fixing it and go kill the cause. If you are the only person who knows how a system works, teach somebody, and if deployment takes a fifteen-step document where one person knows which three steps are lies, fix the deployment. When everybody calls you the moment a particular service falls over, the answer is not to become a faster responder. Make the service stop falling over.²

People resist this, and I understand why, because being needed feels like being safe. Those are not the same thing. Being permanently necessary for one problem is not job security, it is a bottleneck with your name on it. I have watched organizations build a critical process entirely inside one person's head and then congratulate that person for it. They get pulled into everything, their vacations turn into negotiations, and nothing moves while they are out. That is not a strong employee. That is an organization taking on debt and calling it dependability.

I would rather build the process, automate the work, write down what matters, teach someone else, and make my own involvement unnecessary, because then I get to go work on something else. There is always something else. I have never worked for a company that was in any danger of running out of problems, since they manufacture them faster than anyone can solve them. The people who end up valuable are not the ones who defend their territory. They are the ones who keep making problems disappear.

Your Job Is Larger Than Your Job Description

Which brings me back to the assumption I started with. Your job description lists your responsibilities. It does not describe the system you need in order to succeed, and that system is made of people: your boss, your peers, the people who work for you, and the people on other teams who have no obligation to care about your deadline. It runs on communication, expectations, trust, incentives, and handoffs. Ignore it and it does not go away, it just sends you the bill later, in the form of a boss who no longer trusts your status reports, a team that hides problems until they are expensive, and a request that sits in somebody's queue for three weeks.

So manage up, so the person above you has what they need to help you succeed. Model down, so the people who depend on you learn what good looks like by watching you. Help the people beside you, so working together stops being its own project. And keep working yourself out of your current job by solving problems permanently instead of building a career on fixing the same one over and over.

Do that long enough and the frustrated competent person in the first paragraph is no longer you. You will not become less valuable because people need you less. You will become more valuable because of what people learn to expect when they hand you a problem. It goes away.