The problem: I don’t know how to figure out what’s happening on my teams without asking people directly, and it’s driving them crazy!

I am in charge of a team that is running a big, critical project. My boss is breathing down my neck at all times, asking me for status updates, wondering when different pieces are going to be done. Usually, I know what is happening because I’m doing some of the work myself, so I can give the answers because I’m deeply involved in the project. This time, however, I’m not actually doing any of the work, and I don’t even have the time to attend every planning meeting and standup. When my boss asks me for status updates, I feel that I have no choice but to ask a member of the team.

Of course, there’s also the outages. Did I mention that this big project is to replace a system that is crumbling and causing incidents all the time? So, if I’m not asking about project status, I’m trying to figure out why we’re down, what the status of the incident is, if there’s anything I can help with.

I just got some feedback from the tech lead: I’m driving the team crazy with my one-off questions. They complain that I’m distracting them, interrupting their work, and derailing other important discussions to get status updates. I don’t want to do that, but I don’t know how to figure out what’s going on without tapping someone on the shoulder to ask. What do I do?

The solution: Know where to look

When you are embedded in the team you are leading, the details of their projects are the air you breathe. But add on more teams or a level of management and all of those details provide hard to discover. How do you get the status of projects when you are a step or two removed? How do you figure out what is going on without constantly tapping an engineer on the shoulder and asking her for a status update?

To begin with, you have to know where to look. If it is important that you know the status for projects at the drop of a hat, then you should learn how to read the project management dashboards the team is using. If the teams are not using task tracking and project management software, at this point I must ask, why not? It is one thing to avoid the overhead of formal task tracking in a very small group. However, as the team grows, you need to have transparency into progress. This means that you need a sense of what the tasks that make up “progress” look like, which requires some sort of breakdown and tracking, even if it is in the form of sticky notes on the wall.

This also goes for your production incidents. What is your incident management process? Are incidents managed via chatroom, or by people sitting in the office together? Do you have a postmortem process? If ongoing incidents don’t have a communication process and structure, it might be time to throw something together.

Knowing where to look is the first element, one that managers often skip over too quickly. You owe it to your team to look at the existing tracking software and look for the status there first, before firing off questions directly to the engineers. However, looking through the project tickets and work-in-flight status does not always provide the full picture. Sometimes the person managing the project tracking is themselves a bit disorganized. Sometimes the details that you are concerned with are not represented, or not represented well. Then what do you do?

Practical advice: Manage up, read the room, and let the team lead

Let’s break down this situation further, because “then what” really depends on the time and the urgency, and the reasons behind your question.

Scenario 1: You’re asking because your boss asked about the project and you didn’t have a great answer.

That’s fine! But does your boss need more details this second? Or can you ask the team for details in the context of scheduled meetings or via less-urgent communication channels (email or chat)? Usually when the boss asks us something, that makes us want to jump quickly. What we really need to do is just make a note to get more information and then get it when the time is right. This requires some managing up. Predict the questions that your boss tends to ask, and have some general answers prepared. That will give you some ammunition to use as you push back for time to get details on specific concerns. And you will need to push back occasionally. The worst outcome is having your boss go directly to the team themselves and ask for a status update.

Open office plans provide the most tempting setup for interrupting people. Picture: you have a question you’re itching to get an answer for, the manager of the team is in a meeting that you can’t interrupt, but there’s one of the engineers sitting there typing away. The temptation to tap him on the shoulder and ask can be overwhelming. I know it is for me. If you’re going to do this, for goodness sakes, respect the signals. Is this person wearing headphones and look really focused? Or is he chatting, walking around, or otherwise out of the zone? Be sensitive about your impatience versus their focus, and apologize when you are forced to interrupt their work. Apologies don’t cure all evils, but making an effort here is important.

Scenario 2: You’re asking because launch of this work is imminent, or this work relates to an immediate production issue and you need nuanced details that only a developer can provide.

In this case, you may very well need to interrupt someone and reading the room will be essential. There are times when managers, for whatever reason, are themselves either occupied with something else or don’t understand the nuance of the situation you are concerned with, e.g., a release is at-risk and you don’t know why. Sometimes, asking the developers for details will tease out decisions that could change a release from “late” to “on-time minus a non-essential feature.” The goal is to do this very sparingly, and use it as a teaching opportunity instead of a chance to undermine.

In the book Turn the Ship Around (an essential leadership text for engineering teams), the authors spend a lot of time discussing how to resist taking the wheel every time a small problem happens and thus undermining the leadership and ownership of the members of the team. The way you choose to ask for details in the moment can make the difference between encouraging leadership from the team and enabling learned helplessness that causes the team to be paralyzed without you around. Instead of barking orders in a production outage or telling people to cut features close to a launch, practice using these situations to ask them what they intend to do. Asking what they intend to do puts the ball in their court, and forces them to practice taking leadership of the situation. You want the whole team, not just the tech lead or manager, to feel capable of speaking up and sharing leadership for resolving these situations. Use this direct interaction to push that team-driven leadership and encourage the team to be in charge of situations instead of victims of them.

Scenario 3: You’re asking because an idea occurred to you, you just heard of another team doing a related task, or you have an unspecified concern about the project and knowing more details will help clarify.

Getting details from the developers directly is often useful when you have an intuition nagging about a project. Again, the trick here is to do it without interrupting a developer who is in the middle of flow. Unfortunately, you’re the boss. Even if you try to communicate via non-urgent channels like chat or email, often the person will notice and drop everything. Some situational awareness helps. If you work in the office with them, try to wait until they are getting up from their desk, going to lunch or coffee, or notice when they are out of the zone. If they’re not in the office with you, encourage them to make active use of chat status to indicate when they can be bothered or not, or make it clear at the outset of your chat or email that the topic not urgent but you would like to get some details later.

Have you heard of “swoop and poop management?” It describes what happens when a manager or other senior party unfamiliar with the details drops by the team, makes a suggestion for something the team should look at, and then leaves. Swooping down, pooping out an idea or comment, and flying away without seeing the effect of the interaction is, at best, a distraction or annoyance and, at worst, causes people to start focusing on a causal idea instead of the important tasks at hand because The Big Boss said so.

In all of these situations, you want to defer to the team’s immediate manager, tech lead, or product manager as it makes sense. Going directly to the team should be an occasional event, not a regular occurrence. It’s not that you can’t have a relationship with the team directly, but it is the job of the tech lead or manager to manage and communicate project status specifically so that the engineers can focus. When you do choose to go to the team, do it productively and positively. Use it to share ideas with the developers, help them grow as leaders, and affirm your connection with them in a productive way.

Editor’s note: You can find other articles in this series on Camille Fournier’s author page.