Meetings I Actually Like

 

This meeting is face-meltingly good.

While it may come as a shock, there are actually some meetings that I find useful.  It really isn't that hard to come up with something beneficial, but the nature of companies and people's reluctance to buck comfortable habits tend to regress to poor outcomes.

However, any meeting that has a clear agenda, a vetted set of attendees, and a group that's done some prep work ahead of time is likely to keep me engaged.

Since the cynic in me doesn't expect that is going to happen, I'll talk about the categories of meetings I do find useful on a consistent basis.

1-1s

In daily practice, this tends to be a terrible meeting, as it's just a more uncomfortable attempt to garner a status update, but that's not what it should be.  A 1-1 is your employee's opportunity to speak with you candidly about issues they find important.  

Your first order of business as it relates to this meeting is to address their concerns.  Only if they don't have specific topics should you bring any outstanding agenda items to the forefront.  On the (hopefully) rare occasions that you need time to address a performance problem, you should set up a separate meeting and be clear about the topic, so your employee doesn't feel ambushed.  Surprising some with bad news, even if there are warning signs that you expect they should see, is never a good way to carry on a constructive conversation.

Otherwise, any reasonable topic is fair game for a 1-1.  If an employee wants to bitch about co-workers, you don't need to simply be a passive listener and nod along, but do your best to understand their perspective.  If it's a one-time thing, it's a one-time thing - people just need to vent.  If it persists, you'll need to take a more active role to either correct the problem or help your employee understand why their perspective may be skewed.

Regardless, that's the benefit of the 1-1.  You're creating an opportunity for the employee to provide candid feedback that may otherwise be missed.  If you're spending the entire meeting droning on about status or forced career feedback discussions when all they want to do is complain about the co-worker who's microwaving fish every day, you're subtly indicating that their time isn't as valuable as yours, which is a precarious view to take as someone who relies on others to accomplish your goals.  

As I've said repeatedly, there are a million other ways to collect status reports, and the 1-1 is not one of those avenues.

