Builders Fail --- All The Time.

"Let us talk about any one task or project which you consider to be your biggest failure" --- I ask a veteran programmer who; for the purposes of this post; we shall refer to as Fred.

Fred stares at me with questioning eyes wide open; as if I just asked him the famous-inappropriate-are-you-a-virgin-question.

Throughout the interview Fred takes great pride and speaks at length when asked to discuss his success stories but but behaves like he has been put on spot and asked things he cannot answer when asked about his failures.

After taking over a few hundred interviews and observing countless genuine builders at work if there one thing I have learnt about genuine builders who make small or big dents in our universe; it is that they  --- fail.

They fail all the time.

Genuine builders do not think of themselves as seriously kick-ass-rock-stars who can churn out zero defect code every time they are asked to. Most genuine builders indulge in decent amount of soul-searching; and have some a decent level of self loathing for themselves.

Most genuine builders aren't ashamed to openly discuss; analyze and learn from their failures.

If there is one video that describes the idea of flaunting your failures openly with class and glamour; it is the Nike-Commercial on Failure:

"I've missed more than 9,000 shots in my career. I've lost almost 300 games. 26 times I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed." - Michael Jordan

If you haven't clicked on the link of the video you should.

As 'grown-ups' our fear of failure and the tendency to see it as a negative experience comes from the sheepish desire of being 'safe' and mediocre.

Michael Hunter; takes the remarkable lesser walked path. He nudges professionals around the world and encourages them to fail early and fail often. He explains:

If you're lucky, however, your family encourages you to fail early and often. If you're really lucky your teachers do as well. It takes a lot of courage to fight against this, but the rewards are great. Learning doesn't happen from failure itself but rather from analyzing the failure, making a change, and then trying again.

Over time this gives you a deep understanding of the problem domain (be that programming or combining colors or whatever) - you are learning.

Exercising your brain is good in its own right ("That which is not exercised atrophies", my trainer likes to say), plus this knowledge improves your chances at functioning successfully in new situations.

Has it been a very long time since you last failed?

If you answered that question with a 'yes' --- you need to find a problem bigger than what you are currently working on.

Get out of the boring territory of 'safe' --- fail like a child and learn like one; dear reader.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Let's Empower Teams To Have Fun.

During our early days at Multiplitaxion Inc some of us got a little excited about our work-culture and thought of taking it to the next level by introducing a little bit of a 'Google effect' to our very own work environment.

We tried to strive for an independent 'budget' that could be allocated to each project manger to use as he sees fit. Like all beautiful ideas, the concept was simple, pure and clean at it's very core. Every month, team leaders would get a certain budget which they could use to boost the morale of their team in whatever way they see fit.

Ways in which you could use it could include:

1. Buying gifts for top performers and genuine rock-star builders.
2. Organizing project parties.
3. Buying a X-Box for the team so that they could kick some alien-ass if they were tired of coding.

I could probably go on with that list forever but I am hoping; dear reader; that you get the general idea.

Assuming that Multiplitaxion Inc, was made up multiple Multiplitaxion Inc's that happened to be successful, we thought we aught to give some empowerment to the teams and see how they end up finding innovative ways of maximizing fun with a limited budget. This was an idea that would let us do just that.

The idea would also allow us to see how teams of genuine builders like to have fun; instead of taking them to a party and then 'hoping' that they enjoyed themselves when the dinner was over.

Lets Shit-Can The Shitty Empowerment Idea.

So a bunch of young and budding managers; me included; conceived the whole idea of this independent; 'fun-budget'. Three weeks later; we were sorry we had anything to do with the idea.

We were rotting in meeting hell and attending one meeting after another where we were answering what the basic idea of this 'fun-budget' was; what the scope of the budget was; what were the kind of expenses it was supposed to cover and what were the kind of expenses it was not supposed to cover.

After three months of conversations; the idea was finally approved.

Here are the specifics of the approval --- As managers each one of us were now allocated with three-dollars-per-team-member-per-month with which we were free to increase the team morale and make the environment (and the world) a better place to live in.

