[tor-project] (FWD) Team-based structure (Vegas Plan, mark 2)

[Roger Dingledine]

Hi Alison,

Here's the mail from last summer, with the "new" (as of then) organization
and coordination plan. Hopefully this will be useful to you in figuring
out the past, present, and future for the community team.

I am also cc'ing tor-project here, since there's nothing sekrit in the
below mail, and we should get into the habit of publishing stuff that
used to maybe be sensitive but now probably isn't.

--Roger

----- Forwarded message from Roger Dingledine <arma at mit.edu> -----

Date: Mon, 25 May 2015 09:02:22 -0400
From: Roger Dingledine <arma at mit.edu>
To: tor-internal at lists.torproject.org
Subject: Team-based structure (Vegas Plan, mark 2)

Hi folks!

In my last mail I mentioned the topic of org structure. In my mind the
main goals we're trying to solve with a better-understood structure are:

1) Better communication and coordination, both inside the team and
between teams.

2) Give everybody a home. That is, have a named person who can help
you when you need help with something (there's a conflict between you
and somebody, you need some specific resource to accomplish your tasks,
you don't know what you should work on next, ...).

With that in mind, here is one way we could divide up into teams:

---------------------------------------------------------------------

Community team
  Kate
  Jake
  Harmony
  Leiah
  Nima
  Sebastian

Network team
  Nick
  Yawning
  George
  Dgoulet
  Andrea
  Isis
  Aaron Gibson

Applications team
  Mike
  Geko
  Pearl Crescent
  Arthur
  Nicolas
  Arlo
  Sukhbir
  Support team

Measurement team
  Karsten
  Arturo
  Philipp Winter
  Virgil

Operations team
  Tom
  Steve
  Sue Abt

---------------------------------------------------------------------

Some observations to help you understand why I made these choices:

- I called the community team that name rather than outreach or advocacy
or communications because its focus is on our people, inside and out:
communicating to them, learning from them, getting them involved in making
more Tor. So it includes Tor Weekly News, making the website accessible,
handling press, doing trainings and conferences and materials to go with
that, and all forms of outreach.

- The "network" team is what I would have called the "tor" team, but
Nick used the word 'network' once so I'm using it here. This is the
backend: the program called Tor, the pluggable transports, the bridge
distribution, the network simulators, the scripts that support directory
authorities, etc.

- The applications team works on the programs that end users think of
as Tor: Tor Browser, other apps that bundle Tor, the equivalents on
Android/iOS, and builds and QA for these applications. This team also
works on enabling users to actually use these applications: that includes
phrases like UX design, documentation, making sure that users can find
answers to common questions, and making sure that developers know which
questions are common so they can prioritize them.

- The measurement team mashes together metrics, OONI, badexit detection,
onionoo and the community websites that draw from onionoo, and the
research groups who care about our data.

- And lastly, I put an explicit operations team on the list, even
though it is small and probably doesn't have enough people on it to do
everything it will want to do. But I realized that if I didn't list it,
I would be reinforcing the assumption that "operations team" and "execdir"
are synonyms.

- There are other tiny and lonely teams that I didn't list. For example,
we might imagine an "infrastructure team" with weasel and qbi on
it. But I'm wary of loading our kind volunteer sysadmins down with the
communication responsibilities of being their own team. I guess the other
conclusion there is that we should sketch out which teams are missing
now compared to the future well-functioning and better-balanced Tor,
and figure out a plan and timeline for getting from here to there.

- Some of the choices could easily have gone another way. For example,
why is the badexit detection work in the measurement team, and not in
the network team? Is Tails part of applications, or part of community?
We'll need to adapt based on what's working and what isn't working.

- There are many people and groups that I didn't list in the above. That
doesn't mean we don't like you, or that you're less valuable than the
people I did list. I mostly focused on the people who get paid in some
way for this work. Many of our volunteers fit into multiple categories
(e.g. Matt Finkel could be community, could be network, probably
could be a third as well). I'll leave it to them which team they want
to be their 'home', also keeping in mind that these don't need to be
permanent decisions. So think of this as an opportunity to choose your
own destiny. :)

- You'll notice that Isabela and Roger aren't in the list. That's because
I've signed us up to be facilitators of the whole process. Maybe that
means you can think of us like being on every team? We should be careful
of accidentally thinking of these two people as k+1 people each though.

- You'll also notice that these teams are broken up by functionality and
purpose, not by funders. So for example we don't have a SponsorR team,
even though that project ties together many teams. So we're going to
need to cooperate and coordinate between the teams to keep various
funders happy.

---------------------------------------------------------------------

How do the teams work? You'll notice I didn't call out 'team leaders'
or 'managers' or the like.

The goal, original Vegas plan style, is for each team to self-organize
so it can fulfill its responsibilities. Some teams will pick a person
to be their primary person. Other teams will divide up responsibilities,
or trade off, or whatever works for them.

That said, I did list a person at the top of each team who I'm hoping
will be instrumental in leading the self-organizing.

---------------------------------------------------------------------

What are the responsibilities of each team? That's something we should
work through together. Here are some we might choose:

- Keep everybody inside the team coordinated on what needs to be done,
who's doing it, how it's going, etc.

- Summarize for the other teams what your team is up to -- what you've
done and what you want to do.

- Summarize for your own team what the other teams are up to. That
is, here is one way to solve the n-to-n communication scaling problem.

- Solve problems inside your team when you can, and when you can't,
escalate them to get help from the other teams. That is, part of the
team responsibility is to help the other teams when they have problems
they can't solve internally. As opposed to turning me into the central
manager for everybody -- one day we might have a dedicated operations
director who magically fills that role, but we're not there right now,
and we're probably going to be happier if we're better at handling
issues as a team of teams.

- Maintain the roadmaps for your team, including brainstorming things
you should do that funders would pay for, and helping to frame these
for funders so it's clear why they should. Some teams will do their
own grantwriting, whereas other teams aren't set up right now for being
good at it themselves. I'd like to resist having a separate 'fundraising
team', since that's a great way for teams to pretend that it's somebody
else's problem. This topic also ties into our general "how we want to
get funded" discussions -- in the future it can't all be writing grants.

In the past we've gone to new funders with peripheral (experimental)
projects, which has been risky because we don't always put the
organizational resources behind them to ensure their success. I think
our better strategy in the future is to do more fundraising by the
core projects, and use this funding to do the peripheral experimental
projects. For example, raise money for Tor Browser to generalize Tor
Launcher to make it easier to build things like Tor Messenger. More on
this topic later.

- One thing that's missing in this plan is the more traditional
"manager" roles: doing intra-team performance reviews, identifying
when people aren't pulling their weight, working to resolve issues
like this. I worry that doubling up the roles will, in Karsten's words,
"change the character of the team idea from a supporting structure to
a power structure." Is our best plan there to continue stalling until
we get the operations team more up to speed? Input here would be great.
(A supporting structure is still helpful here, because it gives more
chances to answer the question "What is so-and-so doing?")

Next week (June 4-6) some of us are getting together in Boston to discuss
structure among other topics. Somebody from each team will be there. So
please discuss amongst your team if there's some outcome or direction
you want us to be sure to include.

--Roger

----- End forwarded message -----