SEUL-Leaders: seul management design

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

i've been thinking over how to organize the leadership structure and division
of labor for the seul team.  currently, i have a lot of stuff in a heap of
disorganized paper.  i will try to get the basics out here now, so people can
start critiquing.  i know this email is pretty sketchy.  there will be a
"real", detailed report later, after some review of this stuff...

this is basically an outline of what sort of development project seul
looks like, thus what its needs are, and my suggestions for an appropriate
structure to make things succeed.  my suggestions are influenced mainly by
personal experience with software development teams (small-medium scale
projects, both managing and coding), reading i've done on software
engineering, and logic.

I. general form of the seul project
  on a scale of small-medium-large-huge, seul is going to be around large,
plus/minus.  it will be bigger than many medium sized apps that some of us may
have already worked on.  it will be about the size of a large commercial-grade
app.  it will not be a huge project, such as a full commercial o/s (integrated
kernel, ui, app, toolkit, etc development).
  seul will also be a "system" project, where many apps will have to function
together to build a cohesive whole. this is very important to keep in mind.
  seul should be doable in a reasonable time (months to years, not decades),
by a team of roughly 100 developers functioning together at various levels,
to produce a useful final product.  it will not be the be-all end-all of
o/s environments as such, but with reuse of products from other development
groups (linux kernel, a well-supported package manager, a good ui toolkit,
etc), it can possibly be combined into what would qualify as a "huge"
development project, though it is important to keep in mind that the bulk
of our development team must be focused on getting seul out the door in
reasonable time, not on, say, developing revolutionary ui innovations,
which are a 100-person project in themselves.
(see seul mission statement etc, for more details on our exact goals...)

II. resources
  resources available: we have about 80 people (?) on seul-project, and 
5 leaders, with more people inquiring to help.  several people, both on
seul-project and in the leaders group are quite experienced/skilled in
programming, with expertise available in various areas.  not many people
seem to have huge experience in management, though i may be mistaken on
this.

III. organization and rationale
  since this is a large-scale system project there will need to be some
enforced, high-level organization to the project design, or else parts will
not fit into a common scheme, and things will be bad in the end.  it has been
shown that system projects like this work out best if the official word
on what everything should turn out like come for 1-3 systems architects
(with just one chief architect just to be extra sure about stability)
who must be experienced in designing "systems" in the sense mentioned here,
so that labor can be broken up and communication and error both minimized.
systems architects are essentially responsible for producing a "manual" for
the product.  they define what pieces the user should have access to in
the final product, the user interfaces to those pieces, at least at an
abstract level, and how the pieces interact with each other, and what
conventions must be followed for the pieces to truly look integrated.
  note that the systems architects must be extremely detailed in their
design work (thus making this quite a time consuming job), though there
is still plenty of innovative work left for everyone else.  as i've heard
stated: a system architect should be able to describe an implementation for
any spec he writes (if prompted), but he should leave the actual
implementation choice up to the individual subgroups, and be prepared to
accept any reasonable implementation produced.  also, note that these guys
do not hide in a dark smokefilled room for a week and return with an absolute
plan; they take advice from anyone they can into account when designing;
they are not perfect and rely on other people's advice to get all details
figured out, but they are the final word when it really comes down to an
exact system spec.  this is necessary for keeping the system unified.
  for seul, i suggest 1-3 systems architects.  i will be one sys arch, if
we do not get more qualified people to do the job.  (i _am_ qualified, but
i will not deny that there are 3 people who could be much better, and i will
not try to keep them out if they volunteer.)
  in addition, i think we need precisely one top-level manager.  this person
will need to keep up to speed on the systems architecture, though not needing
to know all the trials and tribulations the sys archs go through - just the
final spec.  he must then continually communicate with the individual dev
teams to make sure their ideas of the product they are implementing are
in line with that of the systems architects.
  finally, there are the individual dev teams.  see omega's outline
