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

[Dave CROCKER]

On 1/10/2011 5:25 AM, Andrew Sullivan wrote:
> In city government, there are (broadly) two models: the "strong mayor"
> model; and the "weak mayor" or "city manager" model.  Similarly, in
> this case, I think there are really two possibilities: we can have one
> person who has several responsibilities and quite a lot of control; or
> else we can have those responsibilities divided up among many people,

In reality, both of the models you cite put primary responsibilities into a 
single person's hands.  With strong mayor, it's the elected mayor who might or 
might not have the relevant skills.

The council/manager model has the city council select the city's lead, 
professional manager who holds those responsibilities.  Council/manager models 
tend (or always) still have a mayor, but it has few responsibilities and is 
largely a ceremonial or "bully pulpit" role.

The real-world council/manager model actually parallels quite well with what 
Glenn has proposed.  The council/manager model emerged for city operations from 
a desire to move the management of city services onto a more professional, and 
less politicized, footing.

A very good description is:

    <http://www.rockvillemd.gov/FAQ/formofgov.htm>

    "The Mayor and Council is the legislative body"

    "The manager prepares a budget for the Mayor and Council's consideration; 
recruits, hires, and supervises the government's staff; serves as the Mayor and 
Council's chief adviser; and carries out the Mayor and Council's policies"

Small caveat:  We need to be careful to review all of the FAQ entries and not 
cherry-pick ones that support a particular view, out of context...

The Wikipedia entry looks pretty reasonable, too:

    <http://en.wikipedia.org/wiki/Council%E2%80%93manager_government>

Note the reference to the city manager's being equivalent to a CEO...


> with someone doing the work of a kind of senior special advisor to the
> community, and all the control vested in the community.

In the real world, neither management model reflects this arrangement. 
Reference to a city manager's being advisor is true only within the context of a 
longer list of duties that happen to include more responsibility and authority.


> This is why I argue we have a stark choice.  These models are very
> different.  They involve different costs and benefits.

Folks should try to provide and consider the accompanying details carefully, 
rather than merely rely on an assertion of conceptual preference.

Ted did some of this for one preference, suggesting that the RSE edit documents, 
and that nicely uncovers a conflict with the Production Center's 
responsibilities, for example.


>        For instance,
> your recommendations have a significant cost, as near as I can tell,
> because they seem to suggest some changes to BCP 101 are needed: if
> the RSE has some important level of control over people doing RFC
> production, then that must have some effect on contracts.

By my reading of the relevant documents, probably not.

Delegation of authority to the RSE does not necessarily require changes to the 
BCP or contracts.  Again, folks thinking otherwise should cite specifics.


> I like Olaf's suggestion elsewhere in this thread that there are
> distinct pieces that can be teased apart and then reasoned about
> separately.
...
> I get that.  What I am arguing is that there is in fact another way to
> do this, which is to break the "leadership" and "authority and
> responsibility" components apart.

The benefit of teasing things out can be clarity.  The danger is in thinking 
that the ability to list and discuss things separately means that there is no 
requirement to embody their performance in a single person who integrates 
things.  Piecemeal, uncoordinated, incomplete coverage is the potential downside 
if separation.

When folks propose an alternative model, they need to provide a very clear basis 
for believing it will work.  Examples of similar operational environments would 
be particularly helpful.


> Moreover, the present isn't like the past anyway.  The broader IETF
> itself has changed dramatically over the period in question, and one
> can fairly ask whether, when the facts change, one ought to change
> one's opinion.

Correct.  It's a justification for starting to ask some questions.  However we 
need to be careful that it is not, instead, used as a justification for making 
particular changes to the model.  Justification needs to be based on pragmatic 
differences and needs.

Consequently, the fact that this sort of 'fact' is still in play at this very, 
very late stage ought to strike us all as problematic.

In addition, the exploration needs to look at existing and historical problems, 
not just broad conceptual preferences that are postulated to be easier, cheaper, 
simpler or the like, but lack detail or experience.

The RFC Editor is a critical production service that produces 30 documents a 
month.  This is a dramatically different operation than a multi-year IETF 
working group or thrice-annual IETF meeting planning.

There are well-established and well-understood organizational structures for 
critical infrastructure services.  If we adopt something that differs from those 
structures, we are venturing into terra incognito.  Sometimes experimentation is 
great, but it's difficult to understand how this is one of those.


> "Motivations" says that production and day to day operation seem to
> chug along mostly just fine on their own.  Therefore, I am not sure
> why the production-oriented nature is evidence in favour of an active
> and strong leader with a lot of independent authority.

This logic seems to be in line with the "fire everyone who works for the 
government and is not at their job between Christmas and New Years" model.

When everyone is lucky, critical infrastructure services hum along nicely.

That is almost never a steady-state reality.  Stuff happens and it tends to 
happen frequently.  Resolving that stuff entails a very different skillset from 
what is needed to do the daily grind.


  It seems to me
> that the stability of regular production could be construed as
> evidence that the direction and policy for the RSE could indeed come
> from a board or committee or something.

Only if one ignores what has not been getting done or has not been getting done 
well.





On 1/7/2011 2:29 PM, Bob Hinden wrote:
 > On Jan 7, 2011, at 7:29 AM, Paul Hoffman wrote:
 > I like the idea of RSOC being responsible for policy and the RSE (name TBD,
 > the paid employee/contractor) implementing the policies.  Much like the rest
 > of the IETF.

The danger is in confusing the effort to define and promote policy with the 
authority to approve policy.  Committees aren't so good at the former, but quite 
reasonable for the latter.


 > I think there would also be value if someone from the IAOC served on the
 > RSOC.  My thinking is that this approach worked well for the IAOC.   The IETF
 > chair, IAB chair, and ISOC president are voting members on the IAOC.  It
 > helps to add the right perspective to the discussions.  Given the desired
 > coordination with the IAOC, having someone from the IAOC makes sense to me.

The more inclusive a group is, the less focus it is likely to have.  It also 
invites potential conflicts of interest, to the extent that an 'oversight' group 
contains members who are supposed to be overseen.

There is also the very basic danger of confusing operations coordination with 
policy oversight.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net