The best of managers often manage by building self sustaining teams.

The best of managers often manage by building self sustaining cultures which attract the best of the best and repel the whiners away.

The best of managers often manage by weaving stories which are true and remarkable and which spread within the corridors of the organization and nudge people to do the remarkable.

If there is one thing that is common in the best of the managers it is that their management styles are all about.... managing by not managing.

How do you manage your team, organization, project or product?

Just a little something to think about.

Choosing Between Nothingness or Attempting To Change Lives.

"Nothing" is just about the riskiest thing you can do today.

Lack of resources or opportunities is not the biggest of your problems. Your personal fears are.

Everyone knows this. But most of us spend most of our time doing nothing and being afraid.

There is a funny sitcom you bump into while aimlessly surfing channels. That's nothingness.

A funny discussion on facebook. That's nothingness.

Tweeting about where you ate yesterday and how you hang out with friends. Nothingness.

A long phone conversation on politics with a friend. Some more of serious nothingness.

Why don't you drop nothingness and work on something meaningful that has a "potential" of changing lives? Maybe you do not do that because:

1. Your lizard brain is afraid of failing?
2. Your lizard brain is afraid of succeeding and things around you changing too rapidly?
3. You are just way too comfortable doing nothing and your lizard brain doesn't want to give up that comfort?
4. Nothingness gives you a temporary high and your fears allow you to feel sorry about yourself?

Failing, being made fun of, being doubted, being questioned, being criticized and being called a looser are all better than letting your fears get the best of you, hiding behind discussions, meaningless conversations on facebook and doing.... nothing.

Is facebook, television, conversations and endless arguments a back door for your fears or a hiding place for your lizard brain?

Be honest to yourself when you answer that question and if the answer is yes, try to drop these and work on something meaningful.

Next weekend you're going to have a choice between doing something meaningful and  aimlessly surfing your television.

Which one are you going to pick?

Just a little something to think about.

A Configuration For Getting In The Flow.

Is there a set of songs that you love listing to when you are coding?

Is there a particular corner of your home that triggers ideas when you sit down to write in that corner?

Is there a setting or a set of configurations in your life where all your depressions, anxieties, questions and fears are put aside?

A setting where you can focus on practicing your art?

If you answered no, why are you not working on creating these settings? Picking a soft song and listening to it every time you are distracted while coding. Picking a tiny corner of your home and moving there every time you want to write. Picking a small weapon and switching back to it every time you are unable to focus.

If you answered yes, what are you doing to increase the recurrence of these settings in your life.

After all, productivity often brings happiness. Why not work on building settings and configurations in your life that make you productive especially when you are distracted, depressed, scared or confused?

Just a little something to think about.

What's Your Contingency Plan?

Just a little something to think about from the trenches on the Cricket World Cup 2011 that India Just won.

What's your plan for the day when your star performer is unable to perform (falls sick, is not in the form, if going through a bad time or for any other reason)?

Build contingency into your project plans? Include buffer time into your project plans? Consider everyone a resource and do generic planning? Start Feeling insecure of your own team? Look for another hero?

That's what most managers and captains do.

Genuine managers and captains know that none of this is not contingency planning.

Having a team where every individual in your team can and often does morph into a star performer is usually your only human contingency plan.

If you don't have that all the other contingency that you provide for is just random documentation and a truck load of bullshit.

You know what a stale product is, right? We've all worked on them. Every product company has a portfolio of products where some products click and some gather dust on a beta build waiting for the first set of users to show up.

Even Microsoft had the classic Microsoft Bob. There is nothing wrong with having stale products started within your organization. Ideas have to be implemented before you can test their validity.

Having said that, your ability to identify a stale product early on, defines your awesomeness as an organization or a software development team.

Here are some rather simple guidelines which might help you figure out if the product you are working on a stale product or it needs more effort.

You know you are working on or dealing with a stale product when:

