Builders and Story tellers have their own set of problems.

One of the biggest ones is that if you are an amazing builder or an amazing story teller, chances are that you are an artist.

You get ideas in the shower that are so strong that they hold you by your collar and do not let you go till you put them within the curly braces of code functions or on the light grey pages of a notebook or a word document.

You get fragments of inspiration.

You get headaches with multiple threads of ideas running in your brain at night as you try to sleep.

You thrive at creativity but your problem is that you cannot fill your tax forms without mistakes.

Your problem is that you can get an entire system built but sometimes you blank out and forget what it is that Jack in your team is supposed to be working on.

Dam! You said you will put that down in that excel sheet. You said you were going to get better at tracking.

Newsflash: You are just wasting your time trying to become someone you are not. You are a builder. Not a mover. There is a difference between the two.

Every project requires builders.

Every project requires story tellers.

What every project also requires are movers.

A mover is an otherwise quite tester who walks up to the developers desk and casually reminds him what he needs to work on for today without brining a truck load of process in the middle. His business card or title does not entitle him to remind developers what they need to work on.

But he does it anyway, because creating movement is a part of his nature.

Strangely enough, Instead of resisting or saying no, the builder, listens to him because he knows the mover is not bossing around. He is just helping by being himself.

A mover is an otherwise silent document formatter, who points out the critical features the team has been missing for the last three sprints and that you, the project manager have completely forgotten about.

When Jack says he is done and is about to sign off, the mover jumps out of nowhere and reminds him with a smile that there was a bug that he had said he would close but never did.

A mover notices the slightest of broken windows.

A mover is not in your face. A mover is not irritating. A mover is NOT a manager. A mover does not go around with Gantt Charts and detailed project plans. Yet, a mover is ten times more efficient than a dozen managers running around with their Gantt charts.

Being a mover, means that you "have to" be moving. You have to be in a team that is moving. You sense movement. If your team is slowing down you are the first one to sense it. If your team is moving at a dangerous velocity you notice that too.  But you don't freak out. You don't whine asking others to speed up or slow down. You silently and quietly create an environment where more thrust is applied or thrust is reduced.

I don't consider myself to be a very good mover. I am nowhere closed to being organized. I don't remember stuff. But every time I work in a project that has a team size of more than one, there is always a mover involved. My current project at work for example has multiple movers.

Almost every given day I am nudged by a mover or two reminding me about the stuff that I had promised I would do and I did not do. The movers understand that my bosses called and wanted me to work on an urgent document during the weekend.

But then the movers are relentless. The movers will also be at my desk Monday morning, just casually chatting about what they did during the weekend and then just as they are leaving, reminding me that if I am free I can take up that bug that I said I would fix before the urgent document came up.

If you give me the slightest of hints about taking the movers out of my project and I will fight fiercely to keep them in my project, because while the builders are building stuff and the story tellers are weaving stories, the movers are watching the speedometer, the broken windows and the loose ends, rushing to remind you with a smile that you missed that final stroke of brush in your painting.

Have you identified at least one mover in your project? If you haven't, chances are that your project is fumbling right now as you read this, even if you have both, builders and storytellers working on your project. Go find a mover. Then give him the liberty of being himself and let him build some movement with a gentle nudge every time he sees your speedometer fall, your window break or your painting finish without that final touch up.

I wish you good luck.

He bitches a lot. The whiner in your team, I mean. The classic whiner feeds on gossip. He feeds on creating confusion through communication. A whiner usually whines because whining and bitching is easier to do than shipping something.

The classical management folks and people from HR will give you intelligent sounding advice. Talk to him, they will say. Counsel him. Have a discussion with him.

BULLSHIT.

Then there is other breed that will panic at the whining and bitching. Fire him NOW, this bunch of managers will tell you.

More BULLSHIT.

Unless the whiner is a political scumbag, there in a whiner in all of us. The whiner whines because he is lazy. Because whining is easy. He whines because YOUR culture tells him that he can get away without shipping if he whines.

If you want to genuinely help a whiner and your organization, here is the golden advice:

Get him to ship something. Anything.

I don't care how small it is. I don't care how insignificant it is. I don't care if he ships crap. Make him ship. Consistently.

The same advice works for almost anything in life. Small incremental steps. If you have never run before, running just hundred meters will find you panting like a wild dog. They key is to do it. The key is to keep doing it. Then do it more.

Shipping is hard. Shipping means growing out of your comfort zone. Shipping means you take your ass off that couch, stop bitching and actually add value. Shipping, is also addictive. Shipping adds to a sense of well being and once you start becoming good at it shipping is fun.

Get your whiner to work. Get them to ship something. Anything. Leave no room for lame excuses, moaning or bitching. Make it clear to your whiner that you mean business. Chances are that they will either get so uncomfortable that they will leave or they will slowly and steadily become effective at what they do and have much less time for whining.

Repeat the process.

Do it till the whiner has either quit or till you have a fully productive employee who does not have time to whine any more.

Of course, there is a little bit of a whiner rooted deep down in all of us and if you have not been steadly shipping for some time now, the same recipe works for fixing that whiner within yourself too. Try it.

I wish you good luck.

The internet is littered with articles and blog posts by project managers on how they spoke the truth about their project timelines slipping, how their clients loved them for it and how they lived happily ever after.

I have had my share of those stories and I would love to share them with you, but that would be BORING.

I could tell you that honesty is the best policy, but that would be way too CONVENTIONAL.

The reason why you should choose to be honest in your communication and deals is not because honesty always leads to a happy short-term ending. Honesty is not a commodity that you try to market when hell breaks lose and expect to sell it every time. If you think of honesty as a commodity, chances are that you will find it really hard to market.

Honesty is not a last resort escape route.

Its a way of life.

Its your attitude.

Its who you are.

Honesty begins by being honest towards your work. If you have given your hundred percent, being honest when disaster strikes is not a very difficult decision. It's the gnawing guilt of not giving in your best that makes honest communication so much more difficult when the hell breaks loose.

Your honesty test began when you were doing your job when the sky was blue and when the birds were chirping, not when the sky started falling.

What were you doing when the storm of panic had not started? Working to the best of your abilities? Honestly?

Honest communication is not usually very hard if you were. If you know you were not, then honesty becomes that much more harder. You find yourself playing with excuses, jargons and your fingers by pointing them at others.

I have played the blame game before.

Writing about it and admitting it, even years after it happened, was much more difficult than most people think it is but the whole point of writing about it was that it was a lifestyle change. A transition that happened over a period of years, is still happening and hopefully will continue to happen throughout the lifetime.

The good thing about some of these experiences though, is once you have been through just one of them and burnt yourself, the decision of being honest towards your work becomes a hardcoded part of your lifestyle; and once that happens, the decision of being honest in your communication, even when the sky is falling is a no brainer.

If you were a programmer did you write the best of the code you could? Fought to the best of your abilities to avoid crappy decisions?

If you were leading a team, did you do the best leading, keeping an eye on the project without getting in the way and the best mentoring that you possibly could?

If you were a marketer were you honest to your client when telling him about your product features?

Go on. The next time the devil knocks on your shoulders nudging you to take that shortcut in your daily work life, give him a cold shoulder. Being brutally honest, when the hell breaks lose will be that much more easier if you know deep down inside that you were honest all through and that you did the best you could.

I wish you good luck.

When was the last time your team actively decided not to ship a feature that was done?

When was the last time you had a fully complete post sitting on your hard disk but you told yourself it was not good enough and decided to delete it?

There are times when you watch a lousy movie and you wonder why the production department even bothered releasing it?

As creative individuals we like working on stuff.

Stopping often becomes hard for three primary reasons:

One: The more effort you put into stuff the more attached you become with the stuff you are working on. This attachment creates blind spots and an inability to judge the output of your efforts objectively.

