[rfc-i] "Executive-level management": What is the purpose of the RSE?
glenn at riveronce.com
Thu Jan 6 19:58:37 PST 2011
thanks for your very deliberate and careful analysis. It's exactly the sort of consideration this issue requires.
A large fraction of your observations below are rooted in your asking: are we allowing use of the term "executive-level management" (introduced in RFC 5620) to drive our thinking about the RFC Series Editor?
As you point out, and as I describe in the Motivations document, RFC 5620 uses the term but does not directly define it. In the first TRSE recommendations (draft-kowack-rfc-editor-model-v2-00) published just before Beijing, I provided an explicit definition. As you know my charge was to do the RSE job, determine what needed to be done by the RSE and how, and document my findings. I was careful to define the term based on my experience as RSE, and not to let term itself drive anything not rooted in my direct experience as, or analysis of, the RSE.
By the time I wrote the Overview and Motivations documents, I largely abandoned the term (Motivations only points to its use in RFC 5620) choosing instead to stick to the specifics of work content. Still, I can see how some might continue following 5620, so it's good that you brought this up. Detailed responses follow to your points below:
On Jan 5, 2011, at 10:42 AM, Andrew Sullivan 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".
See my intro, above. In general, I recommend that aggregate terms are used sparingly. We should focus on understanding the actual work first.
> 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.
Based on what I saw during my term, enlarging the scope of the RSE across the entire editor is necessary to allow the community to know who is responsible, and for someone to make a coherent whole of the Editor and the Series.
> 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",
You're right about this weakness in 5620 which I aimed to remedy in later documents.
> 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 .
> 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.
Both of these attributes are represented in the Overview and Motivations.
> 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.
My characterization in 'Motivations' is somewhat different from the above. I focused on a lack of overall responsibility for the series, not on "executive-level management". (See Section 4.1. "General and Design Strategy Differences" (between RFC 5620 and the Recommendations).) This was based on my day-to-day observation that a single person must be responsible for ensuring the operation and development of the Editor and Series make sense overall, and the right person for this is the RSE.
> 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
> the responsibility and authority lie in the same place.
The thought process I tried to convey, particularly in the Motivations, was to determine what a successful Editor and Series requires for leadership, and what that requires w/r/t authority and responsibility.
> 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.
During the above period, each of the the folks above hired and fired editors, made or participated in policy decisions, did editing and production, and represented the Editor to the community and elsewhere. Certainly there's some cause to call it 'leadership'. Note that I didn't say anything like "to the exclusion of any others."
Past experience is always an input. I have heard from many members of the community that focused, individual leadership during the preceding 40 years was vital to the success of the series. This is what I was pointing at, not at "we've always done it that way, so...", which I agree is just wrong.
Separately, the 'seniority' required of the RSE is largely in being able to juggle the different requirements of the Editor and the Series, and in knowing how to match those to the desires of the community. From the last year's experience, I can vouch for how much this requires senior experience and skill.
> 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
> 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
> [. . .]
> [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.
The community has different activities, roles, and practices. The RFC Editor is fundamentally production-oriented, with a steady, daily processing activity that is in service to another segment of the community (the streams). It operates - at the level of the things produced - with highly defined requirements. Further, the demands for steady, quality, accurate, timely production are intense and unrelenting. All of these characteristics are more tightly and specifically applied than elsewhere in the community. There is certainly still some ad hoc-ery, but it can never be their only approach. Let's recall that producing 30 documents a month is not the same as producing one technical specification a year or participating in 3 meetings a year.
> So, the IETF is not really a "professional" organization.
I'd like to continue to stick to the specifics and avoid the problems of this sort of broad naming. In any event, the Editor has no choice as to whether they are highly rigorous in their work or not. You (Andrew) point to something very important: the RSE acts as an intermediate between two very different sides of the community and must contributed to the two working harmoniously: the professional, production-oriented RFC Editor, and the rest of the I* (whose characterizing label remains to be determined :-)).
> 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.
"A tidy org chart" has never been a consideration, but clear, uncluttered lines of reporting are important. Many in the community have repeatedly argued for clarity and simplicity, and I have sought to satisfy both in the recommendations.
> 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?
My approach has instead been to find, based on experience and analysis, the right way to manage the Editor and the Series. Where the Editor and Series have been amenable to conventional techniques, I have recommended those. Where it has not, I've made novel recommendations, and in a way so that both will play together well. That said, moving to an entirely new structure invites entirely new, unexpected and undesirable dynamics, so they should not be used arbitrarily.
> 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
> 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.
Insofar as others believe this is an important distinction, we should attend to it. I think the solution is not a matter of which one, but where to employ various techniques. If you revisit the Overview, I hope you will see that there is managerial clarity (aligning responsibility and authority - necessary isn a production-oriented environment and to attract a qualified RSE) and rigor, combined with a flexible interface that is attentive to community will reinforced by the REOC. The community and I* have differing requirements and a varied response is in order.
Thanks very much for bringing all these points to the list. I look forward to your additional thoughts.
> Best regards,
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest