If there is external factor that I've seen destroy organizations and careers, preventing, whether it is individuals or teams, from doing things which are remarkable and having fun, it is --- distraction.

Paul Graham, in his list of thirteen things that he wants to tell each startup warns startups against distractions:

Nothing kills startups like distractions. The worst type are those that pay money: day jobs, consulting, profitable side-projects. The startup may have more long-term potential, but you'll always interrupt working on it to answer calls from people paying you now. Paradoxically, fundraising is this type of distraction, so try to minimize that too.

With 'business propositions' from three different individuals and three rather tempting job offers in last year alone, for someone like me, who isn't even looking for business propositions or random job offers, distraction definitely seems to be one of those things that is not that easy to avoid. Paul Graham, while talking about disconnecting distraction, explains this much more articulately that I will be able to explain it:

Procrastination feeds on distractions. Most people find it uncomfortable just to sit and do nothing; you avoid work by doing something else. So one way to beat procrastination is to starve it of distractions. But that's not as straightforward as it sounds, because there are people working hard to distract you. Distraction is not a static obstacle that you avoid like you might avoid a rock in the road. Distraction seeks you out. Chesterfield described dirt as matter out of place. Distracting is, similarly, desirable at the wrong time. And technology is continually being refined to produce more and more desirable things. Which means that as we learn to avoid one class of distractions, new ones constantly appear, like drug-resistant bacteria.

But distraction isn't just about technology. Distraction has an uncanny ability to morph into multiple forms and disguise itself before it strikes you and your rather fun filled life which is moving in one direction. If you are a programmer or involved with the craft of building software, this post, dear reader, is my humble attempt to present to you multiple forms of distractions which might be working on keeping you from doing things which are 'remarkable'.

May I suggest, dear reader, to use this list as a reality check of just how many distractions you have in your work life and decide for yourself if those distractions might be preventing you from coming out with results that make small dents in a large universe.

Distraction #1 - Television And Technology.

Seriously. There are dedicated posts and entire sites dedicated on this topic and how big a distraction these are. Television, video games and random social networking websites are the single largest distraction to programmers that I've ever seen. Wasting countless hours writing on the scrap book of your class two friend, now barely an acquaintance, might be a really healthy way to pass your time but does not get anything done in the long run.

If you've seen your Yahoo messenger and email notifications popup as you try to focus on getting some real work done, you probably do know exactly what I mean.

Television and technology that is addictive and disturbing is nothing more than a random distraction.

Distraction #2 - Job Offers And Business Ideas.

Last year alone, I was given three fairly tempting job offers without even applying. More than three groups of people, including a medical teacher, wanted me to hear him out, listen to his business proposition and give 'due thought' and consideration to his business idea.

Considering job offers, listening out business ideas and giving them 'due thought' is mentally stressful and distracting, particularly when you are settled and moving in one direction where your life seems to be taking you naturally.

Unless you have genuine problems with your work-life, try to find a second home, away from home and settle down. Then gear up for some real work. This stuff is supposed to be fun; and every job change demands you spend another six months to a year, to get people around you; get people to respect you and get people give a rat's ass about what you think or have to say.

In any organization, irrespective of how awesome or kick-ass it is, it takes time to create room for yourself, get people to listen to you, give you freedom and trust to maneuver. Earning this trust and room to maneuver is a 'means' towards products and outcomes which are remarkable; it's not an end.

If you've been lucky enough to have found an organization that gives you trust and room to maneuver; stay put and utilize your time to create long term win-win situations for your own career and your organization. Jumping from one job to another in these cases, is nothing more than random distraction.  

Distraction #3 - Travel And Changing Cities.

When you begin you career as a young and budding consultant, travel seems like fun. You get to see new places; meet new people and learn from different cultures. After you've done a decent amount of learning that is necessary for your life; travel quickly becomes a major distraction. Hotel suites and plane flights are not the best places to give focused effort towards what you love working on.

With a home and family, you build a support system so that you can focus on doing whatever-it-is-that-you-love doing. Constant travel takes that support system away faster than most consultants think.

Settle down. Focus. Work. Avoid travel. Do it only if you 'have to'. Travel, is nothing more than a random distraction.

Distraction #4 - Taking 'Help' A Little Too Far.

If the can-you-help-me-fix-my-machine-this-weekend questions sound way too familiar to you, you might be vulnerable to distractions. There's nothing wrong with helping as long as you can draw your lines and know when to stop.

A couple of months ago, for example, I received a call from an acquaintance who hadn't called me in the past three years. Thing gentleman wanted me to help him with his inventory control only to find out later that he was expecting me to design and build an entire freaking system for him under the banner of 'help'.

As much as you would like to be nice to everyone, especially, your child-hood friends and acquaintances, it is a sorry fact of life that the kind of people who make you feel like wearing that no-I-will-not-fix-your-computer t-shirt all the time, do exist on the same planet as we do.

There is nothing, I repeat, nothing wrong with going out of your way to help others; but knowing when the expectation of 'help' is being stretched a little too far and knowing when to stop is equally important.

Help, taken a little too far is nothing more than a random distraction.

Distraction #5 - Hot Technologies Out There.

Everyone has a product which will change the world and every product out there fits your need and your requirement; but that doesn't mean you need to care.

Yes, cloud computing might be the hottest freaking technology out there, but for your own sake, figure out how much relevance it has in your life, your organizations life before you start spending countless number of hours on it.

Not to single out just cloud computing, we spent some amount of time doing a small project in Windows Workflow Foundation; the next time on when we needed simple long running workflows, we just built a small XML based workflow engine to give us everything we need.

Just because a technology is 'hot' and it's 'out there' the experts, for obvious reasons, will exert some amount of pressure on you and make to believe you really 'need to' spend time on learning it. Time spent learning tools and technologies that have no relevance in your life, what so ever, at the cost of being mediocre at your core competencies, can be devastating for your career in the long term.

Resume Driven Development is harmful; not just for your organization but even your own career. It is in fact, nothing more than a random distraction.

Distraction #6 - Generalization Taken Too Far.

This might sound paradoxical to my advice of becoming a one man army but it's not. Turning yourself into a 'generalizing specialist' is good; but not knowing when to stop and forgetting what your core competence; in order to achieve generalization is stupidity.

When you are consulting; and you have Oracle certifications, your continuing with Oracle projects, especially when they are billed at a higher rate, might make much more sense to your organization than it might make sense to you. After I did my Oracle certifications and one small project on Oracle I had to pull the plug and detach myself from Oracle Development and database administration.

For me, understanding how the oracle architecture works was a way of improving my design skills; not a career change. I had fun learning; but it was 'not' what I wanted to spend the rest of my life doing. The same of-course, in my case, also holds true for system administration, my MCSE certification and the one year part-time system administration that I did.

Being a one man army is good; but know what you love doing; and when it's time; pull the freaking plug and stop doing things which are not equally important in your life. Be a generalizing Specialist, not a multi-purpose tool.

Generalization taken too far is nothing more than a random distraction.

Distraction #7 - Meetings And Committees.

