Re: [unrev-II] How DKR Penetration Will Be Achieved

From: Eric Armstrong (
Date: Mon Mar 06 2000 - 14:12:57 PST

  • Next message: Ron Goldman: "Re: [unrev-II] example C level activity"

    From: Eric Armstrong <>

    Eugene Kim wrote:

    > Not to get hung up on my cafeteria example, but I'm not sure what
    > makes
    > the "office-on-skids" example a C activity, but not centralizing your
    > cafeterias. Perhaps other examples could help clarify our
    > understanding
    > of B and C activities.

    My view of things so far, is that the B-level activity says "if we get
    people together,
    they'll work more efficiently". The idea is then to put people near each
    other. Of
    course everyone can't be near everyone else, so we have to choose which
    are near each other, sharing common areas and lunch rooms and so forth.

    A company might put marketing next to development, or marketing may be
    close to sales, or executives next to the shop floor -- whichever
    arrangement the
    company things will bring the best results is the arrangement they
    choose. It's an
    improvement that's undertaken for the beneficial effect on productivity.

    The question I asked myself was: "If making common areas and lunchrooms
    is a
    B-level activity, then would be a C-level activity in the same arena?" I
    came up with one answer, although there may be better possibilities. The
    I saw was that "improving our ability to improve" would be tantamount to

    investing in an infrastructure that made it possible to change physical
    easily, in order to put marketing in contact with developers for a
    while, and then
    later "redress the balance" by putting them close to sales for a while.

    My intuition (a tricky thing) tells me that the semi-ludicrous notion of
    "offices on
    skids" captures the essence of what it means to "improve our ability to
    Any such endeavor must, to my mind, involve a reorganization or a
    or a change in the way we do things.

    Suppose Citigroup develops a DKR, for example, as they aim to do. Making
    "work" requires workers contributing to that repository from around the
    allow "best practices" to surface through comparison, and changing the
    so that contributing to the repository and choosing a better solution
    offered by
    someone else is rewarded so well that people are not tempted to hold on
    to their
    own solutions with a death grip, in order to achieve advancement. Those
    are not
    easy things to achieve!

    But the important point in all that is the notion "improving your
    ability to improve"
    requires *change* -- fundamental, basic, gut-wrenching change to the way
    organization does things. If for no other reason than the cost of change
    organizations are understandably reluctant to make "hard wire" C-level
    as part of their organization. The goal of a flexible, self-reinventing
    may be laudable in theory, but one suspects that the economic cost of
    change would be outweighed by costs that are continually occurred, but
    fully paid back by the improvements they make possible.

    That analysis could turn out to be wrong if the business climate were to
    to such a degree that *only* a continually self-reinventing corporation
    survive. But I suspect that there is an upper limit to the amount of
    change that
    humans can tolerate and still be productive, and it seems to me that we
    approaching that limit.

    So, unless there is a notion of "improving the ability to improve" that
    does not
    involve fundamental change, or the tolerance for change is greater than
    I think
    it is, I simply do not see C-level activities becoming a "central" part
    of any
    organization, anytime soon.

    For the technical subsection of the colloquium, our A-activity is
    producing a DKR.
    The B-activity is improving our ability to kick one out. If we worry
    C-activities, we'll be reinventing ourselves too often to get anything
    done, so like
    every other organization, I suspect that our efforts stop at the

    *However*, the DKR we produce represents a C-level improvement for other

    organizations. Although they are unlikely to invest in creating such a
    thing, they
    are likely to use it. Our A-activity, then, is their C-activity. That
    has been the
    history of business interactions for the last several centuries, and I
    don't see that
    model changing anytime soon, for the reasons mention.

    But another reason an organization is unlikely to invest in a C-activity
    creating a DKR is that it is outside their area of expertise. The cost
    for them
    is much higher than for an organization which is devoted to that goal.
    lack of expertise reduces the chance of intrinsic success (it may not
    at all) as well as extrinsic success (other products may be better).

    We have seen in the software world that it almost uniformly better for a
    to use "off the shelf" software, instead of developing it in house
    (whenever software
    exists that will do the job). The costs of documentation, technical
    maintenance are simply too high. The reason is the size of the market.
    An "in house"
    project has one company paying for it. A commercial product has many
    paying for it. The extra income allows the commercial product to expand
    and add
    features that in house products rarely have time for, if ever. The
    result is that, even
    if they start out with similar levels of functionality, in 5 years a
    commercial product
    is typically far ahead in features and functionality.

    When you add up the cost of change, the smaller user base over which to
    expenses, the lowered chance of success, the higher risk of failure, and
    the lowered
    risk of acceptance, investing in C-level activities appears to be a very
    adventure for any organization that hopes to succeed.

    To relate it to our current endeavor: If our A-activity is producing a
    DKR, and our
    B-activity is finding better tools (better programming libraries, and
    development environments, for instance), then our C-activity is
    developing a framework that lets
    us plug in the development environment of the week -- whatever is latest
    and greatest
    and will let us achieve maximal productivity.

      a) The cost of changing development environments is an additional
           curve for each of us. (If we change too frequently, we derive no
           at all.)
      b) The cost of developing some sort of "meta framework" that will even
           us the change development environments and libraries will suck up
           that we could have devoted to DKR production.
      c) We are unlikely to succeed in that endeavor. It opens up a
    squirrel's nest
          of problems that will require the devoted attention of many people
    to solve.
          And even if we solve the technical problems, it is not all clear
    that anyone
          would really want the solution.

    Admittedly, I'm arguing from the standpoint that C-level activities as
    *part* of an
    organization don't make much sense. So the example I conceive has a
    tendency to prove that point. As a human being, I'm wired that way.

    A useful counter example, then, would be a C-level activity that *does*
    sense for us. Can anyone think of one? If so, are sure it's not really a

    GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0%
    Intro or 9.9% Fixed APR and no hidden fees. Apply NOW!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 14:20:22 PST