If you still did not get the ironic-humor in this; dear reader; allow me to explain. What this effectively meant was that if you had a team of five developers you had a full fifteen dollars a month to treat them, give them iPods, T-Shirts, organize project parities for them or even get your team a common X-Box.

None of us talked about the 'budget' after that day.

The budget that was allocated to us was never used and we decided to shit-can the idea.

Fun Is Serious Stuff --- And It Is Not Cheap Either.

The awesome part about being in a kickass team is that you do not need a lot of organizational funding to build great relationships with team members. Leave a kickass team of genuine builders and story tellers alone and they will attract other builders and story tellers.

Get enough insane trouble makers or rule breakers in your team and they will find out ways to have fun --- with or without the organization's involvement.

The interesting thing about hiring intelligent people is that even if they are not very articulate and expressive about what they see, observe and realize most of them understand the organization at a level that is much deeper than their managers even think they understand. So when the once hyped up morale budget was shit-canned by us; no-one in the team talked about it.

Everyone understood.

We just decided to forget it almost like failed childhood ambition.

Even though we lacked words to explain what had gone wrong with the overall idea; everyone in the  team; including the junior most engineer who knew about the idea; understood exactly what had gone wrong with the idea.

What this incident really did was teach me the level of importance most organizations out there give to the idea of 'fun' in the work environment. Some of the best organizations out there might spend hours talking about the idea of creating 'fun-filled' environments but talk about expenses associated with 'fun' and chances are that you might hear the sound of crickets chirping.

Fun Is Not Very Expensive Either - The Nine Ten Rule.

"So Pops; are you by any chance suggesting that we spend millions creating a fun work environment" - you frown.

What I really learnt from the whole 'fun-budget-episode' at Multiplitaxion Inc, was that there is a price associated with creating remarkable fun filled environments. It does not come cheap.

Having said that is it not the Hollywood-Dream that most organizations discard as unachievable.

To prove my point; dear reader; allow me to propose the Nine-Ten-Rule.

If you own an organization; or are responsible for budgeting; might I suggest that for every ten employees that you need:

1. Don't hire the tenth employee; just hire nine.
2. Take the average salary of the nine employees; consider it the salary of the tenth employee and add that to your overall 'fun' budget.
3. Allow the team of nine to decide what they want to do with this budget.

It's not exactly the programmers bill of rights but it's a good start.

Sometimes; Nine Is Much Better Then Ten.

Happy builders; build more and if you have spent enough time and energy at hiring the right people for the right job; chances are that with the fun element thrown in; your team of nine; will be much more productive than a team of ten mediocre programmers.

I don't know about you; dear reader; but I would rather have nine really happy tribe members over ten unsatisfied grumbling disconnected average employees.

At Multiplitaxion Inc; we were a closely knit team; having fun; meeting on weekends; going out together; but the passionate idea of adding fun to the overall 'organizational' environment was just not there.

With three-dollars-per-employee-per-month; we had seen; first hand; how seriously Multiplitaxion Inc; took the idea of 'fun' --- and having seen that first hand --- when it came to having fun at an 'organizational' level --- we hibernated.

The soul of this entire post; dear reader; if squeezed in a couple of lines; would come to this --- Two roads diverged in the yellow woods; and given the choice between a mediocre work environment of ten average employees and a seriously kickass fun filled environment of nine tribe members; Multiplitaxion Inc, walked the easy-safe and boring first path.

Which path has your organization taken?

Do you think your organization is 'man enough' to adapt the nine-ten-rule?

How seriously; does your organization take the idea of 'fun'; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The Skip

Fred is at my desk on a Monday morning.

Fred; as usual has a problem with his manager.

I cringe.

What Fred is indulging in right now; can be otherwise referred to as a 'skip'. Put very simply; skip --- is a time when you decide to stop reporting to your boss and 'skip up' to your boss's boss.

Whether you are a manager or a young and budding engineer; chances are that you have either used 'skips' or have witnessed a couple of skips being used in your professional life.

Who has the ability to exercise 'skips' in your organization; to a large extent; will eventually define the whiner to builder ratio that ultimately prevails in your organization.

Positive Skips

