[teampractices] The Rule of Three (+1)

Tue Sep 17 18:30:52 UTC 2013

To piggy back on this, the mobile web team also has a rule that all
decisions be communicated on the team's mailing list. This ensures that
/everyone/ is, or can be, aware of decisions that have been made, and also
archives the decision in a way that is easy to refer back to in the future.
This is particularly useful for remote staff when decisions get made either
in a group of three or otherwise in some ad-hoc fashion to which other
members of the team may not be privy.

On Tue, Sep 17, 2013 at 10:39 AM, Tomasz Finc <tfinc at wikimedia.org> wrote:

> CC'ing  (teampractices at lists.wikimedia.org) so that their aware of this.
>
> This is what has enabled the mobile web team to have a balanced
> decision making process that shares ownership across design, product,
> engineering. This removes a lot of the asynchronous coordination you
> would have to do after making an individual decision.
>
> It's not always easy to get three people so good luck on the +1.
>
> I'm really eager to see how it turns out and do lets us know on the
> team practices list.
>
> --tomasz
>
>
> On Tue, Sep 17, 2013 at 10:24 AM, Terry Chay <tchay at wikimedia.org> wrote:
> > Hopefully I sent this to Nick Wilson :-)
> >
> > First of all, make sure all of you are on the e2 mailing list, so I won't
> > spam you twice again. :-)
> >
> > …
> >
> > Tomasz can correct me if I'm wrong :-)
> >
> > The mobile team has a process point which they call the "Rule of Three."
> > Originally, this came from Tomasz and Howie's observation that
> discussions
> > involving three people have a different dynamic than discussions
> involving
> > two. But the way it was adopted by the mobile web team was that when a
> > discussion was going on with respect to mobile features or process, to
> make
> > sure there was one representative from three departments in the
> discussion
> > before consensus is reached. That usually meant Maryana (Product
> Manager),
> > Jon Robson (Engineering Tech Lead), and Vibha (Design) would get together
> > and hash things out by consensus.
> >
> > …
> >
> > I think a variation of this idea is worth adopting. Whenever there is a
> > discussion going on in Flow in one team, to make sure one of three areas
> is
> > represented there. For instance if an engineer has an idea for a new
> > feature, or a reinterpretation of an existing one that is beyond just
> > completing development, just make sure to find at least one person in
> > Product and one person in Design before proceeding/resolving/having the
> > autonomy to do anything. If you can't drag the missing person in, just
> ping
> > them on IRC on #wikimedia-corefeatures and relay the discussion there.
> >
> > The variation is that I'd like community/product analysis to be a part of
> > this. From a logistical standpoint, it'd not practical to turn this into
> a
> > rule of 4, so I'd like it to make three (plus one). This means the rule
> of
> > three to resolve, and the missing leg would be informed as soon as is
> > reasonable (and can provide their input then).
> >
> > I think this will make sure ideas achieve consensus before proceeding as
> > well as create group autonomy. To the former, we don't want a discussion
> to
> > occur without being informed by each of the expertise of our focus
> areas. To
> > the latter, we don't want the Flow team to operate from the top-down
> (from
> > the director-level), a good idea can come from anywhere.
> >
> > Let's see how that goes.
> >
> > To my knowledge the focus areas are:
> >
> > Product
> > ======
> > Maryana Pinchuk
> > (Howie Fung)
> >
> > Engineering
> > =========
> > Erik Bernhardson
> > S Page
> > Matthias Mullie
> > Andrew Garret
> > Benny Situ (he will move up to #3 after he's onboarded in Flow)
> > (I do not count!)
> >
> > Design
> > ======
> > Brandon Harris
> > May Galloway
> > Vibha Bamba
> > Jared Zimmerman
> >
> > Community
> > =========
> > Oliver Keyes
> > Nick Wilson
> > (community members to follow?)
> >
> > Whenever you are in a conversation about Flow other than just completing
> an
> > already agreed assigned task (MVP, the backlog, a new feature/design,
> etc.,
> > not just doing the design, development, or editing Mingle as previously
> > agreed), make sure you have three people from different areas before
> > proceeding or the discussion didn't happen. After anything is resolved,
> > inform someone from the missing focus area as soon as possible.
> >
> > Feel free to change the people in the focus areas (or opt-out), but let's
> > try it this way and see how it goes. We can tweak it later if it isn't
> > working out, but I think it's a good idea worth testing out.
> >
> > Take care,
> >
> > terry
> >
> >
> >
> > terry chay  최태리
> > Director of Features Engineering
> > Wikimedia Foundation
> > “Imagine a world in which every single human being can freely share in
> the
> > sum of all knowledge. That's our commitment.”
> >
> > p: +1 (415) 839-6885 x6832
> > m: +1 (408) 480-8902
> > e: tchay at wikimedia.org
> > i: http://terrychay.com/
> > w: http://meta.wikimedia.org/wiki/User:Tychay
> > aim: terrychay
> >
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130917/97d2c24a/attachment.html>