All posts by Eyejinx

Productivity, Project Management

Tips For Running Meetings

1 Comment

A lead artist at my last job said that I could run a meeting like nobody’s business. It’s an odd compliment. On the one hand, I’m happy to be recognized as an expert; on the other, I know that expertise comes from practice, and I’m not sure I like what that says about me. Meetings (formal, scheduled, official meetings) should be a last resort. They’re such notorious black holes for team time, energy, and focus that they should be avoided unless absolutely necessary. But, inevitably, you are going to need a meeting for something, and when that day comes, keep these tactics in mind:

  • Schedule early.  People need time to prepare for a meeting.  Make sure you get into people’s consciousness and not just their calendar.  Before you schedule a meeting, check in with all of the attendees and make sure they really need to be there.  Attach any relevant information to the appointment.  Meetings interrupt workflow, so try to give your attendees time to mitigate the interruption.
  • Own the meeting.  One of the simple things I started doing a few years back was to announce at the start of every meeting I called that it was my meeting.  This serves a number of purposes; it says that the meeting has officially begun; it orients everyone around the speaker; and it makes meeting organizers responsible for the productivity of the meeting.  Over time, other leaders in the studio started doing this, not because anyone pushed them to do it, but because it works.
  • Bring a clear agenda.  If you don’t have an agenda, cancel the meeting right now.  You (and everyone on the attendee list) should know exactly what you’re trying to accomplish in a meeting.  If not, you’re wasting someone’s time because you can’t be sure who you need if you don’t know what you’re doing.  Don’t go overboard here; an agenda is not a list of topics you’re going to cover, it’s a commitment to achieving resolution on certain issues.  Keep the agenda as small and focused as you can manage.
  • Limit the size. Communication efficiency decreases by the square of the number of people in the room.  I’ve heard stories about an EA exec who would walk out of any meeting that had more than 5 people in it; that’s a bit extreme, but it is good to keep meetings as small as possible, not just because of communication issues, but also because the more team members are in the meeting, the fewer are directly working on the project.
  • Stay focused. The biggest time thief in meetings are the digressions – personal stories, arguments for the devil’s advocate, getting side-tracked into some other issue, etc.  If the topic you’re trying to cover has so many dependencies that you can’t resolve it in one meeting, you’re doing it wrong.  Go back to setting a clear agenda.
  • End early.  In general, meetings lose efficiency around the 50-60 minute mark.  Everyone’s tired by that point.  If you have to go past that, take a break, but it’s much better to end the meeting, give people time to leave that context and digest, and set a follow-up.  Psychologically, meeting time is “lost time” in the calendar.  The shorter the meeting is, the more of that lost time you give back to your team, the more positive they are going to be about the meeting as well as freeing them up to get other work done.
  • Be explicit about action items.  Specify what is going to happen as a result of the meeting, who is responsible for getting that done, and what the timeframe is.  Meetings need to lead to results.  If they don’t, cancel them.  When the attendees leave, each of them should know exactly what is expected of them and when they can see the results of the other people.  Being responsible to the team is a powerful motivator.  Send this information around in a follow-up e-mail to all the attendees so that everyone knows this is being tracked.  Repetition also helps with reinforcement.

The first rule of meetings is to avoid unnecessary ones.  If you’re going to have to have a meeting, though, make sure it is small, focused, short, and results-oriented.

Game Industry, Project Management

Triangle-Class Problems

Leave a comment

Most project managers are familiar with the phrase “fast, cheap, or good, pick two”.  It’s a classic formulation of a resource constraint tradeoff.  If you need it fast, you can spend more or lower the quality bar; if you need it cheap, it’s going to take longer or be lower quality; if you need it to be top-notch, you’re going to have to either spend the money or the time to get it there.  This triangle of constraints represents (in some ways) a particular version of balloon-class problems: squeezing any one angle is going to put pressure on the other two; if you try to pressure all three, it’s likely to explode in your face.

In my experience, though, things are rarely so clean.  For example, where does scope fall in these constraints?  Is it a sub-set of quality?  And labor cost factors into both fast and cheap; even if you’re running a small team, burn rate X time = money.  The idea that spending more money can make things faster also runs into problems with critical path and non-segmentable work (see The Mythical Man-Month on why 9 women can’t have a baby in 1 month).  In team situations (and almost all game development is team-based), you also run into problems because communication efficiency scales inversely with team size, and scaling a team is a risky and time-consuming proposition.

People have tried to refine this triangle by making diamonds, or Star-of-David type diagrams, which really misses the point.  Project management is not a problem you can solve in the abstract.  Every team, every project has its own dynamics.  The triangle is a tool.  Like a forking move in chess, it allows the project manager to present clearly to other stakeholders that they must make a choice, and regardless of which choice they make, they are going to have to give something up.  It is a defense against outside forces who often want everything, or, for that matter, against inside forces that are not setting priorities realistically.  Its simplicity is its strength; it embodies the problem.

Even though it’s not the most precise formulation, it’s still a useful tool.  It allows you to negotiate without saying no, a valuable move particularly when you’re managing up.  On the flip side, if you recognize that you’re getting this a lot from your team, you need to revisit the project priorities, risks, and mitigation plans; something has drifted out of alignment, and you may well be the one who is drifting.