The Cargo Cult
"Those who cannot
remember the past are condemned to repeat it." - George Santaya
The very mention of the phrase "cargo cult" will elicit
either a knowing smirk or confused ignorance from anyone who hears it.
There is no other known reaction to this phrase. For those in the know,
there is a certain condescending superiority in mocking the ignorance of an
apparently primitive people. The sense of superiority is not earned as every
person exhibits cargo cult behavior at one time or another. Being able to
identify this behavior is truly a rare skill.
For those who have never heard of cargo cults, prepare to learn an
interesting quirk of history and, more importantly, how it applies in everyday
life. The cargo cult phenomena can be traced to the later part of the
nineteenth century. As Europeans and Americans began to interact with the
islanders of the South Pacific, they misconstrued the mechanism by which the
white people gained their apparent wealth.
To the islanders, Whitey performed certain rituals and the gods
rendered unto them the gifts of material wealth or cargo. Of course, the
islanders desired cargo from the gods and began to copy the rituals that
delivered the cargo. The Islanders had been known to create mock
airstrips, radios out of coconuts, conduct army field maneuvers, and design air
traffic towers. The fetishization of these rituals in the attempt to
appease the gods is what makes it so comical and tragic at the same time.
It's laughable to think that talking into a coconut radio in a crudely
constructed air traffic control tower beside a fake runway that has never seen
an airplane will produce the desired result.
In addition to mimicking the rituals that produce cargo, the
largest active cargo cult centers around the myth of John Frum. John Frum
is the god in their religion - a black man who has mastered the art of making
cargo appear. He had promised the islanders that he would return to them
and bring bountiful cargo. On the island of Vanuata, February 15th is
known as John Frum day. Every year, the islanders gather and conduct mock
army drills carrying fake rifles with the letters USA written on their bodies
anticipating the prophesied return of John Frum.
Interestingly enough, the name Frum does not appear in any census
in the English speaking world prior to the start of the cargo cult. The
theory is that the cult was founded by a GI who introduced himself to the
natives as "John from America". It's as if everything he said
after that was completely misinterpreted by the natives. John Frum day
has been celebrated for over seventy years and John has not returned to the
natives nor brought any cargo. Still, year after year the celebrations
continue and the belief persists that John's return is imminent.
Lest any Westerner feel too smug, it has been said that a
participant in John Frum day was asked how can he go on participating in the
drills waiting for John to come back when no one has heard from him in over
seventy years. The cargo cultist simply replied, "We have only been
waiting seventy years for John to return and you have been waiting for over two
thousand for your Jesus." You have to admit, he has a point.
There are plenty of everyday examples of dogmatically following an idea without
understanding why it is supposed to work.
In the United States, the diet industry is a $40 billion a year
juggernaut. In its simplest form, weight loss can be achieved by eating
fewer calories than a person expends. It really is that simple. Yet
how many people attend a Weight Watcher's meeting and then eat a Krispe Kreme
doughnut? Going to Weight Watchers is not a bad idea to get some support,
learn some diet success tips, and learning about nutrition; but it will not
result in weight loss in and of itself any more than speaking into coconut
radios will bring cargo. The meeting does not cause the desired result,
it is the behavior modification that matters.
The mistake of thinking that attending the meeting results in
weight loss can be found all over corporate America. For example, the
application of Six Sigma processes to software development. Six Sigma
originated at Motorola in the 1980's as a way to improve quality. The
desired goal was to have less than 3.4 defects per million units - a standard
of quality so high that testing units would actually result in more defects
than not testing. For defined manufacturing processes where defects followed
a normal distribution curve, Six Sigma provided great mathematical tools and
concepts to improve efficiency. The success of Motorola's methodology
prompted other companies to start applying what was a manufacturing process to
just about everything. At General Electric, under the leadership of Six
Sigma loving Jack Welch, Six Sigma methodology was applied to every aspect of
the company. Recruiters in HR were tasked with creating projects to lower
the amount of days it took to hire a candidate for a job posting, which begs
the question is it more important to hire someone quickly or to hire someone
who is a perfect fit for the role? Would it be better if the job was open
for 30 days and filled with a mediocre candidate or if it took 50 days to find the
right candidate? With mis-applications such as Six Sigma projects for HR,
the entire movement quickly became a corporate Cargo Cult.
Six Sigma has five distinct phases: Define, Measure,
Analyze, Improve, and Control. New buzzwords were created to find out
what the real problem to be solved for like root causes, voice of the customer,
voice of the business, etc. Templates were created to capture the
information and an emphasis was placed on metrics. In the HR example, the
problem was open positions were not being filled quickly. A goal was set
to reduce this time and an elaborate way of measuring the opening's position
was created. Where the new process gets Cargo Cultish is the moment
incentives are put in place is the same moment that people will start gaming
the system for their own purposes. What is in the best interest of the
project manager, the HR recruiter, and all involved with the project may or may
not be in the best interest of the company. The project manager will
claim that due to their hard work, the average number of days it took to fill a
position fell by some percentage saving some amount of money (the savings will
be based on a series of assumptions which are dubious at best, but the good
thing is no one will ever ask for the numbers let alone challenge them), and he
or she will probably get promoted. The cost and time spent on the project
will rarely be factored into the program's true cost and everyone will get a
promotion. Unfortunately, the new system will reward hasty hiring and not
good hiring. Mediocre candidates will receive job offers in order to not
exceed the arbitrary goal of leaving a position open. An analysis of the
quality of candidates resulting from the new process will likely not be
performed and all attention will be placed on the now critical (but once
arbitrary) number of days a position was open metric.
At least when it comes to hiring, the consequences of this example
are somewhat harmless. It has been shown time and time again that the way
a candidate performs in an interview situation has no correlation to how they
perform on the job. Where it gets really scary (and even more Cargo
Cultish) is when processes like this are applied to cost cutting and used to
define Key Performance Indicators (KPIs), and worse circulated in executive
scorecards.
The Dreaded KPI and the
Birth of Offshoring
The offshoring movement has been going on for decades.
Around the year 2000, it picked up momentum starting with call center
jobs. In theory, it was cheaper to hire people in India to handle
customer support calls from America. Since the consumer in America was
calling, not interacting face to face, why not send the call to a country where
people speak English (sort of), did not have unions, did not make demands for
health care, and were willing to work for a fraction of what an American would
ask for? Call centers sort of work to drive costs down and so long as
consumers stick to the script, it kind of works. Sure, investments must
be made in building out the infrastructure, rigorous training, linguistic
classes to minimize accents, and management. However, the workers in the
call centers eventually believe they are valuable and have no loyalty, so
turnover is high. To counteract high turnover, wages go up, bringing a
price equilibrium to about the cost of keeping the job onshore, but like I
said, it kind of works for call centers. It's low end work and at the end
of the day, regardless of where the work is done, no one is ever really happy
with the resolution that is provided.
Since offshoring call centers sort of worked, there has been a
movement to offshore all kinds of other work on the premise that it will be
cheaper. Take, for example, programming of large-scale enterprise systems
applications. In the fury of systems integration work leading up to the
Year 2000 and the dreaded Y2K bug, it was said that implementing Enterprise
Resource Planning systems was "the corporate equivalent of a root
canal". The projects were complex and very expensive. In an
effort to lower costs, companies started to offshore what was thought to be low
level tactical work.
My theory is that someone took a look at the hourly rate that a
programmer was making in 1999. Let us say, for example, billing rates
were between $150 and $200 per hour. To a manager making less than a six
figure salary annually, this looks like an exorbitant number. Most
consultants or programmers who were billing this hourly rate were receiving
only a fraction of it, but the manager paying the bill could not comprehend how
this person they hired was making nearly $400k per year. An Indian
offshoring company walks in and says we will provide you with programmers and
we will charge you $20 per hour. The manager has no problem paying
someone forty grand a year and it seems like a bargain. Instantly, their
bill was lowered by 90%.
Unfortunately, the adage you get what you pay for has never been
more true. In systems integration work, the real problem is rarely
writing the code. The problem lies in understanding what exactly the end
user really wants as, often times, it is not what they say they want.
Users, Subject Matter Experts, Customers, Clients, Stakeholders, Business
Managers or whatever you call them do not think in terms of code, tables, or
design. They think in terms of high level business scenarios and think a
fully defined specification is, "JUST convert the
purchase orders from our legacy system." (A real spec I have actually
handled in a previous life)
Please note, the above "specification" makes no mention
as to what validation rules must be performed on all purchase orders, what
tables the legacy purchase orders are stored in, how to map any differences in
data between systems, etc. The very high level and non-actionable
requirement is then sent offshore to be acted upon by a software engineer who
barely speaks English and has zero practical business experience. The
engineer will predictably do one of two things, he or she will either freeze
like a deer in headlights or make wild assumptions and code away merrily.
Sadly, the deer in headlights scenario is the lesser of the two
offered evils. Even though no progress is being made on the activity, the
engineer will always report that their status is green and there are no
problems. Culturally, it is career suicide to raise one's hand and say,
"I don't get it." Eventually, the deadline will approach and
the onshore program manager will suddenly find out that no progress has been
made in weeks. Panic will ensue, but thankfully, real requirements will
be created, a new deadline will be established, and eventually the requirement
will be satisfied. Since no code will be written prior to the panic,
there will be no fundamental re-architecting or regression testing
required. In this case, doing nothing with bad requirements is far more
preferable to making speculative guesses and reworking the solution once
requirements are known...
Which leads us to the alternative to doing nothing. Doing
something, paradoxically, is far, far worse, in this scenario, than doing
nothing. The engineer that does something has no relevant business
background or understanding of the rules governing the requirement they have
received. In order to feel productive, they simply make up business
rules. When asked for a status, the engineer says that everything is
going fine. When the deadline comes, sure enough, the legacy purchase
orders are converted but the actual results are no where near the
expected. Panic ensues and all the business rules governing the conversion
are then captured. The engineer then has to redo all their work, but
rarely starts with a clean slate and instead tries to shoehorn in new
requirements on top of their made up requirements resulting in buggy and
overall poor code.
So where are the savings? The hourly rate now moves from
$200 per hour to $20 per hour. However, since engineers are now available
at bargain basement rates, usually five offshore resources are hired to do the
work of what would have been done by one onshore resource. With this in
mind, the cost now is $100 an hour. But wait, there's more - it usually
takes the offshore team twice as long to get the job done when you account for
the do nothing and then get requirements, or do something and redo it all over
again methodology. Now, we're right back to we we started. There is no
actual savings taking place, the work takes twice as long, and it requires a
lot of sacrifice on behalf of the business users. Their lives will be
disrupted by conference calls in the middle of the night, multiple efforts to
give requirements to people who do not understand your requirements, and hours
pouring through documents that appear to be in English but in fact are
not. When factoring the cost of the extended team's increased commitment to
the project the costs begin to skyrocket.
It all comes back to the KPIs and the Scorecards... A
General Manager can report to their Vice President during their review that
they have reduced costs. The GM can say (and how they can do this with a
straight face is beyond me) that they have reduced the cost of development from
$200 per hour to $20 per hour. VPs being VPs never think to ask the next
question and ask what the overall program costs are with onshore versus
offshore or if the number of resources and hours spent in development were kept
the same. The VP shakes their head and congratulates the GM. No
money was saved, the extended team is burnt out, the code sucks, but the GM
gets a big raise and that's what really matters.
Vendor Consolidation and
Basic Economics?
As if offshoring is not bad enough, large companies have found a
different way to screw themselves and their onshore partners in the
process. Procurement people who are used to making consolidated purchases
of materials decided that consulting resources could be purchased in the same
way. Analysis was done on just how much money was being spent on
consultants and an across the board number was thrown out, probably so it could
be tracked on a scorecard. A bold proclamation was made, such as cut
vendor spend by 15%, or else. Procurement then decides that since the
company is big, they can consolidate to a handful of agencies and give them all
their work. In exchange, the agencies will reduce their rates. At
this point, anyone who has had any experience in dealing with consulting
companies, staffing agencies, marketing companies, etc. should burst out
laughing. The problem is, people are not commodities. The right
consultant is worth their weight in gold while the wrong consultant is nothing
more than a corporate parasite.
The process starts by procurement, who has never hired
consultants, taking a look at the companies that provide consulting
services. From there, they make a list of arbitrary requirements as to
who should be included or excluded from the final list of "approved
vendors". If any vendor company finds that they are not on the list,
they begin an all-out campaign to be included. Once the list has been
established, it is nearly impossible to be included on future versions.
For those who have managed to make the list, a game of politicking begins to
see how many competing firms they can convince procurement to kick out in the
future.
Before examining the theoretical cost savings that centralized
procurement may or may not provide, it is worth a brief examination of how
consulting companies work. They hire a person and pay them $X/ hr (even if it
is an annual salary, this still applies - just divide the annual amount by 2000
hours and voila - $X /hr). They then charge a client $Y /hr for client
services. Their profits are then $Y - $X x billable hours. No matter how
complicated some firms try to make it. Just as every fast food restaurant
claims to have a secret sauce and uses mayonnaise and ketchup, it’s the same
with consulting firms.
With that in mind, what should people expect if the variable Y now
takes a 15% hit, competition is all but removed, and most consulting firms have
a KPI for margin? Obviously, X goes down with Y which results in attracting
lower performing people. Just as with offshoring, the lower rate now requires
more people and more hours resulting in no cost savings, increased risk, and a
host of other problems. However, if you focus on the pure dollar per hour cost,
it has been reduced.
I have seen this approach used at multiple Seattle based
companies. Consulting firms that had been in existence for less than two years
magically got on the Approved Vendor List (mainly by kissing the right rings in
procurement) and started flooding the market with twenty-four year olds freshly
laid off from the now defunct Washington Mutual. However, work still had to get
done by someone and with no real competition, they were able to get fat and
happy all in the name of cost cutting.
Back to Cargo Cults
“Everyone wants out of the
box thinking, right up until you give it to them.” -Me
These are just a handful of observations I have made in my two
decade long career as an IT professional working as a Business Analyst, Program
Manager, Project Manager, Software Engineer, and Solutions Architect as well as
armchair economist (not a professional - just a top seeded amateur). Every
observation should be apparently obvious, but somehow isn’t.
Given that making software is difficult, expensive, and risky; maybe
it’s time to stop doing things simply because that’s the way it’s always been
done. Methodology has moved from the waterfall approach to agile, but neither
guarantees results.
“That was a great use of my time!” said no software engineer ever
following the daily standup.
Just as performing incantations into a pair of coconuts fashioned
into a radio will not bring cargo, neither will holding a daily standup produce
great software. Process can be a good thing and can be used to keep teams on
track. However, every time something is measured and someone is held
accountable to a metric, behavior will change to achieve the desired metric.
This behavior may be a good or a bad thing, but management by metrics is both
lazy and dangerous. Unintended consequences have to be sought out and accounted
for, clear vision and leadership provided, and cost cutting can make things
more expensive.