(in cvs structure/groups/, or in the archives), for the general idea.
there should be a few amendments but i will not list them now - they're
just picky details that can be ironed out.  more importantly, each dev
team should be structured as follows.  there should be 1-2 team leaders
on each team.  specifically, one of those team leaders (or the only one)
should be something of a technical wizard, experienced in programming in
the area that the team is working on.  if possible, there should also be
a second leader, more oriented toward management and communication, but
also fairly knowledgeable in technical stuff.  each leader should be
fully capable of taking over for the other, although obviously the arrangement
is to emphasize individual qualities when things are running smoothly.
it is, as i implied, also possible to have just one leader who does both
jobs, though it will be much less pressure if a team can have two.  in
addition, each team should have about 10 members max who are working fulltime
on it.  the exact organization of these people is up to the team leaders,
although there are some proven successful designs that will be expected to
appear in some form or other...
  one more important thing to note, which is probably not obvious, is that
we want to put very good coders in the team leader and sys arch positions.
this does not mean we are completely losing good programmers from the
dev teams though.  the sys archs should do some programming or other activity
in strategic areas when needed, though their main task is still specs - they
will have to restrain themselves from joining in things that other can do
as well, but be expected to do stuff out of architect character on occasions
when it's appropriate.  the dev team tech leader should do a *lot* of coding.
he will be responsible for keeping the team's project unified and in line
with the overall plan, by laying implementing the overall design so as to
facilitate that goal.  his job is to make sure the individual team programmers
are working under a structure where they still have plenty of non-grunge
work to do, but there is enough groundwork for them to be able to do things
in the "obvious" way and have inter-group interactions work out magically.
this is a pretty time-consuming job - hence the reason that an additional,
more managerial, leader is good for taking the load of more common,
day-to-day interactions, and double checking things, and picking up any other
leadership slack, off of the tech leader.


IV. sketch
  so here's roughly what things should end up looking like.  the lines
are communication paths.  "boss-ness" should be understood from the
discussion above.  beyond those requisites, it is not really important;
everyone is equally essential, and different people have say on
different things.  (i know the discussions been pretty sketchy - the *exact*
say people have will be nailed down more exactly and formally - but not in
this email.  you'll just have to trust my conclusions for a few more days.)


      +-----------------------+-----------+----+----+--...
      |                       |           |    |    |
sys-archs (1-3)    - - - main project - - + - -+- - + - ...
(1 chief sys arch)          leader        (various development team leaders)
      |                       |           (about 6 groups or so)
      |                       + - - >     (each headed by tech/management
      |                                    leader, with max 10-person
     \_/                     /-\            regular team)
    (specs) = = = = = = = = = = = = = >> 

notes:
 o sys archs need to be good coders and large-system designers.
   primary reponsibility is specs, though coding tough bits, and helping
   out other programmers when appropriate is not out of the question.
 o team tech leaders are coders, and that is their primary job (in the
   structure-defining sense described above, plus as necessary to help
   out team members to learn technique or get through tough code chunks).
 o team management leaders should be completely interchangeable with tech
   leaders if necessary, though their normal role will be more for
   communication and organization, and assisting wherever there is slack
   that needs to be taken up as well.
 o main seul project leader should have a firm understanding of tech, though
   needs not be a coding wizard.  he needs to be able to understand the
   system specs, *communicate* with everyone, check on the actual code
   getting written, and make sure everything is in line, or notify the
   _right_ people if it isn't.
 
the jobs above will take about 8-16 people depending on just how we end
up with resources.  each major section (sa's, pm, and each individual team)
should have at least one extremely-qualified leader, with a fair amount of
time available to put into seul.  in addition, there is space for about
6ish teams times 8ish members = 40 or so addition developers that we can
count on regularly to do work in specific specialized areas.

plus, there will be other developers who come and go or contribute parts,
and can fit in doing temporary or lightweight coding jobs wherever best.
the contact person is the main project leader - he should know the state
of the project well enough to know where to send people, or who to ask.

also, note that this entire discussion pertains only to the project
development team's structure.  there will also be a few additional groups
to deal with things like publicity (omega, juhana), with hardware/sysadmining
(cyber, omega, luka), and with treasury (omega?, cyber?, this needs to be
resolved), etc...

the exact layout of everything is forthcoming (with holes where you probably
expect them).  and i know my ascii diagram turned out terribly.  but
hopefully this is enough to give people an idea of how the dev team structure
is being planned, and get some feedback if i did anything stupid.

expect that exact group structure doc soon, as well as the actual seul system's
design doc, which is the other thing i've been working on concurrently.

-luka
----------------------------------------------------------------------------
Simple End User Linux Leader Mailing list
----------------------------------------------------------------------------