[rfc-i] "Executive-level management": What is the purpose of the RSE?

Andrew Sullivan ajs at shinkuro.com
Wed Jan 5 07:42:55 PST 2011


Dear colleagues,

It seems to me that
draft-kowack-rfc-editor-model-v2-motivations-00.txt (henceforth,
"motivations") relies upon a deep but largely unexamined assumption:
the RSE position is "executive-level management".  There are
consequences (many of which are discussed in "motivations") that flow
from this: for instance, the incumbent will need to have more or less
complete authority over certain areas of the RFC Editor Function; the
incumbent requires a lot of prior expertise in the area of technical
publication; many policies and procedures need to be written and
adopted.

In "motivations", the RFC 5620 phrase "executive-level management" is
noted.  RFC 5620 does not actually define, as near as I can tell, what
it means to be "executive-level management", but the following passage
(from RFC 5620, section 3) seems to me to be the closest we get to
such a definition:

   In this model, documents are produced and approved through multiple
   document streams.  The four that now exist are described in [1].
   Documents from these streams are edited and processed by the
   Production Center and published by the Publisher.  The RFC Series
   Editor will exercise executive-level management over many of the
   activities of the RFC Publisher and the RFC Production Center (which
   can be seen as back-office functions) and will be the entity that:

   o  Faces the community.

   o  Works with the IAOC for contractual responsibilities.

   o  In collaboration with the RFC Series Advisory Group (RSAG),
      identifies and leads community discussion of important issues and
      opportunities facing the RFC Series.

   while the IAB and IAOC maintain their chartered responsibility.  More
   details about the collaboration with the RSAG and the IAB
   responsibilities can be found in Section 4.1.

   The RSE does not have the authority to hire or fire RFC Editor
   contractors or personnel (see Section 4.1.3).

I have fixed on this passage because of two important features.  One
feature is that the executive-level manager here described does a lot
of collaboration (with the IAOC for contractual responsibilities and
the RSAG for leading discussion).  The second feature is that the RSE
does not have hire-and-fire authority.

I agree quite strongly with the contention, in "motivations", that
nobody will take a supposedly senior-executive job with such
restrictions.  It is in fact not a senior-executive position at all,
since the incumbent can't execute anything without getting a lot of
agreement from others.

It does not, however, follow from that fact that the authority should
be redistributed to make the RSE job a senior executive job.
"Motivations" argues that, since the job is a senior-executive one,
authority needs to be redistributed to the RSE so that
theresponsibility and authority lie in the same place.  But even
though RFC 5620 calls this job a senior executive function, maybe that
isn't what we want.  Perhaps the update to RFC 5620 needs to say
something more like this:

  The RSE is a co-ordinator of the RFC Series, whose primary
  responsibilities are

    * to facilitate multiple communities' decisions about RFC Series
    policies; and,

    * to provide the necessary administrative support and publications
    expertise to the IAOC when the latter is preparing contracts.

(That is not a serious proposal, but just an illustration.)  

One reason I raise this is because the arguments in "motivations" in
favour of a "senior executive" function don't strike me as terribly
strong.  I've already listed in another message the examples I was
able to find of specific things that had to be done during the past
year.  While those are all non-negotiable areas of responsibility (on
the grounds that they actually had to be done, and someone needs to be
in charge of those things), none of them struck me as terribly "senior
executive" in scope.

Several of the arguments in "motivations" in support of a senior
executive are nothing more than appeal to tradition. For instance:

   Throughout its entire history, the Editor and the Series have been
   led by a single manager, beginning with Jon Postel and then Joyce
   Reynolds and Bob Braden.  The current success of the Editor and the
   Series is due significantly to this historical fact.

Quite apart from the totally unsupported causal claim there, the above
provides no reason whatever why the historical fact is guidance for
the future.  By way of analogy, throughout its entire written history
the geopolitical entity called Canada has had a monarch as head of
state.  One might think there are practical reasons why this should
remain so, but the mere fact of history is certainly not one of those
reasons.  That we've always had a monarch doesn't count on its own as
a good argument for why Charles, Prince of Wales ought one day to be
King of Canada.