1. None of the best people in your organization want to work on the product.
2. When every potential client you show the product to says, "looks good" but doesn't sign up or really use the product everyday.
3. When more than two really capable marketing guys who have sold other products in the past are unable get any customers for the product.
4. When you have been working on a problem without any real user feedback for more than a couple of years.
5. When you try eating your own dog food but other departments within your own organization find the dog food too yucky to eat or too hard to digest.
6. When you find the team building more and more features in the product to impress the management or the marketing department instead of building features your customers will genuinely need.
7. When you see managers discussing technology instead of what the product should do. "Search is going to be hot. Let's see if we can integrate lucent with this product".
8. When you find your business analyst building fictional requirements based on common sense mixed with their fetish. "Let's integrate the advertising module with the time and expense module to keep a track of the time spent on advertising. Yeah! That's going to be so fu@#king cool! I bet no one out there has anything like that! That's what we should do in the next version."
9. When your development team moves to auto pilot or hibernation and stops asking why they are building the features they are building.
10. When the marketing department starts telling the development team that adding this one User Interface enhancement before next week will help them land their first customer. i.e. When you are continuously doing Demo Driven Development Cycles.
11. When one quick sniff at the product tells you that it is rotting and stinking beyond repair and everyone is just busy ignoring the problems instead of getting down in the sewages and cleaning up the mess.

Anytime you start seeing more than half of the above in a single product, you are probably working on a stale product. You are better off quitting or surrendering. Quitting is not such a bad thing after all.

How do you spot dead projects in your organization?

How do you convince your management to move these projects to the graveyard?

Just a little something to think about and discuss.

“Why are you building readershideout.com when sites like Shelfari.com, BookChums.com, linkedin.com (the book list part), GoodReads.com and a dozen others exist out there?”

We've been asked this question multiple times, on facebook, on this blog, on one on one discussions and during long walks and my personal opinion is that this question is actually bigger question than reader’s hideout so I’m going to take some time and answer this to the best of my abilities.

The question really boils down to saying, “If anything close to my idea exists on the web should I even be building an implementation or should I spend the rest of my life waiting for another idea to show up?”

The reasons are multiple of course, but here I some I feel fairly strongly about.

I. Many Italian Restaurants.

I’ve talked about this before so I’m going to keep this point real short. We are perfectly ok with the idea of having two Spanish or Italian restaurants existing around the block but we cringe when we think about having two similar websites anywhere on the internet. Personally I still believe that even though the total distance from any website to another on the internet is just one click, there is some solid value in having choice of websites and services out there.

For one, it pushes innovation and allows the service owners to put a little bit of themselves and a whole lot of their imagination in the service. But then there are other bigger reasons why if you have an idea, a willingness to make a difference and the ability to contribute an implementation towards that idea you should go ahead an implement that idea, which transitions us to our next point.

II. There is No Abstract Art. You Always Start By Building Something Real.

“There is no abstract art. You must always start with something (real). Afterwards you can remove all traces of reality.”  - Pablo Picasso.

Readers hideout is our attempt at making reading cool and providing you a gorgeous way to discuss books and meet interesting readers out there. We had a few ideas that would make Readers Hideout completely different from any of the other book tracking service out there. We had two options:

1. Hide in a cave, build something for a year which implemented every single one of those different ideas, throw it out to you guys and see if it works.
2. Throw out a basic version of the website that looks like most other services, ship it and then work on “removing all traces of reality” gradually over time.

We chose the latter. There is a reason why you do not see book categories on the website. There is a reason why we didn’t go out there and build the user group functionality. The honest comment here is that we don’t know all the answers yet but we’re also deeply convinced that the approaches most book sites out there allow readers to communicate are not the best of the approaches possible.

We’re deeply convinced that there is a better way of allowing users to discuss a book. More on this later and we will be announcing each “abstract” or fun feature when we release it and we’ll be talking about precisely how different it is from any other website out there.

The point is that we need a live “real” code base shipped and working in production before we could start experimenting on it and start shipping some serious abstract art.

III. The Vibe.

Even though reader’s hideout looks like most other book-sites out there the list of features that will start showing up in the next couple of months will start setting a very different vibe to the service. I would love to talk about it but I realize that talking without a real implementation in hand is just lame marketing. I’ll keep the stories on hold till we have something real to show you and I promise you we’ll talk about some of these very different features when they go live.

IV. Why Not

No, seriously. Think about it. Here you are with an idea so strong that it will not let you go, even when multiple other implementations exist out there. You brush it aside a couple of times and it keeps coming back.

Then on one fine evening when you have nothing else to do you sit down to code a tiny part of the idea into existence and you really love working on the idea.

After working for hours you feel all charged up and excited.

