Cargo cults in IT

The end of WW II gave rise to a striking example of a causality problem. On small, remote islands, indigenous people encountered large numbers of military servicemen for the first time. As we, and others, landed ships on these islands, cleared jungles for runways, erected control towers and ran military drills the indigenous individuals observed newfound well being in the cargo our servicemen brought with them.

When the war ended, the military packed up their temporary bases and took their cargo planes with them. And with it went the newfound wealth of the native people. So, what did they do?

Well, they replicated the actions they saw taking place. They cut airstrips out of the jungle. They erected towers similar to the landing towers they saw. They executed military style drills. They carved wooden headsets to wear like the ones they saw servicemen wearing.

Since they didn’t understand the causality of the entire event – a war that led to need for new bases that led to airfields and cargo planes, they figured if they recreated the parts they observed they’d get the same outcome. Cargo planes ought to land and bring cargo. Of course, it doesn’t work that way, which is what makes the idea of a ‘Cargo Cult’ so interesting. We clearly see the logical problem in that situation.

When it comes to the corporate environment, however, we often fail to see our own Cargo Cult behaviors. We observe a great company, say Google, and we see that they have bicycles on their campus, so we buy bicycles for our campus. Or Facebook engages in hackathons so we start to do so too. But buying bicycles or performing hackathons is not going to make your company like those other companies. You are simply emulating behaviors that look like the other company without understanding the underlying culture that causes them to do these things. And as a result, you’re likely to get disappointing results from the mimicry. These companies aren’t successful because they engage in these behaviors. The companies are successful first and therefore may engage in these behaviors.

Which brings me took another point. We often look at older companies that fail and we observe that they don’t engage in these behaviors, and we use that as evidence that these behaviors are necessary to survive. But we can learn something from Mark Buchanan’s ‘The Social Atom’ on this point. In his book he demonstrates a ridiculously simple model that predicts the rise and fall of organizations, simply based on time and getting too big. You don’t need to model any behavioral stuff to get the effect as I recall. So, probabilistically, large old companies will decline even if behaviors are held steady. There will always be companies coming and going, and we will always be able to be selective and say “see, that company didn’t do X and they failed. We need to do X.”

If you find yourself saying that in the future, just remember that you may now be a card carrying member of a cargo cult.

Want something fixed? Give it to someone who doesn’t want the job

I recently had a great experience with simplifying IT processes. Due to recent org changes, a home grown product (that was a ton of spaghetti code) got turned over to a new team. The thing was, the new team’s job wasn’t a support role and they didn’t particularly relish coding. Over time, the organization had become dependent on the product, although people suspected it was partially because they didn’t know any better. There were off the shelf tools which could do the same job.

Well, it turns out if you want to get rid of some job, the best people to give it to might be the people who don’t want the job in the first place. If you’re content building and maintaining a bunch of spaghetti code, and I then give to you an additional product, you’re likely to keep maintaining that one too. But, if you don’t particularly like coding, you are going to try and avoid doing it. One of the best ways to avoid doing something is to get rid of it.

In fact, this is exactly what happened. The team, who didn’t desire to fix everyone’s problems figured out how to replace the home grown product in just a few months. For years the organization had been told that it couldn’t be replaced. The difference? The old team was content to maintain it, perhaps even proud. The new team had nothing invested in it and didn’t want to.

“I don’t think necessity is the mother of invention. Invention . . . arises directly from idleness, possibly also from laziness. To save oneself trouble.”
― Agatha Christie, An Autobiography

No True Scotsman

I was recently enjoying the Illustrated Book of Bad Arguments when I came across the logical fallacy called “No True Scotsman.” It immediately reminded me of a discussion I was having with a couple individuals on software development methodologies. Up until recently, a team had been pushing their development methodology as Agile development. That was, until interest in Scaled Agile Framework had emerged. I can’t comment on the goodness of SAFe, but we had lots of data available from this group on the efficacy of their form of Agile.

The discussion proceeded something like this

Them: “We’d like to start using SAFe, can you help us establish a measurement system to support our decision.”
Me: “Sure, I’m always willing to experiment and learn, but let’s approach this with some skepticism. Our past data on our Agile projects indicates no evidence of statistical differences in quality or productivity.”
Them: “What we were doing wasn’t true Agile.”
Me: <stunned silence>

This is a great example, and interesting use, of the No True Scotsman argument. When we lacked data about what we were doing, it was Agile, but the minute we had data that it may have not been that beneficial, suddenly it wasn’t really Agile anymore. The conversation forced me to do some digging into the scholarly research on Agile methods. There’s a dearth of good research here. Jones offers some analysis in his article here: I like Jones a lot, being one of the few researchers to take up potentially unpopular positions. He is in the consulting business, so he doesn’t give away his data set which for academics is challenging. There’s also this systematic review of Agile from 2008 (ancient in IT terms, I know) which concludes there’s little strong evidence for Agile methods in the available research. But, of course, if you’re willing to adopt the No True Scotsman argument, that doesn’t matter. After all, whatever gets studied won’t really be a good example of it anyway. 😉

