Re: [Iasa20] 6635bis

["Joel M. Halpern" <[e-mail]>]

I presume I am misreading part of the text below.
It seems to say that your understanding is that the ED could decide that 
the RSE needs to be an employee, and place that restriction on selecting 
candidates, without consulting the community.
Or that the ED could decide that the LLC should be staffing the RPC 
function directly without consultation with the community.

That seems so wrong that I presume it is not what you intended, and that 
I am misreading your text.

Yours,
Joel

On 4/29/19 2:24 PM, Alissa Cooper wrote:
> Hi Joel,
> 
>> On Apr 29, 2019, at 1:56 PM, Joel M. Halpern <[e-mail]> wrote:
>>
>> The most obvious difference is that if the RSE is an employee, the LLC has to supervisor that person.  If the RSE is a contractor, primary supervision falls to the IAB and the RSOC.
>> The HR implications of more employees are also different than the HR implications with of an organization with one or two employees.
>>
>> The very implication that this is a question that the LLC board cares about indicates that it likely increases the work load on the LLC board.
> 
> I disagree. Sections 5(c) and 5(d) and the LLC Agreement and Section 5.2 of rfc4071bis are clear about this. The Board hires and manages the ED and provides strategic direction. Whether the community wants to constrain the ED from having the flexibility to fill any particular role with employees or contractors does not bear on the workload of the board.
> 
>>
>> Structurally, we were told this was a small organization with very specific responsibilities, and a board concerned with those specific responsibilities.  If the IETF LLC hires people for meeting planning, RFC production, RSE, tools production, etc. then it is, but simply, a VERY different organization from what was described to the IETF during the BoFs.
> 
> I don’t see anyone asking the question about whether to hire people as employees for the above functions. Indeed, this is the sort of decision the IAD historically made without community consultation, albeit the set of choices realistically available were different under ISOC. As far as I know we do not have RFCs written down that constrain whether any of the other roles are employees or contractors (including the ED role itself, which could be either). I think Sean's question is about whether to allow that flexibility in the future for the RSE role, and others have raised the same question about allowing the flexibility for the RPC functions in the future.
> 
> Somewhat related to this is Section 5.5 of draft-haberman-iasa20dt-recs.
> 
> Alissa
> 
>>
>> Yours,
>> Joel
>>
>> On 4/29/19 12:10 PM, Richard Barnes wrote:
>>> John: I'm confused by this "lean and mean" point.  How is an organization with a collection of contractors (RSE, RPC, etc.) leaner and meaner than an organization with an equivalent number of employees?
>>> --Richard
>>> On Mon, Apr 29, 2019 at 12:04 PM John C Klensin <[e-mail] <mailto:[e-mail]>> wrote:
>>>     --On Saturday, April 27, 2019 23:44 -0400 John Levine
>>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>>      > As it stands the LLC can always fudge it by turning an
>>>      > employee into a nominal contractor by running him or her
>>>      > through a body shop but that seems silly.  The arguments
>>>      > against having employees all seem to be of the form that
>>>      > organzation X or situation Y had or has employees who are
>>>      > poorly managed, but that seems to me to mistake the symptom for
>>>      > the problem.
>>>     John, just to stress something I think is important --and
>>>     important whether this is the WG's decision or the WG is
>>>     supplying input to the IAB, within the WG's responsibility, or
>>>     something else [1] -- I don't believe your statement about the
>>>     arguments is correct.  As he pointed out, Stephen has raised the
>>>     argument before and I don't believe his position is covered by
>>>     your description.  In different ways, Brian, Bob, Joel, myself,
>>>     and others have addressed variants on the issue.  Each of us
>>>     have had slightly different perspectives or expressed our
>>>     concerns in different ways, but I don't believe any of those
>>>     comments have been dependent on "employees who were poorly
>>>     managed" even if some have included examples of that type.
>>>     Even if that were the only issue, the IETF LLC is sooner or
>>>     later almost certainly going to face tradeoffs in selecting
>>>     permanent Executive Directors.  Those tradeoffs may be with
>>>     costs or benefits (assuming the budget is not unlimited) or
>>>     skill set, types of experience, management skills versus
>>>     financial skills versus understanding of the work the IETF
>>>     actually does, etc.  While I assume the LLC Board will do its
>>>     best, finding the perfect person may not always be possible and,
>>>     partially as a result, I don't think any of us can guarantee in
>>>     advance that the person chosen will always be a superb manager
>>>     of people as well as a superb manager of contracts [2].
>>>     However, I believe that one of the community's assumptions about
>>>     the IAOC and IASA 1.0 had little or nothing to do with the
>>>     corporate entity concern.   That assumption was the desire to
>>>     keep the organization and structure as "lean and mean" as
>>>     possible, with few employees (or contracted semi-permanent staff
>>>     [2]) as possible.   I see that assumption as having been carried
>>>     forward into IASA 2.0.   If the assumption has been changed,
>>>     that is almost certainly a matter for this WG to discuss.  If
>>>     the assumption is at all controversial, then I think the WG has
>>>     an obligation --one that falls well within its charter -- to
>>>     spell it out in some appropriate document.  More broadly, if the
>>>     LLC decided it wants to start bringing a significant number of
>>>     functions in-house and hiring significant staff (same
>>>     qualification, see [2]) to carry them out, I think it would be
>>>     entirely appropriate and quite desirable for its Board to have
>>>     to come back to the IETF, discuss the reasoning, and ask
>>>     permission [3].
>>>     I think that what I mean by "lean and mean" is similar to what I
>>>     believe Brian intended by "lightweight and cheap".   It isn't
>>>     about whether an individual whom the LLC needs to retain is
>>>     retained as an employee or as a contractor.   It is very much
>>>     about whether the number of people who end up being treated as
>>>     staff  (or people reporting to people treated as staff) by the
>>>     Executive Director become large enough to form a club, large
>>>     enough to require the Exec Dir or LLC Board to start thinking
>>>     about HR or employee relations programs or staff, or other
>>>     evolutionary changes that increase the probability of personnel
>>>     employed by (or contracted by) the IETF LLC beginning to set or
>>>     manipulate policy on their own.  That risk exists even when the
>>>     number of employees (or direct contractors) is only one (I know
>>>     of at least one example where I suggest that IASA 1.0 --and the
>>>     IETF-- suffered from that problem) but a great deal of
>>>     experience elsewhere with organizational behavior (with or
>>>     without bad management) suggests the risk rises much more
>>>     quickly that linearly with organization size.   If you believe
>>>     that the IETF LLC will, because of some inherent virtue, be
>>>     exempt from those pattern or organizational development and
>>>     evolution but it seems to me that, like a plan to improve
>>>     networking by having traffic exceed the speed of light by a bit,
>>>     those suggesting that we will be ok because it hasn't happened
>>>     here (yet, or very often) have the obligation to demonstrate why
>>>     those fundamentals will not express themselves in this case.
>>>     best,
>>>          john
>>>     [1] I'm also a little troubled by the "this is an IAB document"
>>>     discussion, but not for the reasons Alissa and others have
>>>     cited.  At least for the purposes of this discussion I'm fine
>>>     with the IAB getting community input and then making decisions
>>>     about hiring and most strategy for the RFC Editor.  However, if
>>>     a decision the IAB might make, or is considering making, would
>>>     change or expand the functions or authority of the IETF LLC or
>>>     its leadership, it seems to me that would lie squarely within
>>>     the the scope and responsibility of this WG and IETF consensus
>>>     more broadly.  If such a change were made using the IAB's
>>>     authority, especially if it were supported by the assertion that
>>>     the IAB is not a consensus body or responsible to IETF
>>>     consensus, it seems to me that would violate assumptions and
>>>     provisions that go directly back to POISED and the Kobe affair.
>>>     [2] As we have discussed separately, I think we are in agreement
>>>     that the difference between an employee and a contractor on an
>>>     individual contract who is treated as one is almost
>>>     non-existent, but I don't see that as the key issue here despite
>>>     several postings about it.
>>>     [3] I think trying to define how many hires (or consultants on
>>>     individual contracts treated as employees) are permitted would
>>>     quickly deteriorate into the kind of overspecification you and
>>>     others have decried (I agree that is not desirable).   But that
>>>     is different from establishing clear guidance that, if the LLC
>>>     decides to start hiring multiple people, its Board is obligated
>>>     to come back to the community for discussion and before doing so.
>>>     _______________________________________________
>>>     iasa20 mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/iasa20
>>> _______________________________________________
>>> iasa20 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/iasa20
>>
>> _______________________________________________
>> iasa20 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/iasa20
>