[rfc-i] RSE models

Ted Hardie ted.ietf at gmail.com
Wed Dec 1 11:57:27 PST 2010


Hi Dave,

I've replied below; there are some snips to
focus the response.

On Wed, Dec 1, 2010 at 9:49 AM, Dave CROCKER <dhc at dcrocker.net> wrote:

Ted wrote:
> >  But to me, the meat of
>> the job is in "maintenance of quality and advancement of the Series",
>> which I
>> assume from other discussions means "quality" outside the content.
>
> The presumption in your use of "but" is that management, process and
> outreach have nothing to do with maintenance or advancement, or at least not much.
>

I'm not sure I'd go so far as "not much" to do with maintenance or
advancement, but
I do think that "not the key elements" for maintenance or advancement
is probably
a basic part of where I think the job description should go.  I think
we have an opportuity
to hire someone with critical expertise in a suite of related areas
(archival continuity,
metadata and searchability, formatting and usability, and
translation); getting that
expertise in house is more important to me than whether the RSE acts
as the contract
manager for the IAOC-signed contracts with the production or publication side.
I think that a senior expert with that skillset is also likely to have
some management
capability and I don't have a serious issue with management
responsibilities or even
arbitration roles. But I don't think this should consume the bulk of
the time of someone in this role.

On the second point, I was struck by your inclusion of this text in
the RSE job description
you posted:

"In the case of cross-stream disagreements, the RSE arbitrates the first-level
of resolution effort.  The RSE's decisions may be appealed to the IAB."

I agree with the text, but is it really likely to occur often enough
that we should focus
on it in a job description?  From a time perspective, I hope it occurs
so rarely that
many years of contracts could go by without it ever coming up.  Including it may
clarify the relationships with other streams, but it also focuses on what should
be a really rare event.

To put this another way, I think the effort to stress the community
leadership aspects
of this role have actually focused the discussion on job elements that
are relatively
small parts of the job.  The RSE may speak at conferences, discussing
why the overall
conversation of the RFC series being held together is important and how to read
different parts.  But that sort of out reach is a two-ish times a year
event in my view,
not the day-to-day work.

> However how can
> "work for the communities of interest" be determined without talking to
> communities of interest?  Outreach means talking to the consumer side.
>
>

Some of it will no doubt involve talking to the consumer side; some other
aspects will be surfaced by the streams' editors or approvers
(one community of interest being the producers, rather than the consumers).

>>  I would also believe that working with
>> stream approvers and the publication center when there are difficult
>> documents or clusters would fall under this rubric, but I can see others
>> as
>> seeing that under the "processes" tab.
>
> I am not exactly sure how you distinguish "management" from "process".
>
> The RSE is not the person who performs the daily, essential grind of
> processing documents or handling online services.  That's what the
> Production and Publisher staff do, of course.
>
> The handling of difficult situations -- ie, escalations -- is a common
> management function, absent the more formal problem-resolution escalation
> department present in larger organizations.  Even then, management is part
> of the escalation sequence.
>
>

I think of it in slightly different ways.  When someone is coding and they
turn to someone with more experience or an architectural role in the project
for assistance, this isn't escalation in the usual management sense.  It's
closer to the tech support escalation.  I agree that difficult documents
or clusters will get escalated to the RSE, but I see it as because of her
or his expertise and architectural role, rather than for management reasons.

<snip>

> Classifying any sort of outreach as "overhead" is pretty unusual, as job
> descriptions go.  It is normally classed under such categories as marketing
> or customer service and neither of those is typically viewed as overhead.
>  The former is in the realm of getting or keeping customers and the latter
> is in the realm of keeping customers.  That ain't overhead.
>

Okay, but is it a key role for this job?  Shouldn't the IETF leadership be
marketing/doing customer service for the standards track?  Is
the key marketing here for the series as a coherent conversation spanning
tracks, or as individual tracks?  If the former, how much of the time
for the RSE gets put into this?


><snip>
> Perhaps it's not what you meant, but it sounds as if your premise is that
> people who are under contract cannot be managed or that changes to their
> work cannot be made.  Of course, neither premise is correct, and I'll bet
> that even if you meant something like this you did not mean it in as extreme
> a form as I've stated.
>
> Any sort of supervision comes with constraints.  Supervision of contractors
> has some of its own kinds of constraints and anyone doing the supervision
> needs to be cognizant of them.  But constraints do not mean that supervision
> is not possible.
>

So, please forgive a short digression.  Long ago, I worked as a contractor
at NASA Ames, on the Sterling (later Raytheon) contract for the NASA Science
Internet project.  There was a very broad support contract that governed the
overall work and a civil servant assigned as a manager of that contract from
the government side.  As the task requester on the contract, that civil servant
gave new jobs under the general contract to the Sterling/Raytheon contract
manager, who then assigned them to teams or individuals.  The overarching
theory was that the contractor had control over how the task was accomplished,
within the bounds of support contract and the terms of the task requested.
So, which employees were assigned, what they were paid, and what tools they
used was determined by the contractor; what they produced was determined
by the task requester.

Obviously, this is not the only way to run a contract and not even necessarily
a good model here, but it colors my personal thinking a bit.  If you'll indulge
the question, if you used this mental model, given the supervisory role for the
RSE, would the RSE be a task requester or contract manager?

regards,

Ted


More information about the rfc-interest mailing list