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 operates.

I learned this late. For a long time I assumed that if I did a good job, somebody would notice. I worked hard, learned whatever I needed to keep up, and waited for my bosses and my company to notice, and in any practical way they didn't. I was the frustrated competent person from the first paragraph. I read a line recently that says it better than I can: there is no practical difference between work done quietly and work not done at all.

What finally showed me was becoming a team lead, and then a manager, somewhat in spite of myself. When the people on my team had been my peers, I never noticed them doing the same thing, because I wasn't paying attention. Once I was responsible for the team's output, I watched good people do quiet work and wait to be noticed, and I recognized my own habit reflected back at me. A big part of my job as a lead became making that work visible, and in a company large enough to track work in a ticketing system, that came down to a blunt rule: if it didn't get ticketed, as far as the organization was concerned, it didn't happen.

It took me a little longer to see that the same gap runs between you and your boss. When something important happens, there's no guarantee your boss knows about it unless you tell them.

Bosses vary more than people give them credit for. Some want the detail and some want only the conclusion. One wants to hear about a problem the moment you smell smoke, while another would rather you spend a day on it and come back with options, and plenty of bosses will never open the weekly status document but would happily read four sentences on the day something changes. Figuring out which kind 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're running a large project with a dozen things in motion, and on Monday your boss asks whether it's going to make its date. You say yes, because on Monday that's true. On Thursday you learn that the team that owns the payments API has pushed the endpoint you need into their next sprint, which could sink the date. So you do what a responsible person does. You call that team, have your people build against a stub in the meantime, and convince yourself you can still recover, and since there's nothing to report yet, you say nothing. The following Wednesday your boss asks again, and what comes out of your mouth is that the date has been at risk for almost a week.

From your side of it, you spent a week protecting your boss from a problem you were already fixing. Your boss sees a week in which you sat on something they needed to know.

The version I have lived is less dramatic and more common. More than once, my teams were involved in something that mattered to the project or to the team itself, and someone outside our department misread it. The misreading didn't come back to us. It surfaced later in a high-level meeting, aimed at my boss, who heard about it there for the first time and was left unprepared and probably embarrassed. Sometimes all it took was a casual comment to someone about a conversation we were having over reprioritizing work.

Your boss has a job too. They may need to answer to their own boss, move money or people, or renegotiate a commitment somebody made last quarter, and information that looks like noise from your desk is sometimes what lets them do it. So tell them. They don't need every detail or every minor problem, just enough to 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 will be schedule, risk, and customer impact, bring those answers with you. Managing up comes down to 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 can't be faked. If people work for you, they're watching what you do and mostly ignoring what you say, which 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 defect that has been corrupting their invoices, 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 learn from that meeting is never to bring you bad news again. The next time something starts going sideways, they'll investigate a little longer and try one more fix while hoping somebody else says it first, and by the time it reaches you it will be too big to hide. Then you'll wonder why nobody told you sooner, when they did what you trained them to do.

Run the same moment with a different response. Something breaks, and your first questions are what happened and what the impact is. The next ones are what has to happen right now and how you 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 shown people, in the only way that registers, that problems here get solved instead of hidden.

A team takes its operating rules from what happens when something goes wrong, and the values printed on the wall have very little to do with it. You can't demand one culture and demonstrate another. If you want people to admit mistakes, admit yours, and if you want risks surfaced early, let your team watch you raise them early with your own boss.

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 lot of the work moves sideways, though, through peers and other teams, through people you depend on who don't report to you and people who depend on you and can't tell you what to do. Sideways is where organizations get slow and expensive without anyone noticing, and a two-hour change that has sat in somebody'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 received is a research assignment, because somebody over there now has to work out what Project X is, who is affected, what the change involves, and when it's needed. You handed them your ambiguity, and then you got irritated that it sat there.

Most of the fix is sparing other people from reverse engineering your problem before they can help you solve it, which is boring, and probably why so few people bother. Tell them what you're trying to accomplish and who is waiting on it. Give them the context instead of making them reconstruct it, and tell them when you need it and what breaks if that date slips. If you can see two or three ways to solve it, say so, because they may know a cheaper one you can't see from your side. They have their own deadlines and their own boss asking them questions, so a request that's easy to say yes to moves far faster than one that needs an investigation first.¹

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.

Anything that needs you every Tuesday morning deserves a hard look at why. When you fix the same thing by hand every month, stop getting better at fixing it and go kill the cause. Teach somebody else the system only you understand, and if deployment is a fifteen-step document where one person knows which three steps are lies, fix the deployment. And when everybody calls you the moment a particular service falls over, becoming a faster responder is the wrong kind of progress. Make the service stop falling over.²

People resist this, and I understand why, because being needed feels a lot like being safe. Being permanently necessary for one problem is not job security, though. It's 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, while that person gets pulled into everything, their vacations turn into negotiations, and nothing moves while they're out. An organization that does this has taken on debt and called it dependability.

I would rather write the process down, automate what can be automated, 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 companies manufacture them faster than anyone can solve them.

Your Job Is Larger Than Your Job Description

Your job description lists your responsibilities. It says nothing about the system you need in order to succeed, and that system is made of people: your boss, the people who work for you, and people on other teams who have no obligation to care about your deadline. Ignore it and it sends you the bill later, as a boss who has stopped trusting your status reports or a team that hides problems until they are expensive.

Doing this well does mean people need you less for any one thing, and that's fine. What they learn instead is what tends to happen when they hand you a problem, which is that it goes away.