[teampractices] The Rule of Three (+1)

[Tomasz Finc]

Thanks Arthur. To make it even simpler.

Think about the person who's joining tomorrow. How will they know why
you did something?

If you ask yourself that question then it doesn't matter wether your
remote or not.

--tomasz

On Tue, Sep 17, 2013 at 11:30 AM, Arthur Richards
<arichards at wikimedia.org> wrote:
> 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
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>