Introduction:
I see lots of similarities between the Internet today, and the prior 25 years of the
information age. This manifesto takes into account my experience as a computer store
manager, data processing manager, Internet service provider and webmaster.
My suggestions herein are most heavily drawn from my data processing manager era -- for 15
years -- at the same company. I
think it's important that I emphasize this at the outset as my perspective. Because as the
architectural decision maker, buyer and implementer -- my customers (i.e. users) and
I lived with the benefits and consequences of my decisions -- for many years.
I didn't use architectures that were chosen by someone else. And I didn't change jobs
every five years -- leaving others to deal with my legacy. I slept in the beds I made. So
with that as my intention, I made them a lot differently.
I think it's pertinent to point out that I was fired
from the corporate world in 1996, shortly after the introduction of Windows 95 rev zero.
So I have never supported that chaotic platform in a corporate environment. My IT
experience is based on an extremely stable Novell LAN, and my authoritarian control over
an even more stable HP-3000 mainframe. While this doesn't reflect current IT products, I
believe what I have to say is just as applicable to today's environment.
Overview:
What follows is my advice on how to benefit from the offerings of technology providers,
while keeping the steadfast control of a tight leash, and making each individual
technology provider expendable with a simple broom sweep.
Form vs. Substance; Take what you Want, Leave what you Don't:
Two people recently opined that it sounds like this manifesto was written by an angry
person. They're right, I am angry -- at not only unstable products, but the vendors who
cash in on them, and even more-so at the many technical vendors who's number one objective
so often is to lock you into their offerings.
Incidently, when I questioned those two people what the point of this manifesto was,
neither of them had any recollection that it's "An Exit Strategy from Technology
Providers". I think the reason they missed the main point, was because they were
focusing on form rather than substance -- not what was said, but how it was
said. My response was to thank them for their input -- but the teeth will remain in this
manifesto. Because that's just the kind a guy I am.
Onward:
I will now provide my personal perspective on the history of the past two generations of
computer hardware and software. Then I'll elaborate on how I think lessons learned during
that timeframe can prepare us for the future.
Brief History Lesson:
It's a fact of life that technology providers come and go. Hot today, gone tomorrow. A
lot of big fish, with big revenues and big attitudes, have left big skid marks as they
slid down the slippery slope. And they all had certain things in common -- lots of
momentum, lots of overhead, and the inability to maintain quality while keeping up with
the ever changing pace of technology. So when the landscape changed right in front of
everyone's eyes -- they couldn't alter their courses quickly enough to save themselves.
That's right, the whole world knew about it -- they knew it, the trade rags knew it &
their lowly customers knew it. But they bit the big one anyway. It's a fact.
I watched the mainframe computer companies disappear as they lost their market share to
the minicomputers. Then
most of the mini companies went belly up as toy microcomputers took over their
turf. In both of these situations the giants were outnumbered from below -- by smaller
fish -- who were more agile, responsive and aggressive. And less expensive -- with shorter
commitment cycles. Most importantly though, from the perspective of customers, these
little fish had better attitudes. These days it appears as though history is repeating
itself again -- with the advent of Internet based Application Service Providers (ASPs).
Remember Sperry, Burroughs,
Honeywell, DEC, Data
General, Wang and NCR? And the list goes on. And what about the hundreds of software
companies that had their horses hitched to the wagons of those hardware giants -- and
their proprietary operating environments? Gone -- for all practical purposes -- gone. And
the
bigger they were, the harder they
fell, and the more partners (or whatever they demand to be called) they took with
them.
Loyalty:
And on their way
down the toilet, do you think any of these technology providers gave a rip about their
loyal customers? NooOOoo -- they had their own skin to look out for. It was the same deal
with both hardware as well as software vendors. And with big fish as well as their little
small-fish, wet-nosed, whipping-boys. (Note: Small-fish,
wet-nosed, whipping-boys are spineless vendors who graciously hoop jump to the
satisfaction of big fish. And if you can't see the dollar signs, spewing out of their
mouth every time they open it, then I think you may be a bit naive (that's as diplomatic
as I get). And for this loyalty they receive a poor quality third generation fax with a
little gold sticker inside a frame (purchased at the Dollar
Store on the way to work that morning) after becoming deemed worthy of the title authorized,
partner, affiliate, associate & other similar sounding US$20 terms which bestows
forced reverence, honor, attribution, love, admiration, loyalty & in general just an
overall sense of importance to the ego (and the bottom line) of the big fish. After that,
the little fish is not only entitled, but required to locate the big fish's authorized
logo on their business cards, stationary, advertisements, storefront & at the bottom
of their homepage -- prominently displayed in such a way that no more stature would be
afforded any other logo which may regretfully be present -- including your logo -- that's
right, they think they own your business, and they sort of do, because you did sign their
agreement (and if you don't believe me, re-read it, that's your signature at the bottom
pal). The logo requires adequate pixel spacing between it and any other logos -- as
defined by & in the sole opinion of the big fish -- the terms of which are subject to
change without notice & become immediately binding. Failure to comply with all terms
will result in a fine of no less that US$1000, half the distance to the goal, and a 3
month probationary period after which time, notarized proof of mandatory sensitivity
training & kow-towing must be presented -- along with a renewed acceptance to all of
the latest legal agreements including an ever longer list of companies you can't deal with
for a "long" time (beginning with all of their perceived competitors) in order
to comply with the big fish's exclusivity requirements -- all signed by a duly anointed
little wet-nose whipping-boy trainer in good standing, who's also been certified & authorized
by the big fish. (If it's any consolation, the trainers subject themselves to 10 times as
much crap -- which ought to help explain why they're such potato-heads). The
trainer must consistently meet quota, religiously spout the big fish's party line and your
exorbitant fees to them must be paid in full. All training, a new set of obsolete &
overpriced training materials (whether or not you need them or want them), examinations,
hoop jumps, fingerprints, urine tests, retinal scans, suck ups, the latest generation
new-world-order implant in the back of your neck & any other such demeaning acts must
be re-inflicted -- the fees for which are to be paid in advance by the little fish -- and
never mind certified checks or wire transfers -- because these days they demand that you
allow them direct debit access to your checking account. But don't worry, they won't take
any more than they need. This all sounded pretty good to start with, because they were
going to direct deposit money right into your account -- and save on all that nasty
paperwork. But then there is that simple clause which allows them to pull funds directly
from you too. So in the spirit of good faith (and since you rally had no choice anyway)
you signed it. The fees are very important. Don't forget the fees. Because any other
slipups after this point will result in permanent termination, tar & feathering and
forced sterilization by an off-shore veterinarian. And that's if they're in a good mood
that day. So like I said, don't forget the fees. (LL35
(Proper attribution to Les Schwab's book Pride
in Performance for inspiring this paragraph in red. You won't see any Firestone or
Michelin signs in front of his tire stores -- or any clutter on my homepage for that
matter. But I digress.))
I'm back. Anyway, I've seen dozens of technical companies take the ungraceful slide down
the the slippery slope -- and I've come to the conclusion that only chump customers are
loyal to technology providers. And even more-so for any providers that were loyal to
larger fish. I mean these guys come and go about as often as you get a haircut. And
they're saying, "Depend on us?"
And I say, "Fine, depend on them, but have an exit strategy."
All Locked In and Nowhere to
Go:
To add insult to injury, technology providers try to lock you in. And they say,
"Don't worry, we'll always be here to serve you. And hey, our profits have
increased for two whole consecutive quarters." And life is good -- right up to the
point that another gold rush comes along
-- at which point they'll begone -- off pushing the next generation gizmo -- which catches
mice twice as fast, for half as much. Then they scoff at that the dusty old architecture
that you're using (which they sold you). And they say it isn't fun anymore. But you're
stuck with it -- for a few more years. And your check's long since been cashed, so you
have no leverage. And it's hard. And when you dust off the contract, you may find that
it's no longer effective because of a bankruptcy. Or mergers and acquisitions which so
commonly occur as drowning companies start grabbing onto each other as they're going down
for the count. And guess what? That's the good news. Because there's one more little bitty
issue -- they've still got you hooked. It gets worse -- because they don't even want
anything to do with you any more. How bad is that -- hooked by somebody who doesn't want
anything to do with you. And at that point there isn't enough money in the world to get
their attention. But if you're persistent enough to find a phone number that gets through
to them, and if you call them up, they look at their caller ID, and they see it's you, and
you get voicemail, which they don't return, of course. After a while you'll get the idea
-- you're on your own. Deal with it.
And
here's the part that really gets me -- on their way down the slippery slope do they once
think to throw you the keys (such as login documentation, a clear path to self
sufficiency, and 100.0% source code) that would free you of their shackles? Nada. They
hang you out to dry, baby. Intentionally and without any sense of guilt. Off to hook new
chumps in a new arena. Such is the shameful unrepentant life of technology providers --
with less scruples than a pet rock.
But fortunately and ironically -- the majority of their little customers survive. Even
though most of them are dwarfed in size by these flash-in-the-pan technology giants --
who's products and full page ads are, by now, buried layers deep in forgotten landfills.
But their (ex) customers are a little older, and a little wiser, and life goes on. Yup.
History Repeats Itself:
The point is -- history repeats itself. And I predict that it's going to be the
same thing all over again with the current technology kingpins; Microsoft, Oracle, Amazon,
AOL, Yahoo and Google. Along
with a whole lot of Internet companies. Yeah sure, they look invincible today. But trust
me, they'll begone tomorrow. It's just a matter of time. But you, and I, and Boeing, and
the nationwide chain of 7-11 stores will still be here (for now), too busy to mourn the
passing of yet another generation of technology wannabes playing king of the mountain.
Primarily there are two kinds of technology companies who are going to bite the big one;
those with attitudes, and those without. And you can take that to the bank.
Now that my history rant is over, and now that you're all agitated, I'll discuss how to
get ready for the inevitable, how to minimize disruptions -- and how to proactively
prepare an exit strategy from your technology providers.
The Natural Order:
Generally
you will be pleased when you start using products and services from technology providers.
And you will like all of the things they are doing for you. But as sure as the sun
will rise tomorrow, you will eventually come to dislike what they are not doing for
you, or what they are doing to you. One day you will notice that your competitor
has capabilities that you can not offer because of your technology provider. Eventually
you will come to realize that the only way you will be able to obtain this new
functionality is to jump ship, or sail two ships. No hard feelings Pal, this is just the
natural order. Really! This is just the way it is!
Now to be fair, there are rare occurrences of technology providers who have survived
changes in the landscape (so far) by reinventing themselves. A few have even
prospered in the process. A couple of current (read my lips, current) examples are IBM and
HP. Nonetheless, the customers who adopted their legacy products still ended up
eating them. For example; IBM 360/370's, 34/36/38's and HP 42, 48 & 68's.
But from a customer's standpoint so what if IBM and HP are still alive? What's that do for
you? The point remains; every technology provider and every generation of technology that
you buy into will someday become obsolete. You bought it -- and you're going to eat it.
It's just a matter of time. That's the way it's always been with technology -- where rock
hopping is a fact of life. I'm not sure if that's the way it's always going to be or not.
But considering how long it's been that way, doesn't it just make sense to hedge your
bets?
The Solution:
Any problems though, can be greatly minimized if you plan an exit strategy
from the get-go. And constantly reassess it. The trick is choosing which wagons you hitch
your horse to, which wagons you don't hitch your horse to, how you hitch it,
when you hitch it, and when you unhitch it. As long as you have to eat obsolete products,
why not do it on your terms and on your time table? And why not do it with minimal impact
to yourself and your company?
Every technology provider has one or more strong suits. That’s why you’re looking at
them, right? But
none of them can perform every function that your business needs. And the more
modules that you select from a single provider, the more likely it is that one or more of
these modules will be weak. In fact, some modules may be so weak that your ability to
compete may be hindered by using them.
In addition, technology providers are constantly improving, evolving and
expanding their product line to fill in the holes. So what they don’t offer today, they may
have tomorrow -- but then again don't count on it. After we consider their less than
stellar batting averages on product delivery promises -- we get to guess whether or not we
think such products will be worth waiting for. And sometimes we have to go for the sure
thing -- and buy into a module today -- from another technology provider. After
that, as they say at the Olympics, "Let the games begin". Because no matter what
you do (or don't do), sooner or later you will be forced to interface modules from
multiple providers in order to fill in the holes. Plan on it. Plan for it.
Modules:
So now the question is; what is a module and how is it defined? And my definition
would be; it’s different in every technology era -- although the concepts are the same. A
module is hardware, software, services, and a million other technological wrinkles that
you use in your business. I would also define a module as your onramp ISP, your web
hoster, webmaster, ECommerce provider, EMail provider, application service providers
(ASP), DNS provider, domain name registrar, and so on. A module is anybody that you
write a check to -- and indirectly anybody that they write a check to. I would even go so
far as to define modules as your employees, yourself, and myself. In summary, a module is
anything or anyone that you have put your business into the position of depending on.
Striving for Perfection:
If there is such a thing as a perfect solution, then I believe it’s the one
that you arrive at yourself
-- and which you feel best suits your business. Not what the Jones' are using. Not what's
on sale this week. And not the latest fad that the experts in the trade rags are
hyping and selling editorial about. I would not define the perfect solution as a
single solution -- but rather, a group of modules from multiple providers -- for which you
have clearly defined the functions to be performed by each -- interfaced together
with cleanly delineated lines. And most importantly, I define the perfect overall
solution as a situation where each individual technology module is straight forwardly
replaceable when it becomes obsolete.
Ergo, the first order of business is to look for modules that are designed to be
cleanly interfaced to. This can be a real challenge since most of the time there are no
standards on interfacing technology modules with one another. In fact, if a particular
field has stable standards, then maybe you should ask yourself if you even define
that field as technology at all.
In addition, some vendors (or employees) implement subsets or supersets of standards --
sometimes intentionally -- sometimes without any consideration to the big picture -- and
sometimes clueless to the concept of a big picture. At any rate, I would immediately
dismiss any module which does not provide interface mechanisms to complimentary modules
from various module providers -- including their competitors.
The Hook:
When choosing modules remember Langenberg's 2nd Law;
Look for the hook and you won't get took. Hooks
are a fact of life -- especially where technology is involved. And if you don't find them,
they will most certainly find you. And hooks don't exactly jump out at you and identify
themselves saying, "Hi, I'm a hook!". No indeed -- the most effective hooks are
camouflaged as tasty lollypops. So I would stay on guard for any module that feels
like it was designed to lock you in, shackle you or limit your options (especially your
exit strategy from them). Because if it feels like it was designed that way, it
probably was. I mean you don't really think marketing folks overlook issues this obvious,
do you? Of course not -- but often they're hoping that you or your profit minded,
convenience oriented supervisor will overlook it. And the odds of you taking the
bait are increased if they make it convenient
-- and tasty.
With products like this, things are not likely to get any better with such a provider as
time goes on either. So while you will eventually 86 every module that you ever implement
-- you’ll be singing, Ding Dong The Witch Is Dead
when you bag and tag this one. On the other hand, perhaps a little milking by a provider
is acceptable. It's your call -- you're the customer. But my contention is that it's time
to draw the line when a module, or bundle of modules (ah yes, the bundle) seem like
they're being intentionally manipulated to lock you in, and inhibit your exit strategy.
So let's stay on guard for any module that thinks the world revolves around it, wants to
increasingly dig it's meat hooks into your entire operation, or makes you feel like an
owned resource. The key is to look at each module -- and try to envision what life will
be like once it's replaced. If it's going to be a tough transition, then one of two things
is true; either the module (hardware, software, service or person) has unacceptable hooks
into you, or you have not planned an exit strategy. Either way, you're really
setting yourself up for the big one. It's just a matter of when, not if.
Modularity and Clean Lines:
Suppose you are considering modules A, B and C -- all from different technology
providers, and all of which work in unison to perform complimentary functions -- with
love, harmony and peace on Earth. Stopping
there would be taking the easy way out. Why not prove out your exit strategy? Look
for additional modules that would interchangeably replace each of these -- but still
cleanly interface to your other currently selected modules. Try to keep the
interface lines between your existing modules as black and white as possible.
Consider splitting one module into two, or combining two modules. Just make sure that you
end up with replaceable chunklettes, and that each module is individually replaceable in
preparation for it's certain eventual disposal. By the way, don't worry if a replacement
module doesn't exist today. Just envision and implement modules in such a way whereby
replacements can and should be designed. Because if it can and should be designed that
way, have faith that Mother Capitalism will eventually make this building block available.
And Then Come the Changes:
You know what they say, "the only thing constant is change". And this was
never more true than with technology modules. So what I'm saying is
that by being proactive -- you can avoid disrupting your entire organization every
time one of your modules changes. Why not be in a position to individually swap out each
obsolete module? Langenberg's 87th Law applies
here; Pay me now -- or pay me later. And to pull this off you definitely have to
pay as you go -- and consider how each improved module will affect your overall exit
strategy from every other module.
Once you have your modules selected and implemented -- the changes will come. It’s never
over. Each change will include new features. Rather than blindly implementing each change,
ask yourself, “Is this a feature, or a hook? If I take advantage of it,
will my exit strategy be inhibited? If so, is this feature so good that I should
redefine the lines between my existing modules? Should I combine two modules into one?
Split one module into two? Can I still use this updated module without deploying some of
the new features? Is there a way to implement this feature that won't leave you
hooked? Or is the module provider forcing
their features on you whether you want them or not?
Some upgrades may
feel heavy-handed -- intended hook you deeper and blur the lines between your
existing modules. Even worse, some module providers will do this to you while adding
little or no value to anybody but themselves -- and their (current and future) revenue
stream. In such a case, if a new feature inhibits your exit strategy, it might be
fair to at least consider that it was intentionally planted there -- often by marketing
people in an attempt to tighten their grip on you know what, further hooking you into
their products. And while you may not be a soothsayer, you can count on the fact that the
bubble's ripe for bursting when more and more of their features lack any
technical merit. And you can take that to the bank. Their bank. If forced features without
technical merit is the case, their next change (or upgrade) will almost certainly try even
harder to hook you even deeper. At that point it's a fair bet that the pube-grabbers have
taken over the operation -- and the top priority of their every decision is to lock you in
and keep milking you. From which point forward, your service won't go up & your price
won't come down. They would deny it of course, but you weren't born yesterday. So at this
point it may be time to find a module from somebody else -- and get out from underneath
this provider's thumb altogether. It's best to avoid getting splashed by the residue of
any bursting bubbles. But hopefully your clueless competitors will.
To summarize this section; since technology modules are constantly evolving, it might be
wise to continually re-evaluate the interface lines between them. The focus being
to continually re-access and/or re-define your exit strategy from each individual
module.
Everything's Temporary:
To some degree, once you buy into a module you have to play the hand you're dealt --
for a while anyway. But smart gamblers intentionally and proactively locate themselves in
a position where they can move to another poker table -- with minimal hardship. A
smart gambler doesn't commit in advance to sitting in the first convenient
chair all evening (e.g. long term contracts). A smart gambler can leave the saloon
when they want -- and immediately ride their horse down the street -- or to another town.
Why? Because before they entered the saloon in the first place -- they made sure
that their horse was fed, watered and not fenced in -- even if, for insurance purposes,
they knew that there was a reasonable chance that they may be going to unload that horse.
A smart gambler understands the concept of blinders -- that they're OK for horses and
other lesser forms of life. But a smart gambler never personally wears blinders. Perhaps a
smart gambler only plays with a stacked deck.
Cover Your Butt:
Now then, no matter how you deal with the people who authorize or write the checks, sooner
or later somebody's going to start micromanaging your purchase decisions -- because
they're in the loop of the money, and they're going to make their presence known. Count on
it. Maybe they'll wonder why you wanted to feed & water a horse that you unloaded the
next day.
Trying to reason with a
non-technical bureaucrat, that this was insurance against a replacement not arriving (or
something like that) is completely futile, trust me on that one. And a bean counter
(executive or accountant) is always, always, always going to choose the least expensive
option -- which means you're going to get hosed and be working overtime. But I always had
to have a contingency plan, I was always going to cover my butt, no matter what,
downtime was not an option.
Before proceeding, I recommend that you review Langenberg's 27th thru 33rd Laws.
If you are reading this, I hope you are covered by the 28th Law, and I pray not the 29th
Law.
So what I learned over the years, and what worked the very best for me, was to keep the
bean counters dumb. The less they knew, the less they had to complain about. And the more
you tell them, the more ammunition you give them. (keeping in mind that I worked for a
pretty informal, but fairly political company, which was not in a highly secure or
government environment.)
First of all, the bean counters are only going to find out about it half the time. But
they'll feel completely entitled to be twice as mad about it. So you think, well 50%,
that's not good, but it's actually better than that. Because half the time you'll have
made the right decision in the first place, which saved the company time & money. So
now it's down to only 25% of the time, that you'll have to deal with their double rage.
These are not scientific numbers of course, and maybe you'll be better able to predict
ship dates & the quality of undeveloped products. And I sure do admire you if you can.
This can be improved on by tarnishing their technical credibility (remember you're the one
that's going to be working overtime dealing with any short sighted decisions, and the only
thing they usually know is what you were dumb enough to tell them). Maybe they'll discover
something and complain loudly, but it turns out in their own favor, or in favor of an
executive. Eventually, as your reputation for uptime nears 100%, they'll stop questioning
every purchase, but it will never go away completely.
One Provider vs. Many -- Integrated vs. Interfaced:
The more modules that you acquire from a single provider, the more likely it is that
your overall system will be more integrated and easier to implement -- but the
tougher it's going to be to get out from underneath one or more of these modules when
the provider takes the slide down the slippery slope.
Conversely, the more providers that you introduce into the fray, the more up-front (and
ongoing) effort it will require on your behalf to interface these modules together.
Now I'm going to take a moment here, to point out, that I've used these two words many
times, integrated and interfaced. And I've taken great care, in the way I've used them.
Integrated modules from a single provider typically fit together more conveniently.
Whereas it is generally more difficult to get (and keep) interfaced modules talking
to each other -- because they are from multiple providers. But hey, you're the customer,
so it's your call. Isn't this fun?
But the
buck has to stop somewhere. And somebody has to decide whether to grab for each convenient
lollypop or pick and choose -- with your exit strategy high on the list of considerations.
If you're that person, making these decisions will be easier once you consider that your
business will almost certainly outlive each of your temporary technology
providers.
But once everything's been considered, in my opinion, you really have no choice but to interface
modules from multiple providers.
Band-Aids, Lollypops & Isolated Islands of Automation:
There will be times when it is not possible to find a module that interfaces
adequately with your overall system. In other words, for a while (possibly a long while)
somebody may have to perform a function which isn't interfaced or
integrated, but ought to be. You may find yourself in a position where -- in order to
provide some short term gain -- you need to introduce a temporary island of automation --
and crudely attach it to the other modules with a band-aid. At least until a better
fitting module comes along which does interface.
It is important
to replace all temporarily band-aided modules ASAP. Because the longer you keep them
around, the more inclined (and pressured) you will be to interface them into the
mainstream -- in any way possible -- shortcuts included. If you use band-aided modules
long enough, people are likely to forget (sometimes conveniently) that they were only intended
to be temporary. Ergo, if you don't eliminate the band-aids -- your overall architecture,
over time, will consist of multiple lollypops crudely grafted together. In this case your
numerous short term gains will at some point collectively turn into a big heavy long term
boat anchor hanging around your neck. And at that point all those shortcuts won't be going
away very easily. In fact you may be the one going away if you're responsible for
introducing this sort of prolonged chaos. So from an up-front proactive point of view,
"Pay me now, or pay me later".
Application Service Providers (ASPs):
As of the last update to this document (listed above) the pendulum appears to be
swinging in a new direction -- that of Internet based Application Service Providers
(ASPs). My guess is that this really may be some sort of a trend. But at this
point, nobody really knows for sure -- other than a handful of sure-fire ex-Data General
salesmen who have been laid off a handful of times by Dot-Bomb companies.
If the current ASP trend really does take off though, you will be purchasing less in-house
hardware and software -- and more outside services. But
keep in mind that modules are modules -- whether they be hardware, software, services,
people, or any other technological wrinkle or fad. And since modules are something or
someone that you must depend on -- and since they're all going away someday -- it's just
as important to have an exit strategy from each service as it is for hardware,
software or people. So let's keep our guard up -- just in case some of your future ASPs
went out and hired the marketing dirt-bags from a Dot-Bomb Internet company, who got them
from a failed minicomputer company, before previously working for a failed mainframe
company.
Gaining a Competitive Edge -- Let George Do It:
Learn about the technology modules that
your competitors have implemented. Find out about any high priced or long term technology
stakes that they have they driven into the ground. What holes have they dug that will
inhibit their exit strategy? Have they blindly painted themselves into a corner?
Discover what functionality they can't take advantage of because they couldn't resist
schlepping into some of those tasty convenient
lollypops. Then of course, don't make that type of mistake yourself.
Summary:
It requires a lot of discipline to maintain an exit strategy from technology
providers -- involving the
(occasional or frequent) choice between sacrifice and sin. So rather than just blindly
stepping on every land mine planted by marketing people, you might want to recognize some
features for what they are -- hooks. Then even if you recognize them as such,
the next question is, does it add any real value to your operation -- or is this a
solution to a problem you don't have? Is this a solution that will create more
problems than it solves? And if so, remember Langenberg's
4th Law; What you don't do is more important than what you do do.
Regards,
Chuck Langenberg
PS: Your comments are encouraged.
|