During my young and budding days as an engineer at Multiplitaxion Inc; we worked on countless weekends and late nights for more than a year; only to discover when the year ended that no-one other than our reporting manager knew what we were working on. Turns out; this young and budding manager of ours had a history for quietly absorbing every single drop of credit without passing a single iota of it over to anyone in the team.

Months later; me along with a couple of engineers decided to exercise the 'skip' when our manager was out on vacation.

We slogged countless hours to finish a project three weeks before it's finish date; purely because we wanted to send the completion email before our manager returned from his vacation. Doing that allowed us to strike a conversation with a technical director of the organization and open up a new communication channel that did not exist before.

Put simply; it allowed us to ship; and show rather evidently; that we actually functioned better as a team without this manager of ours.

It worked.

Within weeks we had a lot more flexibility of taking decisions; dropping features and doing what worked best for the product. 

If I can think of the number of times I've exercised a skip in my; I would consider skips as 'isolated' and a rather rare events in my life. If I'm reporting to you; the only quality I expect out of you; for me not to even think about exercising a skip is --- empathy.

Unless you are a downright asshole; skips are off-limits in my professional life.

However; If you are an asshole and if you give me an opportunity to exercise a skip --- I will.

Negative Skips

Today; every once in a while I see a young and budding engineer like Fred; trying to exercise a 'skip' on his manager. Skips; which were a rare incident; and a rather powerful tool in the hands of builders when we were growing up as young and budding engineers seems to have transformed into a tool to jump up to the next level for ambitious but incapable programmers in the software development world of today.

I've seen:

1. A young and budding engineer take a shot at estimation where he was merely a part of an email alias that was CC'ed when a vice-president asked a technical architect to do the estimation. Turns out; the architect was off for a day and this young and budding engineer couldn't resist sending a 3x higher man-hour estimate only to make a fool of himself.
2. A young and budding developer gate crash into a Vice President's room to introduce himself and talk about what he was working on; only to find out that his manager had already kept the vice-president well informed about the great job this developer was doing.
3. A young and budding developer seeking help and advice from a technical director ever time he had any difficulties with an implementation; only to be gently requested by the technical director that it would be good if he asked his team lead before he approached someone else.

Handling Skips

If you manage managers; or team leads; chances are that every once in a while you will see someone attempting a 'skip'. Which skips you entertain and which ones you do not; will eventually decide who thrives in your organization --- builders or whiners.

Not entertaining a positive skip of a genuine builder is seeking due credit and recognition for his work can have long term catastrophic effects on your organization or your team.

Entertaining too many 'skips' or encouraging them as a general practice; can be equally catastrophic and destroy the very team spirit that is the secret sauce for success of your organization or your team.

I cannot give you rules to help you decide which skips you should entertain and which you do not; but every time I see a manager exploiting his team; I feel like gently nudging a member or two to exercise a 'skip'.

Every time I see a Fred; who isn't seriously a kickass builder himself; trying to exercise a 'skip' on his capable manager; by giving me details of every single line of code he wrote --- I cringe.

Skips are powerful tools; use them wisely and teach your team to use them wisely.

How many examples of skips have you seen in your professional life?

How many of them have been positive and how many of them have been negative?

Have you ever felt the need to exercise a skip yourself; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

A few months ago; we announced open sourcing of Crux; an application development framework and a lightweight workflow engine rolled into one; build on the .NET platform. If you want to know more about Crux; you can read more about it here.

Since it's birth and since we posted the initial code base that we wrote; the Crux development team has been putting in quite a bit of effort to roll out some fairly interesting features.

Here's a list of some features that you can try out today by grabbing a zip of the latest copy of the code base:

Application Injection

Crux is supposed to give you the basic framework to build applications on top of. A basic virgin deployment of Crux pretty much looks like this:

With Application injection; we make it easy for you to extend Crux without having to modify it's core or without having to modify the crux-code-base. By uploading one folder with custom ASP.NET pages and a single configuration file; you can extend Crux and inject your own application into it. If your application contains multiple modules or navigation items each one of them show up on crux as soon as your application in injected into Crux.

How this is different from multiple Portal frameworks out there is that while you inject Portlets into your portal; with Crux you will be able to upload full blown applications built using standard ASP.NET.

