Killing old/slow groups - transition thinking

[Margaret Wasserman]

>I believe we would have behaved differently had there been a
>rule setting boundaries both for overall time and allowed slippage.

Rules are not a substitute for active and effective management.

Making a hard rule like "publish in 18 months or perish" will not
serve the community in the long run.  Neither will blind pressure
to meet milestones (i.e. deadlines) without any acceptance
criteria regarding the quality of the output.

Instead, we should have an active, high-level exchange between the
WG chairs and the ADs regarding the direction and goals of the
group, and we should work as a management team to achieve those
goals (with appropriate trade-offs concerning timeliness, quality,
completeness, etc.).

Lots of companies have fallen into a trap that I hope that we will
NOT fall into:

Because it is easier to measure timeliness (i.e. meeting deadlines)
in an objective fashion, that becomes the primary metric by which
engineering teams (and their managers) are judged.  The second
metric (also easy to measure) usually concerns the number of bugs
reported against the product, length of time spent in QA, or
something like that -- we'd probably count the "cycles" of
a document and/or measure time spent in the IESG.

No one has managed to figure out, at the time of release, how to
objectively measure the really important things:  (1) suitability
of the product to its market, and (2) the quality, extensibility,
reusability, etc. of the architecture and code.  So, these things
get short shrift from engineering managers and engineering teams.


>I agree that exceptions occur.  But I do not agree that every
>situation is an exception.  We need rules to increase the pace
>of our work, to bring discipline and realism to our charter
>milestones, and to empower if not demand that the IESG to apply
>the scalpel.  I agree with you, Marshall: Exceptions must not
>be the rule.  They need strong justification and should come up
>for regular review.

The IESG is already empowered to employ the scalpel.  WG chairs
serve at their pleasure, and they can shut down WGs without
even discussing it publicly...  This isn't something that any
responsible person (and all of the IESG members are, certainly
responsible people) would do lightly, but the IESG does have
the power...

What I actually think that the IESG lacks are the management and
organizational skills necessary to effectively run an organization
of this size and complexity.

I don't mean that as a personal slur against any IESG members.
I think that all of them have exceptional skills in other areas:
they are technically profound and most of them are natural leaders.
They also all have the talents and abilities to be good managers,
but they lack the skills which come from training and experience.

I don't know exactly what to do about this...  some thoughts:

         (1) Fund some management/organizational training for
                 our current leaders.
         (2) Appoint a different set of leaders that will better
                 combine technical profundity and management
                 skill (either in each person, or by having one
                 of each for each area).
         (3) Reorganize the IETF so that the keepers of the
                 technical quality gateway are NOT the same
                 people who are responsible for running the
                 process and managing the organization.

Thoughts?

>In my experience WG completion delays arose in no small part due
>to very slow and vague IESG reviews and worse - document action
>black holes which took months to clear up.  This has improved,
>though only recently.  Novel suggestion:  I think charter deadlines should 
>*accomodate time required for IESG review!*  The IESG should
>not charter more than they can actually review.  The IESG should
>then meet these commitments.  What do we do if the IESG cannot
>meet them?  We would have to cut the charter of the IESG.

I agree that it is important that we come up with some way to
hold the IESG more accountable for doing their work in a timely
fashion.

The visibility afforded by the ID Tracker will help us see what
is happening, but it won't necessarily speed things up and/or
make things more predictable.

What we need to do, as you allude, is prioritize our work...
Right now, we have some fixed capacity to do quality work, so
we should not take on more work than we can process.  The only
way to achieve this, IMO, is to prioritize incoming work
requests (from existing and new WGs) and reject work that
isn't high enough priority to get its share of our existing
resources.

The first place I think that we should look is at the side
track for publication of informational/experimental RFCs.
Why does the IESG need to review all of the weakly academic
documents that the RFC editor wants to publish as Info, just
to see if they overlap the IETF and/or meet our guidelines?
Perhaps we could set-up a separate review group to handle
this task which would only bump the real problems up into
the IESG?

Margaret