[UPDATE: The newest version of this presentation is here. joduinn 12feb2014, 09nov2014]

At the Mozilla Summit in sept2011, we ran a session on working remotely at Mozilla.

I was surprised/stunned/honored by needing to run this session *twice* because of popular demand, the sheer volume of interaction in each session and the ongoing interest since the summit.

Writing these slides, I realize how much I care about this topic… and how many careful subtle habits we’ve developed within RelEng over the last ~5 years.

During the summit, and again last week in Toronto, I had a chance to meet with Homa Bahrami (Senior Lecturer, Haas Management of Organizations Group, Haas School of Business, Berkeley). Apart from being a great person to talk with, she has lots of organizational and behavioral science background to help explain why the things that we felt were helping, were in fact, something she would expect to help!

(click image for PDF of slides; keynote available on request, but its large!)

As I said at the start of each session, at first it felt odd for a Release Engineer to be talking about work habits of distributed groups… until you think about how physically distributed Mozilla’s Release Engineering group is. I note, for the record, that *none* of RelEng are “in headquarters”. While there are occasional miscommunications, RelEng is fairly well plugged into whats going on… after all, we *need* to be in order to do our job of shipping software quickly, reliably and accurately.

To me, this feels like it actually is about working together in clearly understood ways. The suggestions here have helped “remote” RelEng people in clear and obvious ways, but they *also* help “local” RelEng people work together better.

Please let me know what you think. And of course, if you have ideas or suggestions that I missed, I’d love to hear them.

(Apologies to those who’ve been pestering me to post these over the last few months. Last week’s “remoties” day reminded me how important this is to post – even in its rough state. I’ve fixed the most egregious errors/typos, and merged in some feedback I got in the Q&A sessions. However, these slides still need further work. If you spot anything to fix, please let me know!)

Its easy to skip a blog post about how to run meetings – yawn – and skip on to the
more exciting posts about some new shiny tech topic. Don’t make the same
mistake I did. This is a quick read and will change your working
life.

Deb did a blogpost a while ago about how to run a more efficient 1×1
meeting. To be honest, I saw the post and skipped over it “Dont have
time to read that, and anyway, I’ve done lots of 1x1s – each unique to
needs of each individual, and they go just fine, thanks anyway”.

Then Coop, in his own polite understated way, told me we were going to
try this format. It worked great for Coop’s 1×1 with Armen, and he
thought it might improve Coop’s 1×1 with me. Our first meeting took
longer then usual, but that was each of us getting used to the
changeover. The second meeting, and all meetings since then, have been
much shorter than usual, and far more productive for both people!

Maybe its just something unique to coop and myself?

But it felt worth trying with a few other people, which I did over the
next couple of weeks. At that point, I was totally convinced. We now use
this for all my 1x1s in RelEng.

Why does it work so so well?

• Set the agenda a day in advance
  • too many 1x1s are impromptu, unprepared and therefore inefficient.
  • making sure the agenda is *not* set by the manager is important; this
    means people can make sure what they need is covered, and the meeting is
    productive to them.
• Sorted by time
  • the past: Talking about what you just accomplished helps set context,
    and helps even the most modest person discuss recent successes.

  • the present: Whats on your mind right now, typically blockers.
  • the near future: plans for the upcoming week help ensure both people
    agree priorities are right

  • the “far” future: Keeping the current work in context of a person’s
    career path, and in context of a group’s quarterly goals is tricky. Its
    easy for this to get pushed to the side in the day-to-day rush of work,
    but this format helps keep everyone aware of.
• Require video
  • its easy to get distracted in our constant-interrupt environment, and
    the video helps keep people focused on the person they are talking with.
    This in turn helps the meeting run much quicker.

  • some “remoties” resisted using video at first – “too intrusive” was a
    common reaction. However, it only takes a couple of meetings this way
    before everyone sees how 1x1s with video run more smoothly than
    phone-call-only. Facial cues and body language visual cues are super
    important – just ask anyone who’s got into a misunderstanding on irc or
    email!

  • this 1×1 can be the most direct human contact “remoties” with the
    rest of Mozilla all week. Video is a great reminder that the voice on
    the line is a real human, and some of the saved time at the end can turn
    into seemingly-unimportant-but-actually-vital non-work chitchat. The
    kitchencams are popular for a similar reason.

  The brilliance of Deb’s approach is that it is super low-tech and super
  easy to use. As engineers, we’re always tempted to look for technical
  solution to any problem, but the few attempts I’ve seen so far have all
  added complexity and got in the way. By contrast, Deb stepped back and
  revisited the essence of the original problem from a completely different
  perspective and I love what she came up with.

  Try her suggestion. If it doesnt work for you, go back to what you did
  before, no harm done. But maybe, just maybe, you will love it, and find
  yourself giving a silent “Thank you, Deb.” after every 1×1, just like I do.

  [UPDATE: Ben Horowitz just blogged about this also. joduinn 04-sep-2012]