Currently you can inject just one application per Crux instance but we are working on features which will allow you to inject multiple application on Crux instance. We are also working on making Visual Studio Templates which will allow you to click File / New / Project / Crux Application - using Visual Studio - and start writing code for your custom application.

The idea of application injection is critical to the adoption and growth of Crux because we have multiple teams within eFORCE using Crux for their projects now and we want to allow them to upgrade the underlying version of Crux without impacting their own application.

The idea of application injection into Crux also becomes important because one of our ultimate goals is that developers outside of eFORCE should be able to build Crux applications; package them; share them with the rest of the community or even sell them if they want to.

We will be working on packaging this feature and will be giving you features to upload zipped installations of Crux-Applications into Crux using a web based user-interface which the Super-Administrator can use to upload Crux-Applications in later releases of Crux.

Extendable Dashboard

While the ability to inject applications into Crux is fine-and-dandy there are times when our project teams using Crux want an ability to extend existing crux screens (we call them dashboards). Here is what a typical dashboard looks like:

With crux you now have the ability to extend these dashboards and map them to parts of your injected application without touching the crux-code base. The application that you inject can contain configuration which allows it to add items to and extend the existing dashboards inside crux:

The same feature also allows you to create completely new dashboards inside of Crux without writing any code.

Other Features

Additional features we have added include Internationalization and the ability to create and manage your own roles instead of being satisfied with what Crux gives you. These came in as patches which have been reviewed; slightly modified and applied into the Crux code-base.

Crux has already seen multiple successful implementations at eFORCE.

The development cycles are fairly fast and we are adding new features.

We have not yet tagged Crux as 'version 1.0' and are going to be leaving it in pre-beta stage for a few more weeks; but we would encourage you; dear reader; to go grab the latest copy of the code base; play with it and send us feedback.

More features; posts and training videos on Crux will be rolled out as we move forward.

We will also be announcing more open source goodness around crux soon --- stay tuned.

The First Baby-Steps At Prickdom.

You've hired a young and budding engineer and made him a part of team of genuine builders.

This young and budding engineer; who for the purposes of this post we shall refer to as Jack; is serious raw talent --- gold waiting to be polished. He is working hard; putting his sweat and mind to what he does.

He is slowly becoming the young and budding rock-star of your team.

Jack earns his first round of salary hikes and promotions.

You are starting to feel a little proud of your pick; the rate at which he is growing within your own team and your organization.

Then; something creepy happens.

Things change as far as Jack is concerned.

Not the quality of his work.

The quality of his work is just fine.

He is still amazing as far as his work is concerned; but hidden admist the layers of complicated human behavior; you find that Jack has suddenly lost the innocence and the X-Factor that made him a rock star in the first place.

Slow subtle chances are becoming noticeable.

You are starting to see Jack have minor issues with people in his team.

Ego-tussles; really small ones --- sometimes with other developers; sometimes with with the office administration and HR guys.

An email or two where he criticizes and demolishes someone in his project team for their mistakes in front of everyone else.

The reasons could be numerous; but Jack; dear reader; is taking his first steps baby-steps to becoming a fully-qualified-asshole.

Professional Puberty.

Personally; I like prefer calling this process -- Jacks-Professional-Puberty.

Much like puberty --- professional puberty is process when a lot of confusing changes happen to people.

Take Jack's case; for example. During his professional-puberty Jack is delivering; he is becoming successful and to add to it; he is starting to get a sense that he is 'important' without having any true idea of the level of his importance in the larger scheme of things.

Professional puberty is a hard time; that most engineers or veteran engineers go through in their lives. Most people act really stupidly in this phase of their time. Even I did.

Here is the sorry part however --- a very few of us who go through the phases of professional puberty emerge as better human beings. Most others; turn into regular assholes and pricks that flock our world under fancy titles and designations.

Asshole Not Allowed.

How your environment deals with someone who is going through their professional puberty will to a large extent define the kind of culture that eventually prevails at your workplace.

When a young and budding engineer takes his first step on the path of prickdom do you have veteran builders who can confront the issue head-on or does your organization avoid the issue; hoping that the issue will fix itself?

