From: Eric Armstrong <firstname.lastname@example.org>
Eugene Kim wrote:
> Not to get hung up on my cafeteria example, but I'm not sure what
> the "office-on-skids" example a C activity, but not centralizing your
> cafeterias. Perhaps other examples could help clarify our
> of B and C activities.
My view of things so far, is that the B-level activity says "if we get
they'll work more efficiently". The idea is then to put people near each
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
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
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
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
someone else is rewarded so well that people are not tempted to hold on
own solutions with a death grip, in order to achieve advancement. Those
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
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
involve fundamental change, or the tolerance for change is greater than
it is, I simply do not see C-level activities becoming a "central" part
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
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
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
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
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
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
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 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
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
of problems that will require the devoted attention of many people
And even if we solve the technical problems, it is not all clear
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: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 14:20:22 PST