From: Eric Armstrong <eric.armstrong@eng.sun.com>
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
people
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
placed
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
only
came up with one answer, although there may be better possibilities. The
answer
I saw was that "improving our ability to improve" would be tantamount to
investing in an infrastructure that made it possible to change physical
adjacency
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
improve".
Any such endeavor must, to my mind, involve a reorganization or a
restructuring
or a change in the way we do things.
Suppose Citigroup develops a DKR, for example, as they aim to do. Making
it
"work" requires workers contributing to that repository from around the
globe,
allow "best practices" to surface through comparison, and changing the
culture
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
the
organization does things. If for no other reason than the cost of change
itself,
organizations are understandably reluctant to make "hard wire" C-level
activities
as part of their organization. The goal of a flexible, self-reinventing
organization
may be laudable in theory, but one suspects that the economic cost of
continual
change would be outweighed by costs that are continually occurred, but
never
fully paid back by the improvements they make possible.
That analysis could turn out to be wrong if the business climate were to
accelerate
to such a degree that *only* a continually self-reinventing corporation
can
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
are
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
about
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
B-level.
*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
like
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.
The
lack of expertise reduces the chance of intrinsic success (it may not
work
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
company
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
support,
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
companies
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
defray
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
foolhardy
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.
However:
a) The cost of changing development environments is an additional
learning
curve for each of us. (If we change too frequently, we derive no
benefit
at all.)
b) The cost of developing some sort of "meta framework" that will even
*allow*
us the change development environments and libraries will suck up
resources
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
natural
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*
make
sense for us. Can anyone think of one? If so, are sure it's not really a
B-activity?
------------------------------------------------------------------------
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!
http://click.egroups.com/1/937/2/_/444287/_/952380784/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 14:20:22 PST