Two: When the creative endeavors have financial aspects involved realizing that you need to stop becomes even more difficult. Yes the movie is lousy, but if we release it at-least we make something out of it. Yes the product is lousy, but even if we release it at a reduced price we stand to earn something out of it. Lets just give it out for free and try to get some users.

Three: When creative endeavors occupy a lot of your time, stopping them, becomes an ego issue. Stopping now is just going to mean the world is going to know about it and think you were an idiot to continue for this long. If the product, the blog post or the endeavor was your idea to begin with, the ego at stake is even higher when it comes to stopping.

Gears are switched. You move to an auto pilot mode where you are doing nothing but building mediocre features on an already mediocre framework. Version after version of the product are rolled out. Every mediocre blog post on your disk is published. Every boring movie is released.

Before you know it, its not just your product, your blog or your movie. You are boring. You are mediocre. You are lame. We do not care about you any more. You are that guy with a boring blog, that director who makes boring movies or that software body shop that hires cheap cogs and builds lousy products.

If you have a product that you are deeply passionate about and believe in, don't worry be crappy works, but if you are working on auto pilot and just not feeling it, shipping stuff that is boring, makes you boring.

Stop. Give up shamelessly. Hit the Delete button. Now.

Fred took rounds on the office corridors during the evenings to take a feel of who was busy versus who was reading an online newspaper or playing a video game. If you happened to have anything other than work running on your screen when this gentleman took his rounds every evening, the least you could expect is an email with a list of tasks that you need to immediately start working on. The most you could expect was a taunting sarcastic remark.

I see a young and budding manager somewhere knitting his eyebrows , folding his hands and taking a defensive stance already. Somewhere, in some corner of the world, there is a young and budding manager reading this, talking to himself and saying this: What is this idiot talking about now? I mean resource management and utilization is all about making sure that your resources are utilized at an optimum level. Isn't it? Huh? Huh? Huh?

Actually, you know what, if you have heard this 'resource utilization' line or if you were that young and budding manager who was thinking this, chances are that you have picked it up from one of the two places. One is through your underpaid teacher at a B-Grade management school. The other is through your previous manager who you looked up to.

Now here is the newsflash: Chances are also high that your underpaid management teacher never actually managed a single live project in his entire life. And as far as that previous manager that you looked up to is concerned, well he might just have been a regular old jerk who was managed by other jerks when he was young which is where he picked up the thought process without questioning it.

When you take a team of kick ass programmers and put them on a kick ass project, you form a self sustaining eco-system. Assuming that you have hired correctly, if you leave a bunch of builders free for sometime, good things happen.

Every programmer has "TODOs" in their code comments. Things that they tell themselves they will come back to later. Every designer has design changes that he would like to refractor if he had more time. These are exactly the things which differentiate a remarkable product from a lousy mediocre one. When you leave a kickass team alone chances are they get sick and tired of reading the news in about and hour.

Then they often tend to come back to these changes and they tend to start working on them. Silently. Quietly.

If you have a product that has been running for more than a year now and a passionate team that loves working on the product, try telling them nothing to do for a couple of weeks and see how they react. Chances are that they might either give you a product with a stronger, faster and much more stable foundation or they might come out with features and really small changes that might pleasantly surprise you.

Stop those stupid status meetings. Stop monitoring every hour of your programmers. Stop giving them new assignments as soon as the last assignment on their list is marked as done. If you have hired the right guys and have left them alone, chances are that they are working on stuff that needs attention. Stuff that you might not even be aware of. Stuff that might usually come back to bite you two years from now. If they are free, they won't sit quietly for long.

If you have the right people, they will be much more worried than you are about having nothing to do.

Now go cancel that status meeting. See how it goes.

I wish you good luck.

In this video on BigThink Jason Fried the cofounder of 37Signals talks about interruptions at work.

The video is excellent when it comes to dealing with interruptions and finding out what is wrong with a typical office workspace today. 37Signals by far have been one of the most vocal when it comes to calling out on bullshit of other firms and they are often heard because they are successful.