Moreover, "motivations" seems sometimes to be arguing that, to be a
really serious organization, the RFC Editor has to attain that elusive
quality often called professionalism.  So, in section 3.3.1, we have
this:

   For the RFC Editor, someone has to own that effort.  The
   point person must vet it past experts, bring it to the community,
   anticipate the consequences of the different options, and be
   insightful at finding a suitable outcome when the right choice may be
   far from obvious.

   We need to acknowledge that such activities cannot be managed in an
   ad hoc way . . .

Similarly, in section 4.1, we see the following:

   [N]o one entity or person is assigned responsibility for bringing
   together all the different inputs from the Editor, plus input from
   the community and beyond, and making them all work together under
   the very serious demands of document production.  This is required
   so that the RFC Editor as a whole operates smoothly and
   efficiently.

[. . .]

   [RFC5620] distributes authority for the Editor across two
   committees and two managers.  This division is problematic.
   Committees are widely understood to be excellent at ensuring that
   multiple interests are addressed, but not at integrating inputs
   into a single, focused plan, nor for driving insights when
   developing such plans.  Committees also, often with the best of
   intentions, suffer from having divided interests.  Being comprised
   of members from disparate entities or parts of the community, they
   may, even unknowingly, have divided interests.  This applies to the
   management structure in [RFC5620].  Without some one person
   assigned responsibility for overall management and development of
   the Editor, the community has a very difficult, perhaps impossible
   job, of knowing who is responsible for what is being done, and whom
   to talk to when there is dissatisfaction.

This seems to me to depend on a bias that is not explicit: the
solution to a managerial problem is to delegate one person to hold the
responsibility and authority for that problem, and then to treat it as
a professionally-contained problem.  But this is not how one of the
main generators of RFC content (the IETF) operates.  In the IETF,
authority is in fact mostly distributed to committees without any one
person being effectively able to override everyone else all the time.
Some of the "committees" don't even have clear membership (who is a
"member" of the IETF? of a WG?).  Moreover, we work out things _ad
hoc_ all the time, because everyone seems to be willing to accept that
in a volunteer organization there are going to be strange but
unavoidable conflict problems.  We address the issue mostly with what
amounts to "reputons": if one is seen too often arguing a position
that seems only to be the Corporate Line, one's arguments get an
automatic discount factor.  None of this is codified or even, perhaps,
codifiable.  But it seems to work, perhaps because we are relying on
human judgement for exactly the kind of case where judgement is the
best guide; and perhaps because the IETF is still small enough that
people's professional reputations can still do a lot of work that, in
a larger (or more "professional") organization, would be done instead
by procedures and rules.

So, the IETF is not really a "professional" organization.  Perhaps
that is a bad thing, but we seem to feel that this mostly works for
us, despite that it leads to fractious, bitter, and drawn-out
arguments every time there is any discussion of how to do things.  On
the other hand, I note that the IETF is gradually accreting a lot of
the sorts of procedures and rules I'm taking about.

Now, the RFC Series is not only the output of the IETF.  Moreover, we
seem to believe that there is some value in having a series with a
consistent voice.  But that does not mean that the right job
description for the RSE is one that makes for a tidy org chart.

To me, then, we need to make a stark choice: do we want the RFC Series
to be organized and managed in a conventional way?  If so, then I
think I broadly agree with Dave Crocker's message from today: the
proposal before us is to align responsibility and authority with one
another, and while it may not be perfect it is a workable approach
(but one that appears to have some pretty serious side-effects on
things like BCP 101).  If not, then I think the problem with the
current proposal is that it answers the wrong question, presumably
because the wrong question was asked in the first place.  If we
redescribed the RFC Series Editor as a facilitator of consensus or an
important advisor to other bodies or something like that, then I
imagine the advice for how to make the job more appealing to someone
who could do that would be different than the advice Glenn has
produced.

For what it's worth, I don't have any clear feeling about which of
these directions is the right one.  But I doubt we're going to make
much progress until we come to a clear understanding of which of them
is the one we're really pursuing.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the rfc-interest mailing list