Killing old/slow groups - transition thinking

[Erik Guttman]

Margaret,

Thanks for your response to my posting.  I am trying to express that
one can use deadlines and rules to get folks to take timeliness
seriously.  I think this can be done without sacrificing quality.

Margaret Wasserman wrote:
>> 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.

The question to ask before chartering a WG is 'What can we finish
*with high quality* in (something like) 18 months or less?'  If the
project has to be of larger scope, can we finish a workable fraction
of it first?  If not, we are generally in for trouble!

   We will have to take on humbler tasks to complete them in time
   with high quality!!!

> 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.).

My experience is we do not trade off against quality and aiming for 
completeness gets us feature-bloat due to committee-based design.
Timeliness gets treated as if it were the lowest priority.

> 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.  

Deadlines are a sword with two edges.  The first edge is for trimming
the project before it starts.  The second is for cutting it down if
it fails to end.  No one (I hope) is suggesting that we wave this sword
around with our eyes closed.

 > 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.

If it were easier to publish a PS then patch it later when errors were 
found, we could refine and correct.  This does not work well when a PS
RFC takes years and years.

> 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...

This power is rarely used.  Since it is entirely discretionary, it
takes an exceptional situation (and AD) to apply it.  If it were
nearly inevitable that a slowly slogging WG would get shut down,
we'd avoid setting them up to fail and turn up the heat on to meet
real expectations.

> 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.

'Existing resources?' This assumes that we will keep working the
same way.  We can't do that at the beginning of a problem statement
exercise.

Erik