A mentee recently mentioned a really frustrating problem that her manager seems to be ignoring. The specific problem doesn't matter, so don't focus on the technical details here.

Hey Nicole!

At $DAYJOB, we have some big problems and it's frustrating, I keep pointing them out and nothing happens. I've told my manager three times about this one in particular and she keeps ignoring it.

The short story is we have a few deploy environments, and while I was on extended leave, some of these broke. Now we can deploy our code to staging and production, but we don't have the dev or test environments!

I pointed this out to her in our 1:1 and also in a call with the team that should fix it, and she just moved past it both times. How can I get her to prioritize fixing this problem?

-Alice

I've been in Alice's shoes a number of times, and it is so frustrating. It feels like I'm the only one with glasses on! Getting a handle on this situation is a really important skill and there are a few good techniques for it. There's also a meta-problem here which you need to learn to handle if you want to enter leadership roles.

Explain the impact, not the problem

First, I'd like to say that pointing out a problem is not sufficient to getting it prioritized. It's likely your manager was already aware of these problems already. She's the manager of your team, after all¹. What's the new information you provided to her?

Instead, what's helpful is to remind her of the problem and then add your perspective on what the impact of it is. Here's one way that could go:

Alice: Hi Manager! I'd like to talk about a problem I've noticed on our team.

Manager: Oh my! What're you seeing?

Alice: Well, it's about the deploy environments... To recap the problem, two of our environments are broken right now, and the ops team hasn't prioritized fixing it.

Manager: *nods*

Alice: We used to use those to verify changes to this one legacy system. We can't do that testing in staging, because <REASON>. So instead, we're pushing those changes out and scrambling when bugs are reported, which is making it really hard to meet deadlines on other issues. It's also a bottleneck on the team. We used to have a few environments we could test in concurrently, but now we only have one, so people are staying late to use this one environment when it frees up.

What you're doing here is assuming that your manager is aware of the problem and giving a high level summary of it, and then explaining the impact, which is less visible to your manager. The way managers see that impact is often by you (and your peers) reporting it to them.

If your manager is not aware of the problem, she can still ask about it. But by not explaining it again, she won't feel defensive ("ugh, they're explaining this again, and obviously I've noticed!") and is in control.

But this is probably not enough. If you really care about this problem and you want to fix it, you need to figure out how your manager sees it.

Reconcile your perspectives

Reconciling how you and your manager see the problem can be delicate. It's best to approach it with genuine curiosity and an open mind. Save the arguments and convincing for a different conversation, and use this one just to learn.

Ultimately, if two people are prioritizing something in dramatically different ways, it's likely because they see things differently. Either they understand different facts, or they have different values. And that's what you want to discover: does your manager see something you don't, or vice versa, or both?

I've had to do this so much in my roles as a staff and principal engineer, and each time the results are pretty good. It doesn't always result in my pet problem being prioritized², but it made me better able to understand why it wasn't, and accept that.

Here's one example of how I could see that going:

Alice: Hey Manager, remember that problem I mentioned with our broken environments? I've noticed it's not being prioritized. From my perspective, like so many problems we feel firsthand, it feels so critical, but I know there might be other more important things to do. Could you help me understand where you see it fitting in, and what information you see here that I don't?

Manager: ohmygosh, thanks for asking! It's definitely a problem that the environments don't work. But there's so much stuff going on. The ops team is totally swamped supporting a new feature launch and that's critical for the business, we can't delay it. The broken environment hurts us but it doesn't lose us money, probably. Not much anyway. And the impact is rough from this on our team, but after that new feature the ops team is focused on fixing the staging environments for other teams who have it worse. They're as short-staffed as we are.

Curious conversations are great for all sorts of things, too. If you hone this skill, you'll be able to learn about a bunch of people's perspectives on lots of things, in or out of work. Curiosity is disarming, and people are more willing to share. And then when you understand that perspective, you can then either try to get the problem fixed, or decide that it doesn't need to be.

Talk to your peers

Another thing to do is talk to your teammates and figure out if they're seeing things the same as you are. Sometimes a problem can dig itself under our skin and we can't let it go, but it's not bothering other people the same way. Or it does bother other people, but they're not showing it.

This is another place where you can approach it with curiosity and try to see if your peers are bothered by the same problem and why or why not. It's sometimes easier with peers, because the power dynamic is more balanced.

If you find out your peers aren't bothered by a problem, it's going to be really hard to get it prioritized unless it's something major and you convince your manager to wield her authority unilaterally to force it. That's usually not a good idea for a manager to do, so this would be things like "we're violating a major law" and not things like "the test suite is 50% too slow."

If your peers are bothered by it just like you are, then you now have an advantage and something you can work with. You can have your team collectively present the arguments to your manager. This way they'll be stronger from multiple perspectives, and the manager also has a tougher time saying no to a whole group than to individuals. They might still have to say no, if there's business context that means the problem isn't solvable, so be prepared!

Moving up the career ladder

If you want to move up the career ladder and enter either the management track or the individual contributor leadership track, you have to hone the skill of identifying which problems are important. This goes beyond this specific problem and into the meta problem of where does it fit in the grand scheme.

In my role as a principal engineer, identifying problems to solve is part of it. A bigger part is identifying which problems are not important to solve, which fire we can let burn a little longer while we address the main dumpster fire³.

So if you want to move beyond Senior Engineer and into a higher level, or a different role entirely like product management or program management, this skill is essential. The soft skills you use for it are also critical. Learning how to put people at ease enough to tell you information, or learning how to suss it out without biasing them toward your existing opinion, is critical to the consensus building that you'll need to do in leadership roles.

If you have a question or problem at work, feel free to email it to me and it might appear on this blog!