Does your environment have experienced veteran builders who can help Jack grow out of his professional-puberty into a better human being?

Does your environment have builders who are experienced and strong enough when it comes to getting straight to the bone and explaining the No-Asshole-Rule to Jack in terms which are simple and clear.

If change in attitude not happening after continuous efforts; is your organization; strong enough to pay the price and gently nudge Jack out of the organization; or does your organization take the safe-mediocre path of tolerating assholes just because they are rock-stars at what they do; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Where Saying 'No' Is An Option.

Do you know who the 'idea man' in your project is?

Usually this is going to be a manager who doesn't do any real work or a business analyst who doesn't do any real or even un-real work.

Identifying the idea man is easy:

1. Idea man does not like to be associated with one project for a longer duration.
2. Idea man is bubbling with ideas that he 'thinks' your clients 'must have'.
3. Idea man understands the culture chart and knows the people high up in the pecking order well enough to pull a few strings and get his  ideas of '(not so) nice to have' features or suggestions magically transformed into 'must have' requirements overnight.

Now; the idea man might work with multiple motives; some of which include:

1. Working for the best interest of the organization and the client ---  You may have click the link to capture the underlying tone of sarcasm here.
2. Desperate attempts of finding his place in the larger scheme of things --- and an inability to find healthy ways to over come his insecurities.
3. Showing those pesky programmers their real place.

One of the major thing that differentiates a remarkable environment from a mediocre one is the number of strings the idea-man can pull on genuine builders and story-tellers.

Joel Spolsky's rather famous post on the topic; where he talks about his experience of being attacked by a bunch of these idea-men as a manager on the excel macro team; is rather fascinating. Joel uses his post to tell a fascinating real story:

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.

I asked around. Who's the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.

"Blah blah!" said one of them. "Blah blah blah, blah blah blah!" said another. I don't think they quite had anything interesting to say. They were very enamored of the idea of sub-classing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, "Well, this is all very interesting. What's next? Who has to approve your spec?"

I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec.

The same story describes the whole string pulling exercise which is a rather common trait amongst idea-men:

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him.

Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?)

My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

Joel effectively goes on to describe what made Microsoft a special environment to work at in the very same story:

I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office -- I knew who he was, of course, but didn't expect that he knew me very well. 

"How's it going, Joel?" he asked. "I hear you've been having some issues with the App Architecture group."

"Oh no!" I said. "Nothing I can't handle."

"Say no more," he said, "I understand." He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.

While the story is a fascinating example of a work environment where eventual builders are given room to maneuver it is also an interesting case-study of what results in the development an environment where genuine builders who indulge in the act of building stuff can flourish and innovate.

If you've been in the business of building software for any period of time; you've probably found yourself demoing your product to the-idea-man.

The idea-man is usually not an involved client; he is not a regular user; he is not even an active team member --- because all three of these require time and commitment and a typical idea-man has neither time nor commitment.

Chances are; that the idea-man will not even log-in in to your application after you are done with demoing your application to him --- but based on his infinite wisdom and experience --- he is going to leave you with a few ideas that your 'absolutely must' implement.

Once you spot an idea-man; be informed; that he will pull any strings he can to get his ideas implemented.

When that happens:

Does your work environment leave you with no other option besides; dealing with the idea-man diplomatically?

Do you have enough genuine builders or story-tellers around you who are masters in the art of sedating monkeys and getting them out of your way?

Is saying 'no' even an option in your environment; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

 Following The Rules Vs. Acting Responsibly And With Passion.

If you have been a reader for this blog for any period of time; you probably know how much respect I have for Processes and Rules.

On one hand; I detest nine-to-five organizations with rules or policies for everything.

On the other hand however; when it comes to my own project; I spend countless hours tweaking my code; fixing the casing of my variable names; measuring lines-of-code-per-function; constantly looking the cyclomatic complexity of the functions; desperately trying to bring the complexity down and indulging in dozens of other painstaking exercises which might sound un-necessary to a young and budding developer.

I even push the idea of constantly following 'DRY' and 'YAGNI' --- sometimes a little too strongly to disappoint others.