Meetings are heroin of the software development world and committees aren't just lame - they are dangerous.  I've personally been drawn in the meeting-culture once, only to realize how much time and energy it can take away out of you without even making you realize that. When you are in a meeting, you are not productive. Meetings and committees are distractions of the highest order, particularly when it comes to software development and your career.

Each one of these, deserve a post by themselves, but this is not a post about these specific distractions.

The list is, indicative but not exhaustive.

Some of you, dear reader, may not even recognize these distractions as things that might be doing you a disservice. They may be intertwined with your life, but remember, if you are indulging in them they 'are' consuming more time and energy from your life and preventing you from doing what you really love doing. They might be wasting much time out of your life than you think.

Take the Steve Jobs approach to life and figure out the things that you would do if you were going to die tomorrow.

Everything else is a distraction; treat it as such and give it as little time and energy out of your life as necessary; leaving you with room, time and energy for what you truly love doing. Avoid time and energy drains.Then go out there and do what you truly love doing. I wish you good luck.

Living by my philosophy of putting myself dangerously close to getting fired; sometime late last year; I ended up taking the task of working as a single programmer on a product which had been estimated to require five programmers.

Put simply, it was an 'inventory tracking system' for one of our clients involving complex workflows. Besides having client specific requirements the part of the product that we at eFORCE owned consisted of modules which could serve as building blocks for quite a few other typical web applications.

Because it consisted of the fundamental building blocks that any web application might need, we decided to call it Crux.

When we had implemented the project using the core of the product, ended we played around with the idea of open sourcing the code base of  the base framework. We did this primarily because we believed that what we had; might be able to help other developers and organizations around the world get jump started with their web-application. 

If you've worked in a typical software development shop and have ever tried to get a piece of code for one of their products,  you are working on, to be open-sourced, because you believe it will 'help the world', you probably know the reaction. It's like dropping a dead rat on the conference table in the meeting room.

Your managers and executives will probably look at you like you're an alien with a third eye when you utter the words - 'open source' and the product name that you built for them in the same sentence.

That is exactly where working in an organization that's not a 'typical software development shop' and genuinely values in innovation and collaboration helps.

When we started talking about open sourcing Crux, I was pleasantly surprised at the level of support and understanding I received from everyone whose approval I needed to get this thing out to you, dear reader.

We got this thing open-sourced, froze on the New BSD license which gives you complete freedom to use the code for commercial purposes without any restrictions. We got our very talented graphic designer to work on the skin for the open source version. We had a couple of rounds of code review done by a couple of fellow programmers and were able to get a build rolled out to you, dear reader, in virtually no time with zero meetings and zero committees. 

We've just finished publishing Crux on CodePlex. It's a fully functional release ready sprint but we're going to start by calling it Pre-Beta; primarily because we would like to take some more feedback from you, dear reader. During this time we would like to have room to maneuver for relatively major changes to the database and the code-base if needed.

Crux by it's very nature is composed of multiple pieces which allows you to jump start with your Web-application using it as a foundation. Alternately, you can take individual modules or DLLs out of the Crux implementation and decide to use them individually. This post describes some of those components. Going ahead I will be working on more posts and videos on each of these individual components.

A multi-tenant authentication piece

Crux authentication, unlike ASP.NET membership supports multi-tenancy and allows drawing boundaries between multiple companies which can be hosted and authentication by the same instance of the application. 

A light weight workflow engine

Windows Workflow Foundation is great; and I've myself used it in areas requiring some complex workflows; having said that, I think it's not for a typical simple web application needing basic long running workflows with human intervention. We needed something really light weight which allows us to do simple configurable long running workflows which require human intervention e.g. approval or rejection at every step, very easily without going to a huge learning curve.

Other Pieces A Typical Web Application Needs

We have a Model View Presenter Implementation, a centralized logging piece, a centralized exception handling piece etc. These are pieces we believe all good web applications should have.

We also have a fully functional administration module with a user interface which allows you to create users, assign users to companies, departments, roles etc. Things we believe most web applications end up building with or without membership controls.

Extending the behavior or injecting different behaviors into this administration piece depending on your needs and requirements is also fairly simple. 

Going forward I will be doing a series of posts on how you can use Crux to jump start your projects and applications and we at eFORCE will also be coming out with its official website soon.

I'm also planning on using Crux as a base code base for my code related posts in future so that I can learn how to code better and share my experiences with you dear reader, using an alive codebase rather than lame examples. This blog now has a separate category for Crux related posts which you might want to follow if you are interested in the development of this framework.

The Technology Stack

Crux is built using .NET 3.5, LINQ to SQL and SQL Server 2005 or SQL Express 2005.

Ways To Participate

If you're going to be working on a typical ASP.NET web application that requires multi-tenancy, building an administration piece and involve simple manual workflows I suggest giving Crux a quick test-drive before you start hand-coding these pieces yourself.

We at eFORCE, are also working on getting a team of very talented programmers and one graphic designer, to work on this project during their free time so that you can continue to get upgrades and more features in future.

Feel free to download the code from the CodePlex-svn, play around with it and if you come across bugs, feel free to file them on the project issue tracker. Feel free to file in feature requests, any problems you might be facing with the code base on the project issue tracker as well.

Feel free to email me if you would like to participate or contribute in Crux development and make a very small dent in an unimaginably big universe.

Special thanks to the following folks in the Crux team, in no particular order, for their time, efforts and contributions: Anshuman Srivastava, Esha Patra and Amit Ghosh. Thanks to Sujith Nair and everyone else at eFORCE who has been a part of  the open sourcing decision for Crux. 

More applications, tools and frameworks to come out soon.

Stay tuned for more open source goodness.

What is worse than a meeting where everyone sleeps while the meeting-man talks?

A meeting where everyone has a different opinion, everyone talks and everyone is busy being nice to one another.

If that picture from Don't Make Me Think by Steve Krug looked familiar when you glanced through it, and it felt like deja-vu; it is probably because that is exactly how a lot of critical user interface, software development and sometime even organizational decisions are taken in a lot of places.

During a recent conversation with an individual, while talking about his company, he ended up describing the whole idea; co-incidentally; but much more articulately than I might have explained it myself. I might not be remember the discussion to the minute detail of every thing that was said to be able to quote it word for word, but here is how it pretty much went:

Individual: You know, in general I have nothing against my company; we are all amazing individuals working really hard and doing all we can do to get the right thing done or the right decisions taken; but every time it looks like something is going to work out really well, we work hard; collectively; as a group, to screw things up real bad. Me: Interesting. Am I allowed to use that sentence on my blog? Individual: Sure. Why? Me: It's an interesting sentence. You might read this sentence again on my blog; sometime soon. Seriously. Individual: Sure. Go ahead. Use it.

The whole a-group-of-really-nice-people sitting in meeting rooms and screwing things up seems to be a recurring theme that happens to manifest itself again and again, so many times that you start to question, if there is something fundamentally wrong in the idea of getting things done by perfect consensus.

Turns out, that there are times in software development when 'Committee Driven Development' as we shall call it, starting today, is down right in-effective. Scott Berkun in his presentation on how progress happens describes how democracy is bad in software development:

