[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one

Samantha Eisner Samantha.Eisner at icann.org
Tue Jul 28 19:20:59 UTC 2015

Carlos, as a point of reference, ICANN has an investment policy in place
that is regularly reviewed by the ICANN Board, which includes principles
on how funds held by ICANN are managed, as well as the size of the reserve

On 7/28/15, 10:13 AM, "accountability-cross-community-bounces at icann.org on
behalf of Carlos Raúl Gutiérrez"
<accountability-cross-community-bounces at icann.org on behalf of
crg at isoc-cr.org> wrote:

>Carlos Raúl Gutiérrez
>+506 8837 7176
>Skype: carlos.raulg
>On 28 Jul 2015, at 11:02, Greg Shatan wrote:
>> One other note -- there seems to be a misunderstanding of what a
>> "non-profit corporation" (and why it is called "non-profit").
>No problem with reserves, contingencies, etc. ICANN has to big ones of
>80 million each. But still a problem with unrealistic income
>projections, and optimistic spending just because we have more money
>coming in tomorrow.
>> A
>> "for-profit" corporation pays out net profits to its owners
>> (shareholders
>> or other types of owners).  A non-profit does not have owners or
>> shareholders, so it does not pay out profits to anybody.  While an
>> entity
>> can be " non-profit," this does not mean it is "non-surplus."
>> "Non-profit"
>> does not mean that it is not supposed to run an excess of revenues
>> over
>> expenses, or have no more assets than it has liabilities.  So, this
>> idea of
>> "balance" is misplaced.
>A healthy finial balance is always in place under the assumptions as per
>> A non-profit, like a for-profit, needs to balance
>> its books in an accounting sense, but that does not in any way mean
>> that
>> there is a prohibition or even a presumption against having a surplus
>> of
>> cash over expenses.
>agree. Two sets of reserves of $80million/each is quite alright
>> Greg
>Carlos Raul
>> On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez
>> <crg at isoc-cr.org>
>> wrote:
>>> Dear George,
>>> I agree with you that a cumulated budget veto is a pretty useless
>>> accountability tool (independently of how difficult it would be for
>>> the
>>> sole member to exercise itŠ)
>>> Moreover, I think the community on the one hand should take care that
>>> the
>>> public interest objectives (policy development and compliance
>>> functions)
>>> are properly funded. It would be much more effective if those
>>> separate hose
>>> budgets (policy development and compliance functions) would be
>>> developed in
>>> a bottom up fashion, based on the needs of the community, and through
>>> the
>>> communities direct involvement. No need for a veto then since the
>>> SOs/ACs
>>> would be DIRECTLY responsible for their budgets.
>>> On the other hand, it is up to management to guarantee the financial
>>> BALANCE  of the day to day operations (yes, balance because ICANN
>>> purpose
>>> is non for profit), as well as guarantee the demands of the community
>>> for
>>> proper funding of the public interest functions (independently of the
>>> line
>>> overseer of the functions, which is another black box altogether).
>>> This would be in my view a much more effective system of so called
>>> ³checks
>>> and balances²  than an absolute veto over the cumulated budget,
>>> where the
>>> community has little knowledge on the different objectives under it
>>> was
>>> produced, and remains in my eyes will very obscure, independently of
>>> the
>>> overall sum in relation to the size of the business.
>>> Best
>>> Carlos Raúl Gutiérrez
>>> _____________________
>>> email: crg at isoc-cr.org
>>> Skype: carlos.raulg
>>> +506 8837 7173 (cel)
>>> +506 4000 2000 (home)
>>> +506 2290 3678 (fax)
>>> _____________________
>>> Apartado 1571-1000
>>> San Jose, COSTA RICA
>>> On Jul 27, 2015, at 9:30 AM, George Sadowsky
>>> <george.sadowsky at gmail.com>
>>> wrote:
>>> All,
>>> These are my personal opinions.
>>> I suspect that the reaction to this post will be, "we are way past
>>> this,
>>> we've discussed this, and now just help us work on the implementation
>>> details."  If so, I think that's a mistake, because what I'd like to
>>> do is
>>> question one of the fundamental assumptions behind what this group is
>>> doing.
>>> When this process started, there was general agreement that it was
>>> more
>>> important to do this right than to do it quickly  Unfortunately, this
>>> feeling appears to have reversed, with the current sense that it is
>>> more
>>> important to get it done quickly in the name of the transition than
>>> to
>>> spend the time needed to do it right.  This process is going beyond
>>> accountability to a fundamental redesign of ICANN, with IMO
>>> inadequate
>>> concern for assuring inclusivity of support as well as lack of
>>> concern for
>>> unanticipated consequences.
>>> So here's what I'd like to contribute ...
>>> I've been uncomfortable with the notion of budgetary control/veto
>>> since
>>> the idea was first presented.  I think that I now know why: in my
>>> opinion
>>> it solves the wrong problem, and it is the wrong solution to the
>>> right
>>> problem.  Let me explain.
>>> In general, budgetary control is exercised by groups who want to
>>> control
>>> an aggregate budget, whether for reasons of limiting growth or
>>> ensuring
>>> that aggregate expenses for a budget do not exceed some measure of
>>> income.
>>> I don't think that's the case here, although I suppose that under
>>> exceptional circumstances it might be.
>>> The alternative is that the control the group appears to want must be
>>> by
>>> program or even by line item, even though you're planning to use a
>>> very
>>> blunt instrument  --  control over approval of the aggregate budget
>>> --  as
>>> your tool to accomplish this.  If that's the case, then what you
>>> really
>>> want is programatic control, not budgetary control.  If the program
>>> is
>>> accepted, then subject to resource constraints, it's up to the staff
>>> to
>>> deliver, and any specific line item or similar objection, however
>>> expressed, interferes with the execution of the activity.
>>> If the disagreement is with the program, with the objectives to be
>>> accomplished, and how the objectives are to be accomplished, then
>>> that is
>>> where the control should be exercised.  Any budgetary control after
>>> that is
>>> micromanagement.  The response to that is if you don't trust the
>>> organization to implement a rather well defined activity, then change
>>> the
>>> management/staff, don't restrict their resources and let them
>>> continue
>>> anyway.
>>> I suggest pursuing this line of argument further.  In my opinion, our
>>> fundamental problem has two components: (1) a persistent inadequate
>>> level
>>> of trust between groups within the ICANN community, and (2) our
>>> inability/unwillingness to create and use structures to deal directly
>>> with
>>> this situation and improve it.   I see the mechanism as starting with
>>> a
>>> lack of trust   --  in Board, management, staff, as well as the ACs
>>> and the
>>> SOs and their constituent parts  -- that generates not only suspicion
>>> regarding motives, non-transparent actions, and actions that are not
>>> equally favorable to all groups involved, but also the sense that the
>>> process is not serving "me" (whoever I am) well and is therefore out
>>> of
>>> control.
>>> In other words, IMO we have a fundamental problem of trust, and we
>>> don't
>>> have an effective way to talk about it or to otherwise address it,
>>> much
>>> less solve it.
>>> The budget rejection process that is being defined by the group is
>>> IMO
>>> based more upon defining ultimate ("nuclear" if you like)
>>> confrontation
>>> mechanisms than upon finding cooperative mechanisms to identify and
>>> resolve
>>> potential conflicts at an earlier stage.  It does not address the
>>> trust
>>> issue, and to the extent that my hypothesis is correct, if not
>>> addressed
>>> the trust issue will continue to bedevil ICANN activities, in other
>>> probably equally destructive ways.   Should not this group be equally
>>> or
>>> more concerned about mechanisms to identify issues and encourage
>>> cooperative-based and trust building processes to solve problems as
>>> they
>>> arise?   It does not appear so to me.
>>> In summary, the current approach, gaining more control over budget
>>> approval, is based upon a model of checks and balances, and that may
>>> be
>>> legitimate to some extent.  However, I sense that is not the way in
>>> which
>>> it is planned to be employed.  If so, it solves the wrong problem,
>>> nad it
>>> does not address the real problem.   We need a different approach,
>>> one of
>>> getting to the root of disagreements, real and perceived, that is
>>> early and
>>> based upon increased cooperation and trust, and we need a way to
>>> communicate that encourages this to happen.  This is not an easy
>>> problem to
>>> solve, but IMO it's the real problem that we have to solve, rather
>>> than
>>> some well meaning but inaccurate proxy representation of it.
>>> Please consider these thoughts in your discussions.
>>> George
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>Accountability-Cross-Community mailing list
>Accountability-Cross-Community at icann.org

More information about the Accountability-Cross-Community mailing list