Isn't all of what I do in my projects a classic illustration of me contradicting myself?

Am I not going against the very core thought-process of having little or no respect for rules?

While I go out there; comment and claim that contradictions do not exist; isn't my behavior on my projects a classic example me contracting my own thought-process of having very little respect for rules and the status-quo?

Of-course it is not.

Allow me; dear reader; to put my point across to you using a rather inspiring post written by Jurgen Appelo.  Jurgen describes the idea of following rules using the example of driving. He explains:

I love driving my car. It’s a male thing, I suppose. It’s somewhere in my Y-chromosome. I embrace every opportunity I can find to hop in my car and start driving.

And (like every other male on the planet) I think I’m a good driver.

You see, I always watch the other cars around me on the road. When changing lanes I check all sides and mirrors. My distance to the cars in front of me is enough to allow for occasional extreme speed reduction.

I match my speed with the weather conditions. I play music in my car (loudly) but I don’t wear headphones. I don’t use my mobile phone while driving. And, as far as I can tell, I am the only person in the world who is able not to cross the lines that mark my lane while taking a curve to the left or the right.

I have adopted this behavior myself.

I might have copied some stuff from other people, but it was my choice to learn these rules and use them, always.

Jurgen illustrates the difference between following-the-rules and acting-responsibly. He explains:

Only thinking and talking about something doesn’t make it so. Just like making up official rules won’t turn your business into a success, traffic signs won’t make you a good driver.

In fact, I often don’t notice many of the signs.

It is my attitude and actual behavior on the road that makes all the difference.

Craftsmanship is something agile doesn’t introduce by itself. And just thinking and talking about it doesn’t give you successful projects.

Managers who want better results must acknowledge that they have to actively change the attitudes and behavior of their people. They must stimulate craftsmanship and discipline. Or else...

Or else accidents will happen.

They say changing people's behavior starts by giving them a good example. So let the world know that yesterday night, while many people were watching the Champions League Final, I myself was learning how to do test-driven development with Python.

I hope to have inspired you.

If you live in the same planet as I do; you will be given rules at every step and corner of your personal and professional life. Every time you are given a rule; you can do multiple things with it. You can follow it; question why; bend it; tweak it; work around it or sometimes even break it outright blatantly and shamelessly.

Remember; what you do with your rules will *not* decide anything --- your attitude; passion for what you do; wisdom; competence; ability-to-make-good-judgment-calls and responsible behavior will.

Go break the rules that don't make sense to you and make new ones that do.

If nothing makes sense fly free --- but flock responsibly.

I wish you good luck.

Stupidity Is Not Always Loud And Clear.

Of all the seemingly harmless things that destroy projects in general and organizations in particular; thoughtless optimism mixed with wishful thinking is one of the items that tops the chart. Every year countless startups fall flat on their face and every year new startups with more thoughtless optimism replace them.

The amazing story of the shut-down of fly-clear by Joel Spolsky is a classic tale of thoughtless optimism gone wrong. The story is Intriguing of multiple fronts. The first front is the actual service that fly-clear was providing; which Joel describes rather well. He explains:

Here's how it worked while it was in business. You paid $200 for a one-year membership. You underwent a big, complicated background check to prove that you were extra-super-trustworthy.

In exchange, in a few big airports, you got to skip to the front of the TSA line for screening.

Now, you didn't skip the screening itself. You still went through the X-ray machine and had to remove your shoes, belt, pocket contents, laptops, and plastic quart zip-lock bag of toiletries.

You just got to cut to the front of the line.

A few people signed up. In certain airports, it was, indeed, worth actual money to cut to the front of the line.

This wasn't Clear's actual business plan. The actual business plan was that Clear would do detailed background checks on travelers, who would then be trusted to bypass security completely because they were extra-super-trustworthy

When TSA rejected the whole idea of skipping the security check and only allowed fly-clear users to just move to the front of the security check line; still leaving the requirement of a security check mandatory; Clear continued with their initial plan --- which was to charge money for their service and continue to do detailed background checks on all their users before they registered them.

Joel describes the stupidity rather articulately:

