I’m a big believer in ‘it depends’ as an all-purpose answer to questions on engineering and management.
How should I decide what to work on? It depends. How do I get promoted? It depends. How should I store this data? It depends.
In the case of giving general advice to an audience that you don’t know well, this is still the best short answer (followed by a bunch of questions to tease out something more specific). But I’ve realized that I fall into a related trap too often as a manager. I provide very little structure, requirements, or processes to my team to help them figure out how to do things. After all, it depends! If your team is in heavy execution mode, spending a bunch of time in meetings talking about strategy and filling out vision docs isn’t useful. And who am I to care about how you track the work your team is doing? As long as it’s getting done and hitting goals, I don’t care about your Jira structure!
Well, surprise surprise, this has its limits. It doesn’t help people figure out what is important to you. And worse, you deny your managers a powerful tool to use with their own teams: the threat or reward of attention from their senior manager.
This lesson took me a long time to learn. When I came into my current job, I had – for the first time – a team of seasoned managers reporting to me. Being both lazy and not interested in the details of tracking work, I let these managers largely operate things in their own ways. We tracked OKRs and looked at project hits and misses every couple of weeks, but I stayed out of the details. And work got done. (Sometimes not as well as I wanted, but I was busy with other things so I figured it was all ok.)
The turning point came when my team got involved in a big, complex migration. The project was going ok, but there were a lot of moving parts. I trusted every person individually who was working on it, but I didn’t feel like I understood the details and I was worried that we weren’t asking ourselves the hard prioritization questions often enough. So I started a monthly update meeting.
I know what you’re thinking. A monthly status update meeting? What a waste of time! Why isn’t it just a spreadsheet? And maybe I could’ve managed this via a spreadsheet that I reviewed with one of the owners in our 1:1s, but the meeting ended up being a useful forcing function beyond any 1:1 check-in or asynchronous spreadsheet.
Why was this meeting so valuable? Well, there were a few reasons.
First of all, this was a chance for discussion. I got to ask hard questions, and the team leadership got to show off.
The team was forced to reach some agreement on the status before showing it to me, and my questions could reveal disagreements that they may not have resolved fully.
They had a target every month that required preparation, coordination, and thought.
And my presence was good for all of us, because it forced a group that didn’t all share reporting lines below me to get on the same page, and gave each the opportunity to highlight disagreements with the others in real-time when they didn’t feel aligned.
Writing this all sounds very obvious. And once I started doing it, I realized that this was something I had been missing with many of my teams, for years. In an attempt to not micromanage, I had denied teams the opportunity to show off, to air grievances, and the forcing function they needed to get past their disagreements and get organized.
The outcome for that project was so positive, I expanded it to a few other areas in my organization. Running this process across different types of teams and projects, I can see its pluses and minuses. I now recommend this type of check-in for situations where any of the following apply:
- You have a critical area that has some misalignment between the participants. This can happen when there’s a disagreement across product, engineering management, and/or the tech leads, or among partner teams working on a project.
- You have a manager who isn’t getting into the details enough and needs some forcing function to get themselves (and their team) organized. They should not only just have status updates, but have status updates that they can explain every month.
- You have a strategic area where there is some uncertainty about where you should be going. You’re learning new information month over month that can change the project focus and direction, and you need to hear about project status, but also how the team is taking in new information to inform future work.
This type of meeting isn’t necessary in an area that is running smoothly with a fairly stable roadmap and strong alignment across team members. You want to give these teams the chance to show off their accomplishments for you, but forcing a status meeting monthly is not the right format for that.
These meetings also need to be adjusted or canceled once their reason for beginning is no longer there. When the misaligned participants get on the same page, the spreadsheet and quarterly update might be enough. When the manager is in the details and organized, you can now have the confidence that things are moving without needing to meet with a large group. When the strategic area gets clarity on their roadmap, there is no need to just talk about status updates. Do not keep these going forever just because you started them. Once they start to feel boring and rote, the meeting has outlasted its purpose. Cancel it, or reschedule it to happen less frequently.
So if you happen to share my particular style of management – heavy on delegation, trust, and lightweight check-ins – I encourage you to add these forcing functions to your rotation. Give your teams the chance to show off, give your managers a boogeywoman to point to when they need the group to focus, and make life better for everyone. You owe it to them.
