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

Ted Hardie ted.ietf at gmail.com
Wed Jan 5 09:26:51 PST 2011


Andrew,

Thanks very much for putting this well-thought analysis together.  Rather
than snip it up to go +1 a lot, I'd like to excerpt one piece from the analysis
and comment:

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

I'd like to add that I believe making it a true senior executive job
is likely to cause friction between the normal workings of the IETF
and this executive.   Titling this role something like "RFC
Publications Manager"
and giving the duties originally outlined I think is workable and will
can attract someone with the characteristics we actually need.  More
importantly, I think it will result in a work style that is a better fit for the
bulk of the documents which move through the series.

I think we've wrapped ourselves the problem in a funny way because
of how we titled the role.  We all *know* the importance that the
RFC Editor has had in the Internet technical community history.  We've
distributed the work now, but it is very hard to say out loud that the
RFC Series Editor could be a part-time position for someone with
reasonable experience.

So I think we should not.  We should keep the original tasks and re-title
the role to fit them.  If we then discover that we truly do need an
Executive or someone with a big industry name, we can revive the
title and move forward.  I do not think adjusting the tasks to centralize
authority here will be that successful, especially if our core reason
for it is simply reverence.  We can honor our history instead by leaving that
title to the people who really did it all:  Jon, Joyce, and Bob.

Thanks again for your analysis,

regards,

Ted

On Wed, Jan 5, 2011 at 7:42 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> 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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


More information about the rfc-interest mailing list