You keep doing that weekend after weekend. And in the process you learn how to tweak your application for performance, how you can return the cleanest possible HTML back to the users, how you can do AJAX JSON calls without using ASP.NET Ajax and a thousand other things always wanted to try out before.

The cost of hosting a website or a service is cheaper than ever before making guerilla  services like Readers Hideout possible.

The other day someone asked me what my business model was and I told him I don't need one. The cost of keeping Readers Hideout up and running is so low that I plan on keeping it up even if I and a couple of friends are the only people on the system for the next few months.

When the cost of running a service is so low, the intrinsic rewards are so high, effort and passion are the only two requirements, the real question I have to ask you is, why aren’t you doing it too?

Why don’t you take an idea that you have, stop worrying about if someone else has built it, see what you can add to that idea and start shipping?

And then when someone asks you why are you building a service that already exist out there, you can just point them to this post and I’ll take up the tasks of arguing with them on comments. #grins.

On a serious note, we are going to be working on some pretty amazing features on reader’s hideout. My only suggestion would be, stay tuned to this blog and we’ll keep you informed about the features we add.

The series of blog posts is not just going to cover readers hideout but larger more generic questions and things that we learn along the way as we move ahead with readers hideout.

Thanks so much for the questions, for trying out Readers hideout and for continuing to read this blog!

Random Thoughts On Policies:

Someone 's downloading movies.... lets block the internet!

Someone 's coming in late and leaving early.... lets punch timecards!

Someone 's taking a CAB instead of a subway.... let's do a travel policy document!

Someone 's wearing T-Shirts instead of ties.... a policy on dress code!

The folks at 37 Signals have this to say about policies in their book Rework:

Don't scar on the first cut. The second something goes wrong, the natural tendency is to create a policy. "Someone's wearing shorts!? We need a dress code!" No, you don't. You just need to tell John not to wear shorts again. Policies are organizational scar tissue. They are codified overreactions to situations that are unlikely to happen again. They are collective punishment for the misdeeds of an individual. This is how bureaucracies are born. No one sets out to create a bureaucracy. They sneak up on companies slowly. They are created one policy--one scar--at a time. So don't scar on the first cut. Don't create a policy because one person did something wrong once. Policies are only meant for situations that come up over and over again.

The classic story of most policies is the same:

1. Someone does something stupid.
2. The organization over reacts and writes an equally stupid policy.

It's a classic two way street for turning intrinsic motivation into hard core ruthless professionalism.

It's like paying your mother in law for a gorgeous dinner and a surprise party she planned for you.

Between steps one and two are all other innocent clueless employees wondering what the f@#ck just happened and scrambling for information.

Every time you find yourself making a policy, your management and  recruitment teams have failed pathetically and hired a bunch of moronic sheep who need herding instead of hiring engineers.

That or your organization just doesn't know how to talk to people and communicate problems openly, candidly and act strongly in certain situations.

Either ways, it's a problem that no policy can solve in long run.

Most of your policies aren't going to fix anything. They're two way streets for stupidities involving a couple of stupid employees and equally stupid organizational reactions.

Replace every single rule or policy in your organization with an intrinsic social norm which appeals to the goodness of your people and you'll have an organization that changes the world.  And if you can't appeal to their goodness, why are they still working in your organization?

Just a little something to think about.

A fat obese middle aged American guy munching on his packet of potato chips and commenting on that pass in the soccer match.

A skinny under weight Indian munching on his packet of lays and describing how the batsman should have played the shot in the cricket match.

Both would probably collapse on field if asked to play just a single complete match of soccer with their kids.

Everyone loves sports. Everyone loves commenting on sports. Playing the sport, is a completely different ball game all together.

Talking like an expert is so much more easier than, "doing" something, even if the doing only involves just meeting the basic standards of a novice.

People love giving expert comments on everything that they see.

If you are a builder or a story teller, your job is to play the game, be a starter, learn the basics and then get better at it.

Can you do that? No? Then shut up and enjoy the game. And  stop giving us your expert opinions on everything.

Now, translate this analogy to managing teams, the advice you give them on how easy a task is, how much time something should take and the volume of code you yourself write. Get on the field. Hit a few shots. Score a few goals.

If not, stop scoring fouls and stop giving your expert opinions. Seriously.