Congestive Meeting Collapse – Scheduling Gridlock

I used to spend most of my day in meetings.  At one point, when I was managing a large team, I routinely had weeks where there were a total of 2 hours between 9 and 5 that I wasn’t in a meeting .. for the entire week.  Anything I needed to work on that didn’t involve other people had to happen early or late.  Such as answering the crushing quantities of email that stacked up while I was in meetings and actually paying attention.

Now that I’m in a startup, where I’m typically in a traditional “meeting” for a couple of hours a week total, it is amazing how much gets done.  When I touch base with people from my previous employer, the scheduling overhead can become darkly humorous.  Routinely somebody will ask to get together, and then schedule it for a month later.  That slot then gets stepped on by some other meeting, often more than once (and typically at the last minute). It’s common for it to take two to three months to set up a conversation with more senior folks (!).  Really?

I think there is an interesting analogy to the performance of networks.  When the amount of traffic reaches a certain fraction of a network’s capacity and the scheduling protocols are not optimal, the network achieves what is called congestive collapse.  It means that the network is in a stable state of low throughput.  Is your company permanently in “congestive meeting collapse”?

The Damage it Does

When everyone is so hyper-scheduled

  • There is no slack in the system.  If something important comes up, you have to step on an existing meeting to get everyone together.  When one meeting is moved, that causes a cascade of rescheduling among all the attendees, which moves other meetings they were in, and on outwards like ripples in the water.
  • Everyone is in meetings all the time, so they are frustrated, bored, and don’t have time to work on individual projects except outside normal hours.  Anything “optional” (like thinking deeply about the state of your world, the future, and what you need to do about it) gets squeezed out by something “practical” but often much less important.
  • A huge amount of time is wasted scheduling and rescheduling.
  • “Medium importance” decisions take forever.  Big ones get attention; the medium ones that require a number of key people to get together and resolve something, but aren’t a crisis, get rescheduled and rescheduled and take much longer than they should.  This gums everything up and makes the organization inefficient.

Why Does This Happen?

Clearly the problem is that there are too many meetings, but why is that?  There are some obvious kinds of inefficiency, such as:

  • The Serial 1:1 – Some meetings are a lazy way for a manager to talk to folks on their team.  Everyone else sits glumly listening, doing email and/or propping up their eyelids with toothpicks, as the manager talks in turn to each person.  Now and then something relevant to the whole team comes up, but mostly it is a series of 1:1’s with bystanders.  Regular team “status” meetings are often like this – ugh, don’t do it!
  • The Inefficient Mess – There is no clear agenda, things wander along without being well managed, and action items aren’t captured efficiently.  Something that could have been handled in 15 crisp minutes takes 90 minutes, and often bleeds over to another meeting because people weren’t clear about what they were and weren’t accountable for doing afterwards.  This is lampooned by John Cleese in a fun training video called “Meetings, Bloody Meetings”.

But annoying as they are, bad meetings like these are just one-off problems that can be fixed with some coaching.  The much more insidious villain, I’ve found, is too many stakeholders.

As organizations grow, and as more groups are needed to be successful, every important decision develops a long list of people who legitimately have a stake in how it is made.  For example, consider a major shift in the strategy of a particular product.  It affects the people who design the product, build the product, communicate with customers, sell the product, and support customers.  It might also involve legal issues, HR issues, and resetting the expectations of senior management.  In a matrixed world, even one stakeholder can drag in multiple people – sales organizations often have somebody who owns the worldwide quotas for a particular product, for a particular market segment (“enterprise customers”), and/or for a particular regional market (“Germany”).

Thus, two things tend to happen.  One is that many stakeholders get involved in the decision.  They participate in meetings to discuss it, commit to it, implement it, learn about it, and review progress on it.  They all try to get invited to the most important meetings, so they are “in the loop”.  As you scale up, this leads to madness.  The other result is that it is so hard to get things landed that only the most senior people in the organization have enough authority to drive key decisions.  So more and more things land in their lap, disempowering everyone else and slowing things down to a crawl because nobody can get the meeting scheduled with them(!).

Sometimes you can dodge the problem by keeping teams small – the so-called “two pizza team” approach.  But if you are successful, eventually things tend to get big.  And at scale, I think the only solution is to cleanly and aggressively delegate authority and to be absolutely hard-core about defining a minimal set of people who get to influence a decision before it is made.

Both of these are hard and involve risk.  Sometimes, the decision-maker will screw up.  Bad decisions will get made that could have been avoided by involving other teams or more senior people.

But the price of avoiding those mistakes is to live constantly waist deep in mud.  Everything you do, every decision you make, is a slow-motion struggle to make progress.  The cost may be less apparent, but in a world moving at lightning speed, can you afford to carry that kind of a burden?  As Teddy Roosevelt said, “in any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.”

The Sacredness of Ownership

sa·cred (sākrid) – secured as by a religious feeling or sense of justice against any defamation, violation, or intrusion; inviolate

The word “sacred” is not one to be used lightly, but I chose it on purpose to talk about a principle I believe is at the heart of any healthy team culture: ownership.  I’ve spent most of my career building large scale software projects, and these are intensely complex systems.  No one person can understand all that complexity and track all the infinite detail of a large-scale project.  And it only takes one person writing a few lines of sloppy code to introduce a security hole that can cause tremendous damage to your customers and to your company.  The success of the whole venture rests on the decisions that the people at the front lines of the team are making every day.  So they’d better feel like they own their work, and they’d better be right!

What It Means to “Own” Something