Sacred cows make tasty steak

At the risk of offending, someone once said the title of this article in a meeting. It was a meeting about change. Process change, organizational change, I can’t quite remember. But it’s the quote that stayed with me, and was brought to mind by a number of friends commenting on their outrage that some large retailers will be open on Thanksgiving this year. For my entire childhood, nothing was open on that day. It was the extreme of boredom, and I’m sure worse for those with families who don’t get along. Not that long ago, grocery stores started opening for at least a portion of the day so that you could buy whatever ingredients you forgot. It was simply a matter of time before retailers realized there was pent up demand to do something besides sit at home.

But the uproar is there, because it is a change and sites like Facebook and Twitter exist to vent that frustration. Now, I’m not going to take a position on whether stores should be open or not. I don’t think we will be out and about anyway since I have a lot of cooking to do. But as someone who has to deal with implementing constant changes, it is always interesting to see how the change management process will go. Right now, it’s outrage and push back. In a few years, it probably will be a vague memory. Sometimes in order to move forward, you have to take a hard look at whatever your organization considers sacred or ‘the way we’ve always done it’ and determine if that tradition needs to be broken.

Why change if nothing’s going to get better?

I’ve often wondered why we undertake some projects at all.  Often times we’ll upgrade a system or replace it solely for the purpose of getting to a “common infrastructure” or “common process.”  Now, not that there’s anything wrong with achieving commonality, but it has to serve a purpose greater than simply having something be common.

If someone said to you, we’d like all of you to drive Ford Fiesta’s (no insult intended, I just picked a car) simply because we thought everyone should have a common car, would you be on board with that?  No, of course not.  A Ford Fiesta might not meet your needs.  If you’re already driving a Toyota Prius, it might not even make anything better – assuming the only category for evaluation was fuel efficiency.

This was something I struggled with when taking my LEAN training.  On one hand the trainer indicated that you should never standardize before you optimize the process – in other words, only change if you are going to change for the better.  In another place the trainer indicated that without standards you cannot optimize.  So, suddenly you have a problem – if you don’t standardize (and therefore necessarily change) then you can’t optimize, but you shouldn’t change unless it is optimized???  Which is it?

I believe the answer is one of intent.  You may change/standardize if the intention is to then improve, but if the intention is to reach a standard simply for the sake of being standard, don’t do it.  What’s the point of change if nothing is going to get better?  Why add disruption if you don’t intend to make something better in the long run?  It seems silly.

Process change demands communication

I don’t travel by air all that often – still, it’s often enough that I belong to the rewards program at one of the major car rental companies. Part of their features is that your car will be ready and waiting for you when you arrive. This is very convenient, since it can mean the difference between standing in line in the office for twenty minutes, or being twenty minutes into your drive.

So, when I landed the other day, I was ready to hop in my rental and drive off. I got into my car and immediately reached for the hang tag which is usually dangling from the rear view mirror. You need the contents – namely a contract – in order to get off the lot. At least, up until this visit you did. I assumed they forgot it, so I got out of the car and walked over to the office to get it. The office was quite busy, so I stood there about ten minutes before it was my turn.

Then, I said “there’s no hang tag in my car” to the attendant who said “oh, we don’t do that anymore. We just print the contract at the exit.”.

“Oh, ok, ” I replied. I was somewhat annoyed that despite them having my email address and phone number that they had not bothered to tell me this and that I stood in line for ten minutes waiting to find out there was nothing wrong. But what really surprised me was that three other people, who were in line behind me heard my conversation with the attendant and exclaimed “oh!” as well.

Now, I’m not actually sure this process change was any improvement. At the exit, the printer was inside the little guard house, while the guard was standing outside. Each time he’d have to walk back in, get the contract that just printed and come back out. The line was longer to get out than it usually is, mostly because of the motion and waiting waste this change created. As a customer, not a good experience.

But, first and foremost, that little bit of waiting at the exit I did is nothing compared to the then minutes I waited just to find out that the process had been changed. If this was the one and only time that the process will ever change, it wouldn’t be so bad… But, of course, it won’t be. Communicating the change is important as well. Don’t overlook its value.

“The problem is…”

I found myself stopping my own conversation the other day when I started a sentence with “the problem is…”  Why?  Well, frankly, I didn’t know what the problem was.  I was having a friendly conversation over lunch with a friend and we were bemoaning pervasive poor development practices.

It was quite an engaging conversation, as is most kvetching, to add up all the problems but not necessarily have an answer.  After all, we all need to vent sometimes.  Somewhere along the way though, I said “the problem is…” and I had to stop myself and say “well, I don’t know if it’s a problem, but …”

What’s the big deal, you ask?  A friendly, but unscientifically founded conversation like this one could someday turn into action.  Sure, if I have no intention of doing anything but complain, then the problem can be whatever I want it to be – lazy employees, terrible processes, management disincentives.  It really doesn’t matter, until you intend to do something about it.

