The limits of flexible management

Camille Fournier

Jul 17·5 min read

I’m a big believer in flexibility as a senior manager. I do not think I know or even can know the exact way to run any given team in my organization. The magic of effective teams is a combination of the personalities involved, the project lifecycle they’re in, and so many other factors. Forcing every team into a single process, whether it’s classic Agile-type two week sprints or Scrum or whatever is optimizing for uniformity of process at the likely expense of the needs of the teams themselves. Being outcomes-driven (is the work getting done, with good quality, in reasonable time, without burning out the people involved) is the only way I know how to work.

However, as a senior manager, at some point you can make it harder for your managers to succeed when you give them very little structure to work with. It’s tempting to say “I don’t care how you do any of it as long as it gets done.” But that doesn’t help people figure out what is important to you, so they have to guess at what they share, when, and how. And worse, without any clear expectations at all you deny your managers a powerful tool to use with their own teams: the reward (or perhaps, threat) of attention from their senior manager.

Creating some lightweight process

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

What made this check-in meeting so valuable?

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.

When is this process useful?

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.