Managing Up Is Hard. It’s Even Harder in Tech.

About five years ago, while working as head of engineering at a startup, Brandon Hays was hit with the most direct feedback he’s ever received: “You’re a terrible listener,” a direct-report developer told him straight away during a one-on-one.

Hays was slightly taken aback, but he came to see his direct report’s firm tone as a blessing. It led Hays, now a senior engineering manager at HashiCorp, to explore active listening techniques and, ultimately, a willingness to embrace a bit of constructive discord when dealing with his own bosses.

“When people think about managing up, they think of how to harmoniously orient themselves in a relationship with their boss,” said Hays. “But sometimes initiating conflict with your boss is a really important component.”

That doesn’t mean total tactlessness, of course — quite the opposite. Hays’ developer was “indelicate,” but, at the same time, “knew I was prepared to handle indelicate feedback,” he said. “We had a relationship and he read the room.”

There’s a delicious irony in the fact that Hays, who also co-hosts Managing Up, a podcast about management challenges within technical teams, cites this brusque quasi-confrontation as a standout example of the concept with which his program shares a name.

Managing up is the process of consciously creating a productive relationship with one’s professional superior — “the art of finding the shared point between your goals and your boss’s goals,” as Hays describes it. By and large, that entails smoothing out the friction that comes with natural differences of opinion, personality and, importantly, communication style. But as any good composer can tell you, a bit of thoughtful dissonant counterpoint sprinkled among the harmonies can be quite effective.

“It’s not about sucking up, being a sycophant or being a brownnoser,” said Mary Abbajay, author of Managing Up: How to Move Up, Win at Work, and Succeed with Any Type of Boss. “It’s about deliberately creating a robust, productive, positive relationship.”

Oftentimes, though, managing up means more self-modulation and more flexibility. Abbajay recalled one colleague’s minor run-in with a boss. The colleague, who kept a non-traditional schedule, had a project due on her day off, so she filed it the next business day. Her boss, who was expecting the project the day before, replied with a long email about expectations for such scenarios and the need for more proactive status updates. She forwarded the email to Abbajay, asking for advice about what the boss really wants.

“And I said, ‘Really? Because if you read his email, he told you exactly what he wants from you,’” Abbajay said. “A lot of times we just resist.”

That’s why managing up, though simple in concept, can be tough to pull off. Humans are naturally against doing things in ways that run counter to their own preferences. After all, if the other way were better, we’d already do it, right?

Why Is Managing Up So Hard in Technical Organizations?

Devs Often Resist ‘Politics’...

Managing up takes effort, but, as Kellan Elliott-McCrea, vice president of engineering at Dropbox, pointed out in a 2019 talk, it’s a wholly unique beast in technical roles.

One key reason: what Elliott-McCrea called “the myth of the apolitical engineer.” That’s the tendency among some software engineers to insist upon a “hyper-rational” approach to their work — “letting the work speak for itself” and scoffing at what they perceive to be office politics, which might include managing up.

Now, we risk stereotyping when leaning too heavily on the perception of developers as apolitical Vulcans, driven by logic and unskilled or uninterested in managing interpersonal relationships. But Hays said, in his experience, that this tendency does indeed play out frequently.

“It absolutely is a prevailing sentiment among software engineers that politics is beneath them,” he said.

... And That Can Be a Career Killer

Not only does this mentality risk crossing signals in terms of working preferences and priorities, but it also risks leaving your boss in the dark about your achievements and missing out on advancement opportunities.

“You have to be good at what you do, but people also have to know that you're good at what you do,” said Abbajay.

Making that known can be tricky. Part of it may be psychological. The group attribution error says that if we associate an action (like self-promotion) with dubious groups (like salespeople who hoodwink clients), then we reject the action. And the negativity bias says that negative events often have more influence over our state of mind than positive ones.

That’s why Abbajay is a believer in keeping what software engineer Julia Evans calls a “brag document,” essentially a running document of accomplishments, shared with one’s manager, that can be referenced during one-on-ones and reviews. This can also remove the “politics” of the self-marketing aspect, if you will, of managing up. A sober list of deliverables isn’t easily dismissed as self-promotional spin.

Of course, cataloging one’s wins can be a challenge itself in the “always be shipping” environment of software development.

“In knowledge work, because you’re delivering constantly, nothing you do ever really feels like it’s worth celebrating because you’re always on to the next thing,” said Hays. Part of managing up, therefore, means pausing to consider the impact of your work and making a habit of copying and pasting received praise into the brag document.

It’s on the individual contributor to make sure their wins are noticed; it’s on the manager to make sure the team’s wins are noticed across departments, Hays said.

Software Development Environments Are So Complex

But even quantifying the value of software engineering is a murky art. It’s impossible to know the impact of the code you wrote this morning and sheer volume of code is obviously no barometer of impact.

Therefore, engineers need to work with their managers to make sure it’s clear how their contributions are affecting the overall thrust of business. A software engineer should have a solid understanding of how their week-to-week work impacts the customer.

“If you don’t know that … don’t write another line of code until you talk to your boss or product manager,” said Hays.

The nature of software engineering makes managing up difficult in other ways, too. It can seem like the technological equivalent of what Germans called “Gesamtkunstwerk,” or total artwork” — that is, it involves many mediums, which can be a challenge to synthesize into a cohesive whole. Software engineering is “incredibly complex,” requiring expert collaboration, communication, coordination, planning, prioritization and focus, Elliott-McCrea said. That “entangled” nature is another reason managing up in technical environments is unique.

RelatedKnowing Your Coworkers Matters More Than You Think