Committees by definition prevent change. The whole idea is to try and get consensus and consensus will always lead towards mediocrity because you are averaging out decision making. So one of the most interesting stories to me about Rome; this is a picture of the emperor Constantine. [picture of Constantine on a projector] He was a later emperor and one of his claims to fame... if you remember the early history of the Christians in Rome; they didn't like the Christians so much; like the whole 'throw them in the lines thing'… that is not a story; that was true. There are catalogs of all the things they would do with Christians and Jews and slaves and other things. There were hundreds of years of horrible treatment for Christians; and then one day Constantine decided - 'You know what? We should be nice to Christians'. Boom! Edict of Milan, believe it was called. Edict of Milan. And now, next day, everyone's nice to Christians. Boom! Like that. That could never ever, ever, ever happen in a democracy; ever. It's designed to prevent that from happening. But if you're talking about change and I'm not really trying to get into a debate about political structures and tyranny and what not but if you are talking about change; autocracy and solidified centralized power is actually a much more effective way to make immediate change happen.

This opinion from Scott  might be subject to a lot of criticism, by people who are firm believers of democracy, but anyone who has been in a meeting where a bunch of people, having equal or similar power, just cannot get to agree on anything, knows exactly what Scott is talking about.

'Power' by it's very nature is something that sounds like a thing the micro-managers crave and the ones who are into the modern-management, shun; but power itself, is neither good nor bad. In the ideal world power is supposed to be just a quality which enables you to get things done. That's what we mean when we say - you're-being-empowered-to-do-this - It is invariably handing power in the hands of people who crave for it the most, that results in disastrous situations. 

Where most organizations tend to miss out on, is finding the right Constantines who are capable and will indulge in using this power to bring about meaningful change. Quite a few organizations often fail at trusting these Constantines after they have been found, simply because they lack trust. Trust, is indeed, a difficult thing to give to your employees after all. 

People in favor of democratized software development often tend to cite open source projects as an example of development by mutual agreement and consensus; but anyone who has been associated with open source for more than a day knows how the function of a gate-keeper and how important it is to the success of any open source project.