Does “owning” something mean you get to do whatever you want with it?  No.  In defining ownership, many people focus on making decisions, which is important.  But to me, the most important thing about being an owner is that you are accountable for the success of what you own.  Therefore, the first and most important thing that an owner should do is to define success.  This sounds easy, but it isn’t, and many people do this wrong.  If you are a developer and own a feature, success doesn’t mean that you wrote good code and checked it in.  Success means that the whole feature team understands the feature and why it is needed, you coded it, you nailed the basics like performance and security, it works well, it shipped, and many happy customers are using it to solve real needs that they have.  A good owner defines success in terms of impact, not activity.  They include key stakeholders.  They feel accountable for the whole success, not a narrow part of it.

It is very tempting to define success in terms of what you control.  This is a classic mistake that people make, especially when they are early in their career.  They only feel accountable for the part they fully control.  “But I’m the developer .. isn’t it enough that I write great code that works?”  NO.  The customer does not care if you wrote good code.  The customer cares if you solved their problem.  Shareholders don’t care if you wrote good code.  They care if customers love the product and buy a lot of it.  You need to feel accountable for the whole success, even though you almost certainly don’t control it.  If you did everything right that you control, and the feature fails to be successfully used by many happy customers, then you failed.  The reason this is so important is that people generally try very hard to succeed.  If you define success broadly, you won’t settle for the excuse that “my part works – it was the other bonehead who blew it”.  You’ll go the extra mile, you’ll escalate if somebody else is screwing up and taking the whole ship down.  It doesn’t matter how beautifully you polished the handrail on the Titanic.  You still drowned.

Decision Making and Overlapping Ownership

One thing that’s confusing about ownership is that multiple people can seemingly own the same thing.  For example, the people designing a product and the engineering team that builds it all need to own what they work on.  Doesn’t that violate the whole idea of ownership?  No, if you internalize the accountability model.  All of the groups contributing must feel accountable for the whole success of their work.

Great, but then how do decisions get made?  The answer is that it depends what you are deciding.  For example, the ultimate decision maker about the way to code a feature better be the developer.  But there are other stakeholders – developers might have to do a code review with their lead or a fellow developer.  They might need to follow development guidelines set up by the development manager, so other people can understand the code and it fits in with the rest of the system.  The designer needs the feature to actually meet the user’s needs.  The developer still owns the code and is accountable for its success, but they must honor the (legitimate!) roles of other people in achieving that success.

Stakeholders

Let’s say you are the owner and hence the decision maker.  One of your responsibilities as owner is to understand who else has a stake in the decisions you are making and what their role is.  Sometimes this is obvious, or you can just use intuition and it all works out.  That’s often the case in small teams.  But as you own more important and complicated things and are part of larger organizations, you will run into the limits of the ad hoc approach.  That’s when it becomes useful to think explicitly about the other stakeholders and their roles.

Once upon a time, the Windows team realized that decision-making was a mess – people weren’t sure whom they had to consult, who was the butt on the line for key decisions, etc.  And so things fell through the cracks or there was gridlock, and accountability was lacking.  As a result, they created a role/stakeholder model that has been used with a lot of success at Microsoft (called OARP).  There are industry equivalents (a popular one is called RACI) – which one you pick isn’t that important.  The key thing is to be explicit about the roles in a particular decision and make sure everyone understands what their role is.  Writing this down will often reveal misunderstandings (“what do you mean I don’t get to review the decision before it is finalized??!!!”) and problems (“we have to review this with twenty people before we lock the decision down?  That’s not going to work.”).  In general, the owner’s life and the team’s efficiency will improve radically as you reduce the number of reviewers, approvers, and other obstacles to progress.

Dealing With Misbehaving Stakeholders

Just because you have done a great job defining the ownership model and gotten everyone to understand it and agree to it in theory doesn’t mean that’s actually how things are going to work out.  People will frequently violate their role, often through the best of intentions.  Maybe your lead says you are the owner but they don’t respect your ownership and are always micromanaging you or giving direction to your team without including you in the conversation.  Maybe people elsewhere in the organization who are supposed to review decisions start turning into participants or are making decisions on your behalf.  And so forth – the opportunities for misbehavior are legion.  Sometimes they happen because people are too eager to help, often because people are being thoughtless, and sometimes from malice.

Your responsibility as the owner is to treat these as problems and get them fixed.  That super-helpful senior manager who comes down and straightens things out for you without you asking for help?  Problem.  Either you blew it, or that very helpful manager did, or you both did.  The participant who thinks you are blowing it as an owner and second guesses your decisions without confronting you about it?  Problem.

If someone in your management chain comes in and starts proclaiming this and that, there are two common reactions: 1) denial/rejection/anger and 2) “yes, sir, thank you”.  Both are wrong.  The right response from the owner is “good input, thanks”.  Then YOU go take action.  Don’t ignore what the manager thinks.  Sometimes they are giving you new data, sometimes advice (hopefully good).  Sometimes you are screwing up and they feel a need to jump in.  But if you are going to be a good owner, then you have to get the dynamics right.  You own the decision until ownership is taken away.  That should always be an explicit act – you might ask the manager to take over, they might inform you that they are taking over; that can be the right thing, but it is a very important change in the state of the project.  If ownership is leaving you and going somewhere else, you are no longer accountable for success.  That’s a big deal, and everyone needs to be clear about it.  You don’t have the right to demand to stay on as owner if your manager becomes convinced that you are not up to it.  You do have the right to demand clarity.

Final Thoughts

In my opinion, ownership is a crucial tenet of a healthy team culture.  How to take action on it?

  1. Figure out what you own.  Make sure everyone (including your manager) agrees.
  2. Define success.  Don’t be narrow.
  3. Figure out who the stakeholders are and respect their role.
  4. Go own the hell out of it.  Everyone is depending on you to get it right.