Not All Technical Bosses Are Great Managers

One reason people might chafe at the prospect of managing up is because, well, they expect their bosses to be good bosses. But Abbajay has seen plenty of people reach management levels despite suboptimal communication or collaboration skills, including in tech.

“Organizations still [often] promote people based on their technical ability to do a job without really knowing whether they have any aptitude or argument for actually being a good boss,” she said.

There’s been a trend in recent years to allow some individual contributors to advance to managerial levels while still retaining a greater focus on the technical side and less on people management.

In his 2019 talk, Elliott-McCrea noted that, even though the supply of quality resources for developing management skills within software development keeps increasing, the demand continues to outpace supply. “We have a growing gap in our expectations of management skill and how many good managers we have available,” he said. Needless to say, when working with a manager who’s still learning how to manage, some managing up will likely be necessary.

That said, remember that not every less-than-perfectly handled moment is evidence that a manager is out of depth. As work advice columnist Alison Green wrote in a Slate article about managing up, “Don’t forget your boss is human: There may be times when she is grouchy, frustrated or frazzled, or times when she would appreciate hearing that she handled something well.”

How to Have the Necessary Conversations

As Abbajay sees it, managing up is a three-step process: getting a sense of your boss’s work style and concerns, getting a sense of the same for yourself, and either making reasonable adjustment requests of your boss or realigning your own style to get better in sync. Each step, Abbajay stressed, should be done without casting judgment.

Remember, too, that realignment doesn’t mean being phony. 

“If I swear like a sailor who wants to be a truck driver, does it make me inauthentic if I choose my language more appropriately?” said Abbajay. “It’s not about changing who you are or acquiescing. It’s about figuring out the person’s preferences and reducing friction.”

So what does that look like in practice? 

Abbajay uses a conversation template that lists 20-plus questions about preferences, priorities and pet peeves. Preference questions cover topics like how often one likes to meet, how one defines success and preferred modes of communication. (For example, give a hierarchy of communication methods, such as email, Slack, text, call.) The priorities section includes questions about individual, team and organizational goals; top and lower-ranking priorities. The pet peeves portion asks: What drives you crazy? And what stresses you out? 

It’s the manager’s responsibility to initiate this conversation, but if they fail to do so, the individual contributor should ask to have it, Abbajay said.

In engineering management, this sometimes takes the shape of a “user guide” or manager README document. The idea is, just as a software development project might include overview documentation in a code repository, a manager README file provides need-to-knows about that person’s expectations and preferences.

The README is often considered a manager’s tool, but the concept has benefits for individual contributors, too. The process of writing down information about yourself — your responsibilities, communication and feedback preferences, known shortcomings — improves self-awareness, which in turn makes it easier to align frequencies with colleagues.

It’s worth pointing out that READMEs do have their critics. Camille Fournier, author of The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change, considers them well-intentioned but flawed. READMEs assume a level of self-awareness that most people lack and people lose credibility when they inevitably contradict their self-described preferences, she wrote in a 2018 post. They also allow the writer to excuse and normalize bad habits as “quirks,” according to Fournier.

But being aware of those potential pitfalls might make it easier to avoid them for those who do write such a document.

For README advocates like Ernie Miller, director of engineering at Fastly, sharing the document is as important as writing it. But Hays believes the power comes more from the self-reflection it prompts. To achieve this, he uses Resilient Management author and engineering management vet Lara Hogan’s “questions for our first 1:1” template, which asks the manager and individual contributor about their feedback and recognition preferences, goals and support, and what makes the other person grumpy.

Hays likes the framework because it helps him more explicitly position his role as a support function. Managing up so often means adapting to the boss’s style, but “it is actually the manager’s job to adapt to the preferences of individuals on the team as best they can,” Hays said. Of course, not every boss feels similarly, so the individual contributor does still need to have some sense of how to adapt, too, he added.

RelatedA Guide to Stress-Free Performance Reviews

Managing Up Over the Long Run

A few scenarios tend to recur where the art of managing up comes in handy. One is when an individual contributor is confronted with a decision with which they don’t agree, be it a team restructuring or a feature they believe is unnecessary.

Here, Kate Matsudaira, vice president of engineering at Splunk, offers a few recommendations: ask about the context behind the decision, don’t jump the chain of command, offer alternative solutions and, above all, remove emotion — especially if your suggestions don’t win out. Green, in Slate, stressed this point, as well: “[If] your boss ultimately picks a different route, it’s helpful to have reasonably thick skin: Don’t take it personally and keep your ego out of it.”

A good way to prevent these kinds of interactions from getting personal is to be intentional about providing feedback to a manager. Some tips include: preparing thoughts ahead of the conversation, supporting your perspective with data, using non-accusatory “I” statements and offering positive feedback in addition to constructive criticism.

At the same time, don’t manage up only when a moment of conflict arises. Hays recommends thinking about three questions during one-on-ones:

• Where are we going?
• What’s my role in that?
• How am I doing it?

It’s the sort of larger-picture framing that developers and managers don’t necessarily have the time to tackle at every weekly one-on-one, but if you wait for the six-month or annual review, then “surprises will creep in,” Hays said. Even if you don’t explicitly foreground the questions, make sure that bird’s-eye-view perspective is being addressed at least once a month.

Hays recalled the time when, at a previous company, his manager had assumed he wanted a promotion, when in fact he wanted to support a lateral team. But meetings were so dominated with status reports and project punch lists that, even though Hays’s manager was pleased with his work, he was missing the career-development forest for the job-task trees. 

“But you need to have that conversation about broader strategy and trajectory,” he said.