I have quoted 37Signal so extensively that I have often been accused of being a 37Signals fan-boy.

To be honest, I am one.

The problem with blind fanboyism however is that you often tend to see everything positive about the organization and lose the objectivity to see mistakes the organization is making.

The recent video on 37Signals new office space however, is disappointing, particularly if you take the fan boy cap off and analyze their office objectively.

To begin with the video shows the entire team in a meeting or a conference. I am sure this is a rare occurrence at 37SIgnals but definitely not the right time to be shooting the video specially when you take strong stands on how toxic meetings are. What is actually even more disappointing is that their office seems more like a typical cubical farms with open workspaces designed for interruptions.

When  you are an organization as small as 37Signals who believes in not interrupting your developers and letting them get in the flow, why build classic cubical farms where interruptions are a part of the design?

Why not learn from FogCreek office tour video which seems to suggest that they are putting their money where there mouth is by giving every developer most items on the programmers bill of rights?

I'm just saying.

Okay, enough critical commenting. I am going to wear my fan boy cap again.

By the way, did you read rework? If you did not it is definitely worth a read. Go buy a copy now. #Grins.

Venture Capitalist have been using this technique for years now. There are a few out there who browse through countless PowerPoint presentations and every minute detail of your business model. Others however are more interested in knowing you as a person and every question they ask revolve around judging you as an individual.

As someone who has been given funding offers without any presentations, ideas or even asking for them, the aspects that some venture capitalist use to fund you, confused me, till I learnt first hand from a venture capitalist, that he was not interested in funding an idea. He was interested in funding the people who he thought were right people.

As an organization however, when you hire employees the equation seems to change dramatically and rather abruptly. We are suddenly concerned if a person knows what a Factory or a Facade is. We are so obsessed with skillets that we tend to forget that is it not the skill set you are hiring. It is the person.

Is the candidate smart? Is he upright? Is he honest? Will he go out of the way to help others? How is he going to handle setbacks? Is he a paycheck programmer?

Hiring a "good" human being should be on the top of your list when hiring.

Everything else is secondary.

Of course, the competence, the kickass programming skill-sets and years spent slogging on code helps, but if you are not spending enough time and energy evaluating the basic personality elements of a person, you are just hiring skill-sets, not people.

What would you rather hire? Three years of .NET or a helpful, enthusiastic programmer with kickass programming skills who happens to be really good at .NET?

The choice is yours. Just like the Venture Capitalists who prefer to fund "good people" over "good ideas" I prefer to hire good human beings with a smart mind over hiring a resume or a skill-set.

Ok, I am done with the post.

You can go ahead and call me stupid or impractical now or you can munch on this thought next time you go to take someone's interview.

I wish you good luck.

As a consultant I’ve been on-boarded into multiple organizations during my career. The best on-boarding is not when the HR takes you around the office on your first day showing you toys like Gyms and swimming pools. The best on boarding is when the HR shows you how the organization you are going to work for is going to empower you as an employee.

A beautiful tool for empowerment was a capped corporate credit card which we were handed on the day we joined work. File office expenses directly to this card and you do not have to worry about getting them reimbursed. This is what I call Hassel free empowerment that comes with a lot of responsibility.

Another beautiful empowerment tool was cell phones. Of course you carried your own cell phones to work, but when we joined we were handed a cell phone that was directly billed to the company.  “You can use these to make any phone calls” – we were told.

Of course it meant work related phone calls but that part wasn’t stated explicitly which made it all the more empowering.

Work from home. Casual dress code accepted widely within the organization. Open internet access.

This was one organization that was serious about empowering employees.

Look around you. How many of your office facilities are nice toys to have versus how many empower you? Having a gym is one thing. Letting your employees take an hour off during the afternoon if they want to and work out is another.

When you are surrounded by policies you can smell that. When you are empowered you can feel the empowerment. Toys are nice to have, but if you do not have empowerment in your workplace the toys mean nothing.

Don’t just give your teams and employees toys to flirt and show off.

Empower them.

I wish you good luck.