Suddenly, those innocent “the problem is” statements become a dangerous jumping off point to change something, perhaps something you don’t entirely understand.  Maybe the attempted change will be a fool’s errand that ends up nowhere, but maybe it’ll be fantastically destructive.  You won’t know which until it happens.

When we get engaged in spouting our theories about what’s wrong with the world we end up with some pretty cockamamie ideas about how to solve the problem that isn’t even really there.  “The problem is” sounds terrible confident, but it hardly ever is.


I received a nice rejection letter today for a paper I submitted to a conference.  In my career, I know there will be many, many more rejections to go along with the acceptances.  This rejection even came with very helpful feedback about what I needed to do differently.  All in all, it’s the best kind of rejection one could get since it stood a chance of leading me to a better result.

But, at the same time, it still felt really crummy.  Deep down I know that the reviewers of this journal have incredibly high standards and that lots of people vie for a limited amount of space.  There must be winners and losers.  But the feedback gives me the opportunity to regroup, improve and perhaps resubmit my work and get accepted next time (or the time after that…)

At the same time, I’ve been working with a team to implement peer reviews.  One member of the team called the reviews a hazing, like it was some rite of passage and when you’d gotten through a few you’d be in the club and not have to do it anymore.  Not so.  Peer reviews aren’t like hazings, because they never end.  The reality is that members of this team (and any team who regularly does serious reviews) will be subjected to endless rejections.  No matter how many times it happens, it’s going to feel not great.

Should we stop doing it?  Should the journal simply accept any paper submitted to avoid hurting the authors’ feelings?  No, of course not.  Should we stop doing reviews simply because it may result in someone having to rework their analysis, design or code?  Again, of course not.

Being rejected is unpleasant, and I doubt giving it some euphemism like “deferred success” is going to fix that.  We shouldn’t give up on having high standards for our work simply because being the recipient of bad news feels, well, bad.  Nor should we give it up because delivering bad news is uncomfortable.

At some point, we have to learn to live with being rejected.  I don’t think we’ll ever like being rejected unless of course, failure was consciously or unconsciously our plan all along.  But we can learn to accept it as a natural course towards improving our work and ultimately being able to be proud of the quality of the result we created.

Any given Sunday

Now that the Superbowl is behind us, I feel like it’s due time to write a football analogy.  OK, it’s not an analogy, but I was reading Don Banks over at SI as he discussed the playoffs system and why we seemed to be so enamored of it.  A lot of it had to do with the Seahawks, who had somehow (at the time of the article) become potentially the losing-ist (is that a word?) team to win the Superbowl.  In fact, at the time they would have had to have won the Superbowl to end with a winning record.

At any rate, his point was about whether the playoff system was fair, seeing as how a poor team nonetheless seemed to make their way into the playoffs having had a mediocre season at best but having beating the right team at the right time to secure their place in the playoffs.

Was this right?  Weren’t there better teams who ought to have been in it despite the quirky loss to the Seahawks?  He argues, that no, we like the “any given Sunday” mentality, which treats the football field like a miniature war – a foe is vanquished in a single event.

In business, however, rarely does the war end over a single battle unless the gamble is so catastrophic as to destroy the company.  No, it has little to do with “any given Sunday” and instead requires a dogged determination to continue to work at and improve the business.

Therein lies the disconnect for me.  Is there something in our DNA?  Is Don Banks right that we are tuned to like playoffs and heroes and to dismiss solid, consistent but unexciting performances in favor of dramatic rescues from the brink?  If so, how do we overcome this mentality to look for and reward heroism in favor of consistent, and continually improving results?

Good leaders don’t just provide the direction

This headline is probably old news to almost everyone, but it couldn’t hurt to reiterate it one more time.  We tend to think of leaders as visionaries, not necessarily do-ers.  It comes as no surprise that many who are anointed to be leaders often provide the direction, but lack the ability to see whether said direction has been done.

Organizational inertia is strong, so when a new manager arrives at the organization, s/he may forget that there are two ways employees can make them happy.  The first way is to do what the leader asks, to follow his/her vision and try and make it a reality.  If it happens, and the vision is a good one, the organization can thrive with a change of leadership.

However, there’s another choice.  Instead of actually implementing the vision, you could simply tell elaborate stories about how things are changing without ever doing anything at all.  That’s an organization’s inertia.  It’s easier to tell stories about how doing the exact same thing as we were before is now the new thing than it is to actually implement the new thing, whatever it may be.

If, as you lead the organization, you think you can sit high on your throne and expect things to happen, ask yourself, why would anyone do anything differently if I have no ability to observe that it’s different? 

As the head of a software organization, you can’t readily visit the factory and see parts being made.  You’d think this precludes you from “going to the gemba.”  Not so.  You can see the effects of your change through new artifacts being created by the process, via audits and changed measurement systems.  You’ve got to get out there and ask for those things, for people to provide proof that things are being done differently than before.  

It’s too easy to stay in your comfort zone – both the employee who can pretend to change without changing and the manager who can be content to be told a story.