Another thing to note for 1-1s is to be consistent.  I block off 30 minutes for every employee every 2 weeks.  I also do my best to ensure the 30 minutes after the meeting is generally free in case we want to extend the discussion (this is the only meeting I'm ok with extending on an ad-hoc basis).  

Due to the tyranny of corporate meeting scheduling, it's not uncommon to need to reschedule to another day nearby.  That's fine.  What's not ok is to consistently cancel and not reschedule.  1-1s are one of the best ways to track, maintain, and improve employee engagement.  Not holding consistent 1-1s is another clear signal that you don't value your employee's time.  If the employee wants to cancel or cut the meeting short, that's fine, but it's your responsibility to give them that opportunity.

Another corollary - if the meeting falls off your schedule, it's your responsibility to reschedule, not theirs.  You want to send the signal that they're important and making sure they're top of mind sends that signal.  If you're thinking "it's their meeting, so they should schedule it if they find it important," you need to rethink exactly what your role as a manager is.  Avoiding your employees or being passive about engaging them seems odd for someone whose entire job is, well, managing people.  

If that is your thought, don't fret, you're in, er, company.  The world is littered with sub-par managers who are where they are because they think they deserve a modicum of misplaced power.  But don't be one of those people.  Your soul will thank you, as will your employees.

Retrospectives 

Retrospectives (or Retros) fall into the generally reviled class of Agile meetings that everyone hates and the one that's rarely held, or if it is, diverges vastly from how it was originally prescribed.  While I can simultaneously mourn the loss of the stand-up and place it on my list of detested meetings, I can also say that I find the retro important (extremely so) and say there are moments where I regret keeping it as a standing meeting.

As with most meetings - Agile ones in particular - this meeting can wander into painful territory if not held in check, so it's important to rein it back to its basics.  There are two components to a successful retro: 

• An enumeration of good and bad events in the sprint (the work unit duration denominated by small-a agile practitioners - usually two weeks, beginning on a Monday and ending on a Friday).
• Everyone's individual face of pain for the sprint (more on that below).

Both of these seem trivial and they can be updated asynchronously, but this is one meeting that I think merits meeting in real-time.  If 1-1s are a chance to gauge your employees' morale individually, the retro is a good gauge for the team as a whole and a spot check on their interactions with each other.

Listing the good and bad events of the sprint helps the team strengthen their individual ties and recognize the perils or triumphs that may have been lacquered over during the course of the sprint.  This allows the team to celebrate successes during an otherwise shitty sprint or may strengthen their ability to sympathize communally during a particularly bad sprint.

As a little meeting sugar, I typically refrain from just listing the headings "Good" and "Bad" on a wiki page.  Instead, I'll inject opinionated, topical (but still whimsical, if corny) substitutes to help the team ease into what can, at times, be a tense meeting.  For instance, instead of "Good," I may write "Godfathers I and II" and for "Bad" I may write "Godfather III" (fight me on this).

Often that will kick off a mini tangent that helps warm the team up (especially during bad sprints) before delving into the sprint's details.

After giving the team 10-15 minutes to scan their collective memories, we'll move on to the faces of pain, a medical construct co-opted by software engineers to determine their level of stress/satisfaction over a sprint.  The faces we used ranged from 0 (no pain; I might be dead) to 5 (3 Stooges level of pain; I might be dead soon; please kill me).

Again, while this might seem trivial, it provides valuable information.  Collectively, it shows the overall health of the team.  It also helps you gauge whether or not your own expectation of the sprint's outcome is correct.  If the entire team is doing well, except for one individual, it may indicate someone's getting the brunt of busy work or feeling under-appreciated.  

If everyone's unhappy and they didn't previously communicate their unhappiness, it gives the team collective bargaining power to complain that they may otherwise shy away from for fear of being the squeaky wheel in isolation.

If everyone's happy, great!  But pay attention to whether or not they're papering over pain.  

[Note: I also forgot to mention that, in addition to listing their face of pain, they need to mention the reasoning behind their number, otherwise you'll miss a lot of valuable information when reviewing your notes later.  Also, make sure you're recording all of this.]

That's pretty much it.  If time permits or if I have something important to relay, I'll use the time as a team meeting (in conjunction with stand-up) rather than borrow people's time elsewhere.

What the retro is not is a sprint planning session or an in-depth review of every agile task for the sprint (which is yet another way to sneak status into a meeting.  How many status updates do managers need?  How insecure are we?)

Also, if, for some odd reason your "sprints" extend much past 2 weeks, make sure you're holding retros in the interim.  You want a reasonably frequent, consistent cadence for feedback and 2 weeks isn't overbearing or glaringly infrequent.

Envisioning Meetings

Envisioning meetings are used for designing and planning large projects.  The idea isn't to scribble out every little detail.  The idea is to do the following:

• Identify the current needs and assumptions of the proposed project.  Sometimes the assumptions don't match the needs, and it's a good idea to get the engineers together to ensure that you're not building the wrong thing or building something that's way more complicated than it needs to be.
• Identify the major milestones for the project.  Don't handwave over difficulties, but don't attempt to discover every possible problem here.  That discovery phase is part of the project, and should be baked into the timeline that you're building.  Unknowns are fine, but outright declarations of defeat are not.  If someone believes a project is untenable, they should be able to enumerate why.  Either way, expect to spend a reasonable amount of time exploring options throughout the course of the project and build that into your estimate.
• Gather estimates for the major milestones only and don't settle on one, canonical number for the estimate.  Large projects have variability and therefore need to have a range built into their duration estimates.  Don't attempt to plan out every little task - this is akin to measuring a coastline in smaller and smaller increments - you will never come up with a correct estimate and you will spend more time estimating than is practical.
• Decide on a relatively large duration for the smallest increment.  I typically use a sprint.  Sure, some things may take way less than a sprint, but some things that are estimated at a sprint will take more time.  Using a relatively blunt estimate for the smallest duration allows things to average out.
• Don't flat-out deny engineers' estimates.  You should challenge them on their assumptions, but if they say something is going to take 3 months, it's very likely that it will take 3 months.  

That's it.  At the end of the meeting, you should have milestones for development and ranges of time for the delivery of those milestones (including the total project duration).  Do not succumb to the urge to give your boss the most optimistic (or the most pessimistic) estimate.  Give them the range and the assumptions behind those ranges.  Something that's large enough will have a variability of 4-6 months.  You cannot will it into being 4 months.  

It's possible that you're making erroneous assumptions, but that's why it's important to show your work.  Maybe you have an available software package that handles work you thought you'd need to build out, shaving a month of your expected duration, and your team was unaware, but someone else checked your assumptions.  Voilà! Now the project is down to 3-5 months.

As for running the meeting, it's not unusual for it to take 2-8 hours (possibly more, but at that point, you can probably break it up into further sub-projects that can be tackled by separate teams).  Ideally, it should be colocated, given the fluid nature of the conversation.  If that's not possible, you need access to good whiteboarding software or a very detailed note-taker and the patience to review missed conversations as a result of virtual meeting fatigue and technology snafus.

In either case, any individual session should be no longer than 2 hours and you shouldn't have more than 2 sessions in a day.  Assuming you can cram 8 hours' worth of work into a day will make everyone cranky and degrade the output at the end of the session.  Your projects are likely going to last several weeks to several months, so an additional day to keep everyone fresh isn't going to hurt.  

If you have the luxury, split an 8-hour envisioning session out over 4 days.  Even though the meetings tend to be long, engineers typically enjoy envisioning meetings because it's a chance to flex their creative muscles on upcoming projects.  It sets the tone for the whole project, so the prospect of what are essentially engineering jam sessions is something they look forward to rather than shun.

And those are my good meetings.

Until next time, my human and robot friends.