Recent discussions around GNOME user interface that a small team changed, without the community consensus, and then presented these changes back to the community, forms an interesting read. The explain their stand while presenting the final changed to the community:

Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design ("you can't make the panel menu depend on beagle!!!") and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells "fork" deserves to get one stuck in them.) An equivalent answer to the question is "because you can't do design by committee". Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be.  This is just another aspect of the UI "simplicity" thing. We like UIs that try to do the right thing (metacity, epiphany/Firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee.

In the same discussion, the developers submitting their changes, thrash the whole design-by-committee approach rather ruthlessly and end up with a conclusion the individual I quoted at the start of this post had landed up with. The developers who made changes to the Gnome user interface without community consensus explain:

But some people will still say "But couldn't you have discussed it with the community before doing it?" No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with he GNOME community, it's a problem with communities in general. The wisdom of crowds [4] only works in situations where there are clear right and wrong answers. If you try to apply it to a design problem, where there are many entirely different right answers, then you end up with a wrong answer. Always [5]. So to sum up: design by committee is bad, endless debates that result in code not actually being written are bad, design by very small teams is good, software with a unified vision is good, trying out cool new UI ideas is good, free code at least doesn't suck, and of course, for Novell, not shipping NLD10 is bad. I don't think there's anything we could have done to get more of the good without also getting more of the bad.

From what you've read so far, it might sound that committees in general just prevent change from happening and slow down things. 

Committee Driven Development is definitely the sure-shot path to avoiding change. It prevents both you and your organization from doing anything remarkable; but it doesn't stop there.

I am here, dear reader, to tell you, that blown out of proportions, high volumes of overlapping responsibilities and having too many committees in place, is single handedly capable of destroying your next project or even your entire organizations faster than most programmers and organizations think. Committee Driven Development is not just lame; it's dangerous.

The next time, when you're thinking about your company, and feel that you're all amazing people, doing the right things individually, but tend to screw things up when you get in meeting rooms and talk for long hours,  maybe it's because your organization has failed at picking the right Constantine's and giving them enough power and trust to get things done.    

Your job, in some of these situations, is to see if you can become that Constantine.

Don't know how? Go read the James Shore's Change-Diary or see Scott's video on how to make change happen and prevent committee driven development.

I wish you good luck.

The idea for this post happened when a few of us sat at a local cafeteria and discussed where most ideas come from. We talked about random dreams; deja vu and other creepy things.

Some of us believed that solutions to most complex problems happen in the strangest and least expected situations; for example, when we are either asleep or about to fall asleep; having a shower or exercising.

Turns out, the funniest and the creepiest one of them all was the one factor that was common to some quite a few people in that cafeteria. Believe it or not; some of us, weird programmers; thought that we think better on a toilet seat; much more than we do when we were at our desk in those noisy crappy cubicles at offices around the world.

Now you might be knitting your brows at the mere thought of most thoughts emerging out of rest-rooms; but think about it. Quite a few ideas that you may have had; may have actually started or originated there. Quite a bit of what you read on this blog definitely does originate there.

I've grown so used to the concept of getting sudden light bulbs going on in the middle of the night, when I am about to head off to sleep, that I often keep my PDA handy so that I can email the idea to myself before I fall asleep; I like to capture the thought the next day when I get to checking my email.

We like to think that innovation and creative software development happens when people in their suits sit around in meeting rooms projecting serious power-point presentations on the wall.

Beautiful personal toys like suites and ties or professional toys like projectors in meeting rooms make us 'feel' important and gives us a 'perception' of being productive or innovative.

If you think about it though, these tools, in the real world where we live, have nothing to do with genuine innovation or for that matter being productive.

Paul Graham, in his forward for Founders At Work by Jessica Livingston, describes how successful startups work and what sets them apart from the stupid-out-sourcing-consulting-body-shops:

The effort that goes into looking productive is not merely wasted, but actually makes organization less productive. Suits, for example, do not help people to think better. I bet most executives at big companies do their best thinking when they wake up on Sunday morning and go downstairs in their bathrobe to make a cup of coffee. That’s when you have ideas. Just imagine what a company would be like if people could think that well at work. People do in startups, at least some of the time. (Half the time they’re in a panic because their servers are on fire, but the other half they’re thinking as deeply as most people only get to sitting alone on a Sunday morning.) Ditto for most of the other differences between startups and what passes for productivity in big companies. And yet conventional ideas of “professionalism” have such an iron grip on our minds that even startup founders are affected by them. In our startup, when outsiders came to visit we tried hard to seem “professional.”  We’d clean up our offices, wear better clothes, and try to arrange a lot of people to be there during conventional office hours. In fact, programming didn’t get done by well-dressed people at clean desks during office hours. It got done by badly dressed people (I was notorious for programming wearing just a towel) in offices strewn with junk at 2:00 in the morning. But no visitor would understand that. Not even investors, who are supposed to be able to recognize real productivity when they see it. Even we were affected by the conventional wisdom. We thought of ourselves as impostors, succeeding despite being totally unprofessional. It was as if we’d created a Formula 1 car but felt sheepish because it didn’t look like a car was supposed to look.

Scott Berkun in his presentation on how progress happens and 'tools for innovation' also talks about the most important tool of innovation: people. 

People who can genuinely innovate tend to use the most basic and fundamental tools at hand to come up with genuine innovation. Most of the times these tools are crude and at times they are even down right ugly. Pack a bunch of genuinely innovative developers in noisy cubicles, for example, and they will put the rest-rooms of their own homes to good use.

When we see a beautiful application we tend to glamorize its build and development process and draw our own conclusions on how the teams must have had regular status meetings and how well defined their process may have been.  What we often miss out on, is that Innovation happens in-spite of these these regular status meetings and their well defined processes; not because of these things.

When we see a product that is remarkable; We tend to visualize, guess and talk about how smart everyone in the development team may have been. Hardly do we tend to think about innovators as normal human beings, who were willing to take up countless nights of head-aches, the countless days of self-discipline and the countless small self-scarifies that any form of creativity and innovation demands.

We tend to turn a convenient blind eye to inherent ugliness and pain associated with creativity and innovation; ranging from birth of a life form to shaping of a new idea into something concrete and truly remarkable. creativity, Innovation and success usually involve a decent amount hard work and usually has a decent amount of ugliness associated with it.

Of-course in a world where most developers, bloggers and managers can't even stick to one thing for more than a couple of weeks; glamorizing innovation as something that only the super smart people can do because of their smartness which manifest itself only during work hours, sounds like a convenient way to think about innovation. There is only one problem to this approach however: innovation and creativity does not happen to be that systematic and 'beautiful'.  

The next time you see a beautiful user interface in an application; see if you can picture a programmer in the middle of the night in a towel or someone seated alone in his quite dark office, pulling his hairs out of his scalp, coding away to glory. The next time you see a decently average blog, picture a person passionate about writing, seated on his toilet seat, deeply immersed in writing; working away at his keyboard at four in the morning.

When it comes to innovation, things more often than not, get ugly.

Not a whole lot of us seem to get that though. We read inspirational posts; think of changing the world and when the ugliness starts to kick in; we chicken out; or move to something else; which; more often than not, turns out to be something that makes us feel 'safe'.

Innovation is by it's nature, is inherently ugly; It is accepting this ugliness, seeing the beauty of it and ultimately loving this ugliness that makes you innovative. Glamorizing innovativeness and taking a 'we-are-going-to-be-the-next-bill-gates' path turns you into an idiot with wishful thinking.

Honestly, co-incidentally and almost creepily, I happened to bump into this video after I had finished writing this post; but if you think my being hit with ideas or solutions, on my toilet seat or when I am just about to sleep and then working at them for hours without being able to sleep is weird, go watch and listen to Elizabeth Gilbert to see how beautiful the ugliness associated with creativity or innovation can be.

Have you ever seen a young kid play around with a box of cardboard or some paint.

Kids have an innate tendency to explore; experiment and at times end up making a fool of themselves; an ability grown ups seem to lose during the 'growing up' process.

As I talk to more and more developers, even the really good ones, I'm starting to believe that Picasso's famous quote - 'All children are born artists, the problem is to remain an artist as we grow up' - might in-fact be much more applicable to our lives much more than we think it is.

With every passing day, I find it increasingly difficult to come across young and budding developers willing to take some chances with their career and do something unconventional with their code, projects or their life. Most careers I seem to witness today usually seem to revolve around nine-to-five jobs, building CRUD screens and jumping from one job to another and one project to another.

In one of my earlier posts I talked about the fact that no sane walking, talking, human being on this planet gives a rat's ass about you; your product or your blog, unless you have something in it for them. This 'something' can be something as simple as a simple product that works a little differently, a message or a cause that takes people by surprise.

Margaret Mason for example, describes the noble cause of Heather Powazek Champ’s post; which hilariously; is to teach the world the right way to insert toilet papers in paper dispensers.  She describes this in her book 'No One Cares What You Had For Lunch' with the help of a diagram:

She adds:

When I am queen, I shall decree that all rolls of toilet paper be correctly inserted into the toilet paper dispensers. Correctly? You have all been improperly instructed to place your toilet paper with the “tongue” facing outward. This is incorrect. Why? It’s ugly. Please view the illustration above. Isn’t the arrangement in the right far more aesthetically pleasing than that on the left? But what about ease of use, you ask? I don’t give a rat’s ass about ease of use. I want the world to be a more beautiful place, and I’m going to start with your toilet paper. Thank you.

Now, you can find the post hilarious, ridiculous or even funny; but it is; in it's own way; something that can be referred to as 'remarkable'.

Seth Godin in his 'remarkable' presentation at TED explains what 'remarkable' is:

The thing that's going to decide what gets talked about, what gets done, what gets changed, what gets purchased, what gets built, is, is-it-remarkable? And remarkable is a really cool word; because we 'think' it just means neat but it also means worth making a remark about.

What you talk about, or what you work on, doesn't always have to be as grand as saving the world; but it has to end up being ‘remarkable’; much like the mission of teaching the world how to correctly insert toilet papers in the dispensers. Compare 'remarkableness' of that with posting your organizations balance sheet online or sending out marketing spam mail to customers and you'll be able to figure out why no-one is visiting your website, blog or buying your product.

Seth, has a  theory of being 'remarkable' where he defines 'remarkable' as the 'purple cow'. The idea is simple; After all when you are driving by the country side, no-one notices a white cow; but if the cow is purple; people pull over and take notice.

In the same remarkable presentation Seth proposes that the whole notion of being 'safe' and nails it heavily. According to Seth, safe is easy but in today's world that is the riskiest thing you can do to your life, your product or your blog:

The riskiest thing you can do now is be safe. Procter and gamble knows this. The whole model of Procter and gamble was always about average products for average people. That’s risky. The safe thing to do to now; is to be on the fringes; be 'remarkable'; and being very good is one of the worst things that you can possibly do. Very good is boring; very good is average. It doesn't matter if you are making a record album or you are an architect or you have a track in sociology. If it's very good, it's not going to work because no-one is going to notice it.

Kids as it turns out, are born with the ability of taking these risks and creating perfectly 'remarkable' purple cows. I'm not sure if the tie-and-the-suit takes it away from managers and the need-to-get-a-guaranteed-safe-job takes it away from developers, but when I look around, I find only a minuscule number of developers taking sufficient amount of risks.

In a world where most programmers can't program; even most of the ones who can, are busy being just 'very good' at programming. Most of the time I see developers playing it safe; not just with their life; but with their profession and even their code.

I'm not talking about quitting your day time job and going for your own startup; I'm talking about simple risks of investing your career with one organization for a decent amount of time; taking up that course on literature or psychology even if it has no direct benefit on your career; or maybe just writing your code a little differently by building opinionated software.

When you can get an internet connection dirt cheap and a hosting account for less than a few dollars a month; there are no excuses for living the life of a paycheck programmer and not participating in making small but crazy dents in the universe. The bare minimum tools of change that you might need are not expensive and you have no excuses for being just 'good'.  As the world evolves, safe is riskier by the day and being just 'good' is bad. 

Aiming a 'safe' job that gets you a higher paycheck and keeps you busy with mundane CRUD applications through out the day for example, is the riskiest thing you can do to your career. Having ten posts on your hard disk and not posting them out on your blog because you think your readers may not like them is an equally risky thing you can do to your blog. Not releasing till your code is not perfect is the riskiest thing you can do to your product.

Don't worry about being 'good' or 'safe'; be 'remarkable'; take chances.

Show us the true color of your cow; and paint like a baby.

I dare you.

Have you ever seen any young and budding blogger, who for the purposes of this post, we shall refer to as Fred, start on his 185th blog? He is as excited as a little baby who has been given a brand new toy which he thinks will allow him to change the world.

He spends hours thinking of a name for his 185th blog; gives special attention at picking the theme and spends hours doing a spanking new absolutely cool-and-happening-web-2-0-CSS-based design for the blog. Then he starts with a first post which he believes will make all his readers fall in love with his writing and make them crave for more.

This time he is firm and decided. This time he is going to write a blog which not just makes him famous but will change the world for good.  There is only one little problem however.

The 'world' that our dear blogger wants to change doesn't give a rat's ass about him.

The millions of readers who were going to love and hang on to every little word that he writes, happen to be just a little busy, doing their job, providing for their family and sometimes, even a little irritated doing chores, managing their spam mail and hanging up random marketing calls made by call centers who specialize in the act of calling individuals when they are least in the mood of accepting random unsolicited calls.

These millions of readers, as it turns out, are so darn irritated that they are not interested in buying anything; not even if it is just ideas; for which the only price to pay is just five minutes of their time daily time.

Long story shot, these millions of users, our dear blogger wants flocking on his blog, don't care; and the ones who care enough to read and listen have, most probably, found the mavens they want to listen to; and have already started trusting them for their transactive memory.

Our dear Fred, continues to blog for a month; during that one month he blogs once; twice; and then thrice, only to realize that he is talking to himself. The comment count is constantly zero. His web-site statistics aren't crossing the three 'returning visitor' count.

Google just doesn't seem to be crawling his website, no-one seems to be linking to him and Feed-burner statistics hardly seems to cross a count of five RSS subscribers, two of which are his own subscriptions; one from office; another from home.

By the third post, the enthusiasm to change the world has started stammering. Our dear blogger has swallowed his pride; but he is not done yet; after all he is not one of those who will give up. He will start again; with yet another fresh start; yet another blog, that will, one day, change the world and get him the million readers he seeks so desperately.

I cite the blogging example here because blog posts have very short release cycles. It is usually less than a couple of days from the moment the author conceptualizes the idea to the moment he publishes or releases it to the world.

Much like programming, the bar of entry for young and budding bloggers is low. In fact it's even lower than programming. Much like programmers, anyone can be a blogger; all you need to do is sign-up at a blog-spot or a word-press. Truly, blogging seems to be representative of every other thing that we usually do in the world of software development; only difference being that it's usually individual and can see a blog post's life cycle in less than a couple of days.

These characteristics makes blogging makes, observing why blogs fail, an excellent 'sampling tool' to investigate where people usually go wrong when it comes to marketing their products and ultimately their 'ideas'.

As programmers we tend to believe that if no-one is using our system or reading our blog, there 'has to be' something wrong with the technicalities and specifics of the blog. Maybe it's name isn't hip and happening enough. Maybe it's user interface is not being catchy enough. Maybe the underlying blogging framework is not being fancy enough. Long story short, we tend to believe that there are 'technical issues' which are causing our readers to not like our blog.

The same is usually true for products and systems that we build.

As developers, we are also great at bulldozing everything that we don't think is perfect starting fresh; again and again. That is what leads us to iterate the infinite loop of failure. We tend to; or should we say, 'like to' believe that if we abandon the current effort and move on to a fresh start, everything will mysteriously work out.

Anyone who has looked at the number of dead projects in source-forge, number of abandoned blogs on blogger and word-press and number of startups in f@#ked-company, before f@#ked company was itself f@#ked, knows what I am talking about here.

As Bloggers, software developers and even marketers we like to think that if we 'build' something or write about something, that we believe is great or cool, people will usually care about it as much as we do. The simple, hard and blatant fact of life is that, like experts, most human beings are creatures who work on incentives and unless you give your users or your readers, depending on what you are doing, a strong enough incentive to care, they will simply ignore you.

Why? Because it's easy for them to ignore you. They have options.

Bloggers and Software Developers taken over by the desire to save the world and save their readers or customers, forget the simple fact of life Seth Godin reiterates again and again in countless of his videos and presentations like this one. He explains:

This is so important, right, ready? No-One Cares About You. They invented television to sell ads to you. They invented radio to sell ads to you. They invented news paper to sell ads to you. That's not why they invented YouTube, That's now why they invented the internet. The internet doesn't care about you. People don't "have to" watch channel seven any more. They can entertain themselves mindlessly for hours by pressing the stumble upon button. So if someone is going to watch a video; they are not going to watch it because they care about you. They are going to watch it because they care about "me" (them). Me-Me-Me-Me-Me - my favorite person - Me. They are not going to read e-mail from you; they are going to read me-mail; because that's who they care about. So if you make a video like the Blend-tec guy, the Will-it-blend videos, people will watch it because watching Chuck Norris blend in a blender is sort of a hoot but if you make a video of how your factory is twelve percent more efficient than it was last year... (yawn)... I'm not coming.

No one cares about you; they don't care about what you had for lunch; your cat; or your favorite color; unless of-course you can talk about these things in a way that makes them roll over laughing; keeps them hooked; helps them take better care of their cats; or helps them cook their lunch better; if you can't do that, your cat, your lunch and your favorite color doesn't mean zip in the larger scheme of things.

No-one; I repeat; No-one; not a single human being; unless that human being happens to family or a loved one; cares about you, your latest blog post or the system on which you are spending your weekends. All they care about is, their favorite person; themselves.

This is supposed to be common knowledge in the world of marketing and even software development and yet I see individuals jump from one blog to another, organizations jump from one product to another and programmers jump from one open source project to another; in hope that a 'fresh start' will make their users care.

Whether you write a blog or do a project, what you are ultimately interested in doing is getting people excited about your thoughts or ideas. You are interested in sharing them with people who happen to be busy and in general, don't give a rat's ass about you or your ideas.

The only way of grabbing their attention and getting them to even remotely care about what you want to say, is by putting yourself in their shoes; and thinking about the value your work is giving them. Is it entertaining them; Motivating them; Inspiring them;  Educating them; or simply irritating them.

Adding genuine value through your work and getting people to genuinely care takes time. It requires constantly proving yourself with actions; not words. It takes time to prove that you are serious about delivering whatever it is that you want them to consume; and that you will not just deliver high quality; but that you go out of your way and will deliver constantly.

Gmail took more than three years of persuasion; friend-feed took even longer; Most authors writing inspirational posts on success tend to not even talk about the countless other applications and startups that might have died a painful death along the way. 'Overnight success' in any form usually takes a long time.

Depending on what you are trying to do it might take years. This post isn't supposed to be a motivational post which tries to come out and pamper you; pats you on your back and assumes a if-you-keep-trying-you-will-succeed tone; because we all know you may not succeed; and that, dear reader, is the whole point of this post.

Unless you yourself, are willing to stick to at-least one thing, in spite of your failures; continue to deliver; go beyond shipping; and continue that for months, without expecting any overnight success in return, expecting your users or readers to take you seriously or care about what you have to say is nothing more than stupidity.

Expecting them to believe that you feel passionately about what-ever-it-is-that-you-want-to-say-or-are-working-on, because you said so in a blog post or two or because you rolled out the first sprint of a product, is nothing more than a joke.  

So the next time you sign up for a blog, first remind yourself of this simple little fact of life: no-one cares about you; not even your very own users.

Then ask yourself if you have something interesting to say that your users will really care about. Besides asking yourself why 'you' want to write that  blog post. Ask yourself why they should care to read it. Ask your self this question; constantly as you edit and re-edit your post. Then, ask yourself this question before you publish it live.

Think of the internet as a large room of millions of on-going parallel conversations; people are fairly open to letting your participate and contribute; the rules are simple:

1. You have to have something to say that adds genuine value to the community.
2. You have to say it with conviction.
3. You have to care enough about the idea(s) or whatever it is that you are working on, to keep doing it; even if no-one is listening.

Step one, is highly under-rated and most people in the world of software development know it, but unfortunately, do not seem to 'get it'; which is why we have depressing blogs which talk about how-depressed-Fred-was-feeling-this-morning; personal-life-blog with Fred shouting at the top of his voice about how passionately feels about cats and his pet-cat in particular.

As you browse through countless personal blogs, be prepared to be amazed by how the The 'passionate interest' in cats, for Fred, usually ends in just about two posts, after which Fred decides to just stop talking, goes silent and disappears.

Huh! Wonder what happens to all that 'passion' on cats; you wonder.

Then months later Fred moves to a new blog with a new topic he feels passionately about.

If you want to talk about Cats, be a Cat maven and provide useful information on cats. If you want to talk about your depression, provide a wealth of information on how you fight your depression. If you think it's hard, take a look at Scott Hanselman, getting you involved in his fight against diabetes. There are countless other great examples out there.

Oh and by the way, changing your blog URL, adding a new theme, changing your project name or constantly changing your jobs does not result in a 'fresh start' that will magically change your life Hollywood style and make 'them' care about you.

Unless you have something concrete which you can offer to the world; and unless you can offer it consistently; I am here to tell you dear reader, the world does not care about you. Unless you can get them to give a shit by giving them enough value and genuine incentives to, you, your blog and your dream project are all doomed to be ignored like unsolicited marketing calls.

If you find that unfair; go grab a copy of Atlas Shrugged; and read it ten times over.

Technology of your hosting provider, bad CSS, your blogging framework and not having the bells-and-whittles is not your problem. Lack of features in that open source project that you might be working on, is also not your problem.

Having a cause, a message and then getting people to care about your cause, message or whatever it is that you have to say is.

Unless you can do that, you, your systems and your blogs are no better than spam mail that lands in our inbox every morning.

Now, stop signing up for that new blog or gathering email addresses for your next press release mail blast.

Go build your own tribes instead. I wish you good luck.

When you are in the business of building software; information, knowledge and wisdom that you carry in your own your head is not the only measure of how successful you are.

With software development it is in fact, the knowledge and wisdom that you have 'access to' that matters much more than how much of it you carry with you in your own head.

Malcolm Gladwell In his book, 'The Tipping Point', explains this concept when he talks about 'Transactive Memory'. He explains:

This is what University of Virginia psychologist Daniel Wegner calls "transactive memory."  When we talk about memory, we aren't just talking about ideas and impressions and facts stored inside our heads. An awful lot of what we remember is actually stored outside our brains. Most of us deliberately don't memorize most of the phone numbers we need. But we do memorize where to find them — in a phone book, or in our personal Rolodex. Or we memorize the number 411, so we can call directory assistance. Nor do most of us know, say, the capital of Paraguay or some other obscure country. Why bother? It's an awful lot easier to buy an atlas and store that kind of information there. Perhaps most important, though, we store information with other people.

The idea of 'Transactive Memory' is relevant pretty much in all spheres of personal life and work life; including your online time. When it comes to the world of software development, even though a huge number of us may not be open to the idea of contributing on the internet; we use 'Transactive Memory' all the time; while we are looking for information; and particularly when we are going to make decisions based on that information. Ever read a blog to find out what someone thought about a tool or application you were planning on buying? Ever went through Amazon user-reviews before buying that book?

Using transactive memory is exactly what you were indulging in when you were doing all of these or multiple other activities that you do online when you look for information and in particular when you use that information for making purchase decisions; online. You were depending on individuals who you did not even know personally and you were trusting them to provide you with accurate information.

When you are buying a thirty dollar book at Amazon it's easy. However,  when a part of your job includes picking tools and technologies for your organizations and most projects that are implemented in your organization, developing strong 'Transactive Memory' using sources of information you can trust becomes much more important.

As someone who is involved with making technology decisions for multiple development projects for years; I've had my share of successes and failures at picking products and frameworks to be used in projects. I've also learnt some lessons along the way quite a few of which are about building a better 'Transactive Memory'. This post is about one of those lessons.

At Multiplitaxion Inc, for example, during my early years, a client approached us with the need of having a customized user portal done. Someone high up in the pecking order at the client organization had a friend, who turned out to be the SharePoint expert.

This gentleman with his expertise in SharePoint was expected to lead the project; if it materialized. When the client approached us, the decision to use SharePoint was something they has 'defaulted to'. This decision of course, was based on 'expert advice' and they believed, in all sincerity, that it was a correct decision taken under the guidance of a true expert.

For days we struggled back and forth; trying to do a 'proof of concept' with SharePoint; the SharePoint expert helping us out every time we were up against a road-block. This guy, was amazing with band-aids, workaround, tips and tricks up. He always seemed to have some cards up his sleeves; especially every time we were going to hit a wall.

This was the early SharePoint version where if you were going to do custom development, you were pretty much stuck with writing .NET-Custom-Controls and all SharePoint did was act as a liability slowing you down in development instead of being this amazing portal framework that the Microsoft marketing folks were busy portraying it to be.

This gentleman, however, wasn't discouraged. To be fair to him; he was good; in fact he was great. He could do things with SharePoint lists that none of us thought made any sense to even attempt and he would get away with it; producing a new magic trick every time a road-block was showed up.

After a few weeks of prototyping, band-aiding and this expert of ours pulling magic tricks out of the his expert head, we decided to quit.

'Freakonomics'  by Steven D. Levitt and Stephen J. Dubner co-incidentally of-course, describes what had gone wrong with us trying to implement SharePoint in that project. We, the allied relationship of the client and us, had relied on an expert, when the best interest of the expert was not aligned with our best interest. Both the client and development team wanted a simple maintainable ASP.NET web application; this expert on the other hand needed consultancy and dependence on him.

In their book Freakonomics; Steven And Stephen provide excellent explanations on what is wrong with working under the assumption that an expert will always provide you the accurate information and work for your best interest if you pay them. In the book, Steven And Stephen describe an experiment conducted to find out if experts always work for the best interest of their clients:

Experts are human, and humans respond to incentives. How any given expert treats you, therefore, will depend on how that expert’s incentives are set up. Sometimes his incentives may work in your favor. For instance: a study of California auto mechanics found they often passed up a small repair bill by letting failing cars pass emissions inspections—the reason being that lenient mechanics are rewarded with repeat business. But in a different case, an expert’s incentives may work against you. In a medical study, it turned out that obstetricians in areas with declining birth rates are much more likely to perform cesarean-section deliveries than obstetricians in growing areas—suggesting that, when business is  tough, doctors try to ring up more expensive procedures. It is one thing to muse about experts’ abusing their position and another to prove it. The best way to do so would be to measure how an expert treats you versus how he performs the same service for himself. Unfortunately a surgeon doesn’t  operate on himself. Nor is his medical file a matter of public record; neither is an auto mechanic’s repair log for his own car. Real-estate sales, however, are a matter of public record. And real-estate agents often do sell their own homes. A recent set of data covering the sale of nearly 100,000 houses in suburban Chicago shows that more than 3,000 of those houses were owned by the agents themselves.

The experiment involved measuring data and coming to a conclusion which describes why relying on experts may not always be the best way to gather information. Steven And Stephen explain:

There’s one way to find out: measure the difference between the sales data for houses that belong to real-estate agents themselves and the houses they sold on behalf of clients. Using the data from the sales of those 100,000 Chicago homes, and controlling for any number of variables—location, age and quality of the house, aesthetics, and so on—it turns out that a real-estate agent keeps her own home on the market an average of ten days longer and sells it for an extra 3-plus percent, or $10,000 on a $300,000 house. When she sells her own house, an agent holds out for the best offer; when she sells yours, she pushes you to take the first decent offer that comes along. Like  a stockbroker churning commissions, she wants to make deals and make them fast. Why not? Her share of a better offer - $150 - is too puny an incentive to encourage her to do otherwise.

In the world of software development, especially when you are responsible for picking tools, technologies, directions, trends to follow etc. for your organization and even for your own career, knowing three simple facts is important.

1. You'll never be able to know or find out everything and keep it in your own head. You will have to use Transactive Memory and depend on 'experts' rather frequently.
2. When you are building POCs, every tool out there meets your requirements; especially when you have an 'expert' who is convinced it does.
3. When your best interest doesn't align with the best interest of the experts you are relying on; experts will cheat; most of the times they will do so unknowingly and subconsciously.

If there is one thing I've learnt, in my career as a software development it is this; don't depend individuals who are 'just' experts. If you must depend on someone for the choice of the tool, platform, technology, framework or information in general, depend on individuals who besides being decently good at what they do; are also individuals who can otherwise be defined as Mavens.

Malcolm Gladwell describes these individuals in his book, The Tipping point when talking about Mavens, Connectors And Salesmen. He explains:

The word Maven comes from the Yiddish, and it means one who accumulates knowledge. In recent years, economists have spent a great deal of time studying Mavens, for the obvious reason that if marketplaces depend on information, the people with the most information must be the most important.

Malcolm in 'The Tipping Point', while talking about one of the Mavens, further describes how these individuals, end up helping others by simply being themselves and indulging in their own nature of gathering, processing and sharing information:

At one point Alpert launched into a complicated story of how to make the best use of coupons in renting videos at Blockbuster. Then he stopped himself, as if he realized what he was saying, and burst out laughing. "Look, you can save a whole dollar! In a year's time I could probably save enough for a whole bottle of wine." Alpert is almost pathologically helpful. He can't help himself. "A Maven is someone who wants to solve other people's problems, generally by solving his own," Alpert said, which is true, although what I suspect is that the opposite is also true, that a Maven is someone who solves his own problems - his own emotional needs - by solving other people's problems. Alpert is not, it should be said, an obnoxious know-it-all. It's easy to see how he could be, of course. Even Alpert is aware of that. "I was standing next to a kid in the supermarket who had to show his I.D. to buy cigarettes," Alpert told me. "I was very tempted to tell him I was diagnosed with lung cancer. In a way, that desire to be of service and influence — whatever it is — can be taken too far. You can become nosy. I try to be a very passive Maven... You have to remember that it's their decision. It's their life." What saves him is that you never get the sense that he's showing off. There's something automatic, reflexive, about his level of involvement in the marketplace. It's not an act.

Anyone who has seen Life-Hacker, Scott Hanselman's Tool List, Scott Guthrie's direct and straight forward elaborate posts on technology Microsoft is working on or seen Rory criticize Microsoft when they make lousy mistakes, while retaining his full time job at Microsoft, knows what Maven-ship is; of course there are countless other examples of true and genuine maven-ship out there.

If you look hard enough for Mavens who are genuinely trying to help by collecting, processing and then distributing accurate, honest and true information; you will find them. Another way to spot them, is that unlike experts, who primarily work on information and see all information that benefits them as 'good', Mavens have an ability to form strong personal opinions about information they gather.

Pick a few Mavens; follow them through their blogs or website for a few months; see if your opinions align. Scrutinize their posts. Are they are making the right judgment calls that work for you most of the time? If your answer is yes for a particular Maven, you can use his knowledge or effort and make it a part of your own 'Transactive Memory'.

Months ago, for example, when I was asked to go looking for a static analysis tool to suggest at work, the nDepend official website was not the source of information I wanted to base my judgment on; I had tried the product and was happy but with; but when a third person who I know to be an honest maven talks about it and helps me get started on it, that is often the personal tipping point for me; something that results in a buy. 

Coderush is another example where multiple Mavens have got me introduced to the product without any hidden interest or incentive; ultimately resulting in me recommending the buy and a license getting purchased.

The list is endless but what is common in the list is that I would say I've never been disappointed with any of my purchase, downloads, recommendation-to-my-organization or recommendations-to-a-client; when the information used for the recommendation, purchase or download was from a genuine Maven I already trust. That, for me at-least, speaks highly of the power of 'Transactive Memory' used correctly. On the other hand, any software purchase or download that I've done based on an 'expert opinion' has turned out to be a lousy decision more than once.

You can take an expert opinion;  but the opinion would be correct only as long as the interests of the expert who is giving you the opinion align with your interests. When given the choice between the Maven and an expert; especially when you are picking sources for your 'Transitive Memory'; irrespective of how talented or awesome the experts you have access to are; don't depend on them.

Look for the quality of maven-ship in people instead. Depend on people who demonstrate that quality and then form your own pragmatic opinions based on theirs. I wish you good luck.

If your manager behaves like an angry tiger; chances are that he is putting up a mask; behind which, lives a timidly scared and insecure individual.

Scott Berkun describes this type of insecurity as one of the ten primary reasons why Project Managers And Development Leads become assholes. He explains why managers often act like assholes:

They are insecure in their role. The psychology of opposites goes a long way in understanding human nature. Overly aggressive people are often quite scared, and their aggression is a pre-emptive attack driven by fear: they attack first because they believe an attack from you is inevitable. Management makes many people nervous since it’s defined by having have less direct control, but more broad influence. A huge percentage of managers never get over this, and micromanage: a clear sign of insecurity and confusion over their role and yours.

Insecurities manifest themselves in multiple forms but the most serious form I have witnessed till date is the fear of becoming redundant. Most managers who are not from development, programming backgrounds and are managing projects are walking, talking, breathing examples of this form of insecurity.

Even technical managers are not immune to this insecurity.

In fact, to be honest, chances of you having this insecurity exist, even if you are the best developer in your organization.

The act of having written all that code for that critical module in that critical project, for instance, gives us programmers, what can be called, a 'perceived' sense of security. We love the warm and fuzzy feeling of our 'organizations' needing us for a a very long time in the future as much as we hate and fear the feeling of not being needed.

If you are working with a team your first responsibility as a manager; is to lose this sense of insecurity.

Now, that's easier said than done.

As it turns out, this insecurity is not 'that ring' which you can just lose in the sink. The fundamental problem of transitioning to leadership role is that this insecurity, in most cases, has a tendency to multiply rather than getting reduced; especially as you move up the pecking order.

Michael Lopp, in his post, describes this tendency of managers getting sensations of insecurity, rather articulately. He explains:

This sensation will appear at the end of the day when you ask, “What did I build today?” The answer will be a troubling, “Nothing”. The days of fixing ten bugs before noon are gone. You’re no longer going to spend the bus ride home working on code; you’re going to be thinking hard about how to say something important to someone who doesn’t want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting… something.

It is this sensation of building 'nothing' day after day that makes most managers feel insecure and take their first steps on the path to prickdom. This fear of their team or their organization finding out how easily replaceable they are, is exactly what makes them forget their 'not to do' list and makes them do too much. Most managers jump from creating Gantt charts, to organizing meetings knowing deep down inside that none of these activities do not add any value what-so-ever and yet continuing to sound detail oriented and in charge; instead of just getting out of the way and letting their teams drive.

Having said that however, turns out, depending on what you do with this insecurity, which is usually supposed to get you started on your path to prickdom, matters. This same insecurity that gets you started on your path to prickdom, can help you become a kickass manager, if channeled in the right direction. Used correctly and generously this fear or insecurity can transform you and take you to the next level of genuine competency. It is like taking the devil along with the angel when you head out to war against prickdom.

Used wisely, what this insecurity allows you to do is 'scale up'.

Don't knit your brows.

I'm not asking you to 'scale up' like the VP of sales and marketing expects your development team to scale-up-and-do-more-with-less; that's not what I mean. I'm not talking Managementese here.

The fluff aside, scaling up is one thing that needs to be one of the primary things you focus on in your career profile.  Michael talks about the art of scaling up using a writing style that is not just fun to read, but rather motivating . He explains:

As a new manager, whenever the sky falls, you’ll become an engineer again. You’re going to fall back on the familiar because those are the tools you know and trust, but it’s time to trust someone else: your team. If I could give you one word, a single, brief piece of management advice, the word would be “scale”. Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing. It’s time to translate and to teach what you’re good at to those who you work with, and that starts by trusting them to do that which you previously only asked of yourself. The benefits of defining and maintain this trust create a satisfying productivity feedback loop. By trusting your team, you get to scale, and scaling means you hopefully get to do more of what you love. The more you do, the more you build, the more experience you gather, the more lessons you learn. The more lessons you learn, the more you understand, and that means when more shows up you’ll have even greater opportunity to scale.

Put simply, to me scaling up means that you try to make yourself completely replaceable. You work hard to make yourself a primary candidate who can be fired without any dependency or hassle; because his team knows what they have to do and can continue to do it; even if you are not around or decide to quit. It's like building self sustaining eco systems in fish tanks. Continuously.

I'm not talking about traditional succession planning here. I'm talking about enabling your team to do everything you are doing and encouraging them to do it better; even while you are around. Make them replace you so that you are no longer a critical part to the success of the project.

Yes, that makes you primary candidate for being fired; but if it actually does gets you fired; you didn't deserve your job anyway; or maybe your organization didn't deserve you; either ways; it is best for you to move on.

My first lessons at scaling up came in when a young and budding developer at a client office, working for them, approached me asked me if I could explain the security piece that I was leading. Here's how it happened; he was free, had nothing to do and wanted to contribute. I was way too busy and way too insecure to let go ownership. I politely dodged his question with a - sure-maybe-some-other-time-when-I-am-free answer. As a matter of fact, My being busy wasn't a problem; my being insecure, was.

I'm not sure why I did that, but the very next day, I randomly walked over to his cabin and I think I spent over five hours taking him through the entire module, showing him how to debug the module and running him through the entire implementation. Then I spent a couple of hours showing him where my code sucked and asked him to see if he can come up with better ideas. It was the very next day something creepy; almost Hollywood style, happened. I lost my insecurity - just like that ring aught to have been lost; and most importantly, it was fun. 

Three weeks later this young and budding developer of ours was leading the security module. I moved on to code-reviews; working on the nastiest performance fixes and challenges which were so insane I loved working on them.

Early on in my career, it was divine coincidence, that made me stumble upon my first experience of 'scaling up' by making myself completely replaceable and then working my ass off to take up an even bigger and better challenge. It was like a tame lion, tasting his first few drops of blood. The rest as they say is history. Today, one of my measures of success if I am supposed to be managing it is - how easily will the project continue to run if I were to quit for good without any replacements.

Once this level of temporary uselessness is achieved; I love flaunting it, talking about it rather shamelessly and finding something much more challenging to do.

May I suggest dear reader that you do some serious soul searching on if you have insecurities about your colleagues beating you in the race of getting to the top? If you even heard the mildest whispers of the word 'yes' while asking that question; may suggest you act now and start on your journey to overcome these insecurities. Multiple techniques exist:

1. Pick what you learnt last week and conduct a knowledge sharing session. You insecurity of having no competitive edge will make you learn more in a desperate attempt to stay ahead in the stupid rat race; then conduct another session again after you've learnt something new. Keep doing this till you no longer feel insecure; and if possible continue doing it even after that; just for the fun of doing it. 
2. Take the module you own; explain it to someone and then hand it over. Help the other person when needed; but don't code on it. You insecurity of having nothing to do and not being very needed in your organization will make you probe into other productive areas; then teach those to someone else and hand them over as well. Once you've manage you use and lose all your insecurity; continue doing it anyway.

Long story short; use your insecurity till you lose it. Learn the art of making yourself completely replaceable and dangerously close to getting fired each year; and then, if you still don't end up getting fired year after year, you'll know you're growing. I wish you good luck.