At this point, and here's the interesting part, at this point, a rational businessperson would say, "Well, does the Clear idea still make sense if we can’t actually let you skip the screening?"

OK, maybe it still makes sense to charge to skip to the front of the line. Maybe there's a business model in that.

In that case, though, why did they still do background checks? It doesn't make any sense.

The environment changed. It turns out that Clear's business model of prescreening wasn't going to be possible. But they kept doing it anyway. What kind of organizational dysfunction does it take to completely ignore the changed circumstances and keep at a money-losing business?

Joel ends the post with a note of wisdom and sarcasm:

What's even funnier is that Clear could probably have been profitable if they had just skipped the one unnecessarily stupid part of their business model: the detailed background checks on all their customers.

Nobody at Clear did any thinking.

They had a business model, the business model wasn't actually possible, everybody knew it, and they still plugged away at it. Thoughtless optimism. I don't know whether to salute them or laugh.

I find these stories really fascinating because based on the little facts that we as outsiders are privy to; these stories allow us to do black-box-investigations into huge colossal fu@#kups-ups orchestrated by smart people who had the means and the measures to organize fu@#kups of this magnitude.

Joel does his fascinating and thought provoking analysis of the story and comes to a simple logical conclusion --- Nobody at clear did any thinking.

Take that analysis one step forward and you realize that thoughtless optimism in real life; isn't as simple as a team of lousy-thoughtless-bozos coming together; moving into a dark cave and writing random software after they have lost all touch with reality.

Put simply; thought-less optimism is a slow process that happens over time; and by the time it takes it's toll on your organization; your organization; in all probabilities; has already lost the sight of the stupidity that surrounds it.

While it is easy to conclude that everyone working at Fly-Clear was a bozo indulging in thoughtless optimism; my guess; is that like any other typical startup out there Fly-Clear had its bunch of builders, story-tellers and whiners.

Now; if you assume that Fly-Clear was a decent startup like any others with an idea and an implementation --- it makes you wonder what got them from the great-fun-filled-start-up days to a miserable shutdown.

Multiple possibilities exist.

Maybe the leadership at Fly-Clear was too arrogant to consider the idea of surrendering; giving-up and starting something else.

Maybe they started off with smart and talented employees who lacked the spine to come out and announce that the king was in fact, naked.

Maybe the young and smart employees in the corridors of Fly-Clear spoke their mind but then decided to hibernate while the folks higher up in the pecking order could not care less.

Maybe just one senior vice-president high up in the pecking order at Fly-Clear believed that he could still get TSA to agree at skipping the security checks and then all those background checks they did would suddenly become appropriate.

Sometimes you need a team of monkeys to turn a project into a failure or shut-down an organization; sometimes; just one monkey left un-sedated is enough to bring an organization to a shut-down.

Maybe it was just mitigated speech and complete in-ability to accept; that the whole idea of continuing background checks; even after TSA refusing to skip the security check; was; as a matter of fact; fu@#ked up that brought them where they are today.

Maybe; and here is the creepy part; maybe it was all of the above in small dozes which were barely noticeable.

While it is easy to read stories of failure and discard them as --- Oh-they-were-stupid-we-are-not --- why these stories of failure with very little forensic evidence to base your analysis on; are still useful --- is because they show the level of fu@#kup-ups some decently intelligent teams; sometimes even having a few really smart people; are capable of orchestrating.

Remember; the problems that eventually cause your project or your organization to fail are much more subtle than we think.

Every time you read a story of failure; take a deep hard look at your organization; your team and your project.

Random acts of stupidity might be happening; really slowly; around you; right now as you read this.

Being consciously aware of the fact and knowing that a fu@#kup as big as some of these glamorous fu@#kups could be cooking right in the corridors of your organization is your only chance at avoiding these fu@#kups.

When you are on the look-out for stupidity in your very own project, team or organization; keep your eyes open dear reader; because total random stupidity is not usually very loud and clear.

It all begins with one isolated act; and then it grows from there --- usually in small doses and unannounced till it becomes big enough to cause your entire organization to go-down; without any prior warning.

Next time you look around you and see what is going on in your project, team or organization; keep your eyes open; really wide.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.