Screen And Pick People For Your Team Like Your Professional Life Depends On It.

A very senior manager at Multiplitaxion Inc, has picked a few candidates from the cream colleges out there based on IQ tests and Math questions. He expects me to on-board them on my team and begin their training.

I am looking at his condescending eyes as I speak the unspeakable - "I'll need to interview them again before they join my team. Not all will qualify."

Suddenly I find myself involved in an argument where I'm being asked if I feel that the selection criteria of Multiplitaxion Inc isn't good enough.

Breathe --- I tell myself.

My professional career as a manager at Multiplitaxion Inc, depends on who works on my team and who doesn't.

This is one thing where intimidation and pressure techniques will not work easily. 

No-one is joining my team; not till they give another interview and pass the team's selection criteria. Not till they convince me that they 'fit' and that they have at-least one super-power.

Of-course; they are all 'good' --- I am sure some even smarter than I am; but the question that is on my head is different.

How many of them can clear the litmus tests? --- I find myself thinking aloud.

The Litmus Tests

During the course of working with multiple teams which worked on some decently interesting products; we came out with a set of litmus tests.

Before we go ahead with the whole idea of litmus tests; it is hugely important; dear reader; that you know and understand one dirty little secret of recruiting genuine builders.

This is big.

So big that most managers go into denial when they are told this secret of recruitment.

Steve Yegge; explains this deep dark secret of recruiting genuine builders with true competence in his post on Smart-And-Getting-Things-Done. He explains:

So you can go out there; 'formalize' your interview process; conduct five rounds of interviews; check all the past experiences, educational background and take all the IQ tests you want but if interviews are your only means of selection; chances are; that if you are not lucky; you can land up with a hardcore whiner.

Now that you know you cannot pick the most genuine of builders without getting lucky; the best approach; to take; dear reader; is to eliminate as many whiners and the assholes as possible and throw them out of the pool before you get yourself blind-folded and throw the dart.

The more whiners you have been able to weed out before you take your pick; the higher your chances of picking the genuine builders will be.

This is precisely where the litmus tests of recruitment come in.

If you really want to understand what Litmus Tests are take a look at some out there. A very famous example of a litmus test for programming logic is the famous Fizz-Buzz example illustrated at ImranOnTech.com. Imran explains:

While FizzBuzz questions act as a good litmus test for programming logic; multiple other litmus tests exist which can help you cover areas ranging from design; testing to general work interest and enthusiasm. Here are some examples of litmus test questions that you; dear reader; can use out of the box to access the overall technical competence, approach and attitude of the candidate.

Tell me any three technical questions that you can answer and then answer them.

Is the candidate lost; can he think of three questions he can answer confidently. Does he stick to simplicity or does he pick a complicated set of questions to impress you and then ends up blowing it. Based on the questions candidates pick; probe deeper and you know who not to hire.

Talk about three of your strengths and three of your weaknesses.

Most candidates when asked these questions describe their strengths rather articulately but come up with ridiculously stupid and artificial weaknesses; the I-cannot-lie weakness being the stupidest example. When you cannot talk about your weaknesses openly it just tells me that either you haven't done any soul-searching what so ever in your career; or you are a blame driven asshole who points a finger at others every time the sky starts falling.

Talk about one project where you were hugely successful and one where you failed miserably.

Any candidate who tells you that he hasn't ever failed falls in either one or all of these categories:

1. He has never taken a chance and has always remained in the realms of mediocrity.
2. He is a compulsive liar.
3. He goes in denial mode every time he encounters a failure. Chances are that he loops in the infinite loop of failure all the time.

Failures in your professional life are just as important successes. After all if you haven't had seriously colossal fu@#k-ups and failures chances are; that you haven't learnt enough and that you're not going to be successful.   

The Thing About Litmus Tests.

"Ok Pops. I get the idea." --- you say.

Good.

Now you can go out there and create a few of your very own litmus tests. The one thing to remember about Litmus tests is that they are not supposed to help you pick the genuine builders for hiring. All they are supposed to do is weed the whiners out. Put simply; the fizz-buzz question; for example; will not tell you if a candidate is a good programmer; but it'll tell you if he is a bad one.

Go prepare your own set of litmus tests that are based on your selection criteria and weed out as many whiners as you can. Then take a chance and hope that you get lucky.

I wish you good luck.

What do you do to weed out whiners and pick genuine builders who; if left alone will automatically create remarkable work and play environments?

How many times have you been successful in picking genuine builders and how many times have you failed?

What litmus test questions do you use while interviewing candidates, dear reader?

Discuss.

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

Hiring - Where It All Begins And Ends.

Recruitment Managers at Multiplitaxion Inc, look at me like I am an alien talking a different language all together. I've interviewed a hundred people; rejected all of them and have proven beyond doubt that there is something wrong with my eyes and scanning abilities.

All hundred of the candidates interviewed cannot be idiots after all.

Or can they?

Sadly enough no one out of those hundred candidates seemed to fit the criteria of people I would love to work with or even closely match people I was already working with.

'If you take this approach we are never going to be able to hire anyone.' --- I am told.

A subtle nudge that is supposed to tell you that it's OK to lower your criteria and pick the best from what you are getting. We would then go out and make a big noise about hiring the best of the employees.

That is exactly what most organizations do.

Put simply; this is one phenomenon Joel Spolsky describes rather elegantly in his post on hiring the best. Joel explains:

In the same article Joel also introduces you to the notion that genuine builders are not really going to be sending out their resumes and applying for a job:

What Joel is doing is pushing the idea of reaching out to really smart college interns and hiring them before they get a job opportunity anywhere else.

He is also pushing the idea that in case of genuine builder it is often your organization that might have to approach and quite literally beg them to join. Waiting for the resumes to show up in your inbox is not going to work. Neither is looking out for resumes on job sites going to be a very effective technique.

In multiple organizations around the world I've seen selection criteria come down merely by the virtue of the fact that a hundred candidates have been interviewed and none have been selected. When you cross the magical figure of hundred or more; suddenly; panic strikes. This is when organizations go out there and hire the 'best' out of the pool of idiots they interview.

Having your selection criteria crystal clear and not compromising on it is the first step to hiring a team of seriously kick-ass builders. Of-course Recruitment managers; and teams responsible for hiring candidates; are supposed to pressure you to go out and hire from the bucket of mediocre idiots that are being thrown your way. Providing these gentle nudges is a part of their job.

Most recruitment professionals and placement consultants are evaluated by the number of people that they place. It is therefore no surprise that the expert in them want you to lower your criteria. Most organizations out there actually have a whiner recruitment plan so they want you to lower your criteria as well.

Your job on the other hand is simple --- don't panic.

Hiring people who you are not fully satisfied with is your sure shot step to creating an environment that needs to be managed and anything that needs to be managed actively does not sustain itself in the long run.

Whatever it is that you do; don't panic; don't compromise.

I see multiple versions of the whole 'talented guys are limited'; 'we cannot be hiring all rock-stars'; 'we will never be able to hire at this rate'; arguments being thrown by multiple individuals and organization. Any organization that knows anything about software development turns a deaf ear to these arguments. Steve Jobs; for example; explains the process of hiring and how painful it can be rather articulately in his interview at business week:

Most Recruitment professionals will frown when they read this. Steve Jobs; on the other hand; also has a reaction to the argument of managers and organizations not having the time to recruit people at this speed; which he describes rather articulately in the same interview with business week. He explains:

Remember; of all the things that you are going to do to build a genuinely awesome work and play environment where builders thrive and flourish; recruitment is the most important.

It is so important I could quite literally do a complete book on it; but the whole point here is rather simple --- recognize the importance of hiring the right people; have a clear criteria for the team and whatever it is that you do; do *not* compromise on the people you hire.

If you can do that; most of the great work and build environment is pretty much going to happen automatically. If you don't you have lost the battle before it even begins.

Taking the simple approach of We-have-to-live-with-what-we-get does not cut it. All this approach does is create an army of whiners; faster than you know it.

What is your interview to ratio of candidates selected to the number of candidates rejected?

How many times have you been pressured or gently nudged; to settle for less when it comes to selecting candidates for your team?

How many times have you given in to the pressure, dear reader?

Discuss.

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

One of the thing that fascinates me is an environment and the vibe that I get from an organization when I walk into it.

As a consultant I've worked at countless client offices around the world. During this period of my life as a consultant I have seen a few environments that are capable of housing genuine builders and giving them room to maneuver; thrive and flourish. I've also seen a few environments that would make a genuine builder uncomfortable to an extent that he runs and never comes back.

The fact of life however; is that most environments fall somewhere in the middle. Smack in the realms of mediocrity which is good enough to get your work-at-hand done but not cross the chasm of innovation and build something that is genuinely remarkable.

This is why most software companies; irrespective of where they are located hardly do anything which makes big or small dents in the universe.

When I talk about your organizational 'environment' I'm not just talking about how your office looks; how big it is; or what your decor looks like.

Environment is more a state-of-mind; a reflection of your organization's personality.

From the very first vibe that you get when you walk into an organization to the feeling that you develop for the organization after working there for a couple of months --- that's what I like to call your work environment.

That is exactly what I've been interested in observing for quite some time.

Observe a wide range of organizations long enough and you can't help but ask a few simple questions:

1. Why do some environments have the best of the builders; while others struggle to find even decently good candidates?
2. Why are some organizations able to make really big dents in the universe; while others are unable to make even a tiny dents on their own backyards?
3. Why do some organizations need teams of just three builders to change the world; while others find it hard to survive even with armies of consultants?
4. Why do some organizations have builders sticking around year after year; while others struggle to keep their revolving doors from stopping for sometime?
5. Why do some organizations have style; finance and brand loyalty; while others are just cheap body shops selling cheap brainless bodies?

These are questions; most managers and organizations; have been trying to answer for a very long time. The answers I believe lie in observing some of these teams and organizations very-very closely. 

Everything you will be reading in this section of this book comes from an exercise which involves taking three simple steps:

1. Studying companies that are successful and observing individuals who have been able to made a big dent in the universe.
2. Observing the organizations that are getting it wrong and trying to figure out why they are going wrong.
3. Trying to figure out what is so hugely different between these two organizations or should we just say --- trying to figure out what's wrong in the underlying approach of the two organizations.

Google is often regarded as the holy grail of software development world. It is one company that has undoubtedly changed the face of the world and how we interact with the internet. 

Stories, articles and videos of the great work environment at Google are littered all over the bathroom walls of the internet.

CEO's; CTOs and Vice Presidents look at these stories, videos or pictures littered all over the place and cringe at the mere thought of spending millions in trying to build environments which can compete with Google environments.

The safe line of defense you hear these folks speaking is --- 'We're not Google'.

Now that is one line I've heard from friends, acquaintances and sometimes even professionals in offices of the clients I have worked with.

If you've said this before; I've got to be completely honest with you dear reader and give you a little secret you can use.

Ready?

You do not have to be Google.

In fact; you should strive really hard to see to it that you do not become Google.

The Google element of charm and surprise is  taken. It's old. Trying to mimic Google is going to get you nowhere. 

As a matter of fact; trying to mimic any work environment is stupidity at its height.

When I say that; I also mean that trying to mimic the typical-factory-floor model of how people do stuff in 'big companies' and 'body shops' is also something you might also have to consider stopping immediately.

What you need to do is think and come up with ideas that will work in your organization.

Creating work environments for builders is easy. Whether you are a CEO; a Vice President; a Manager; a Programmer or just another employee; I am here to tell you; dear reader; that you can make a difference in the overall thought process of the organization and the overall work environment by making small changes at your very own personal end.

What I intend to do in this section of this book; dear reader; is show you how easy it is to create an environment where builders can not just thrive; flourish and grow but also feel proud enough to spread the word and attract other genuine builders to join in.

It goes without saying that as we move along I will be expressing my ideas and proving my points through the act of story-telling.

The intention here is not to try and preach the list of 'N' things they can do to create awesome work environments.

I wish it was that easy as that and I wish I had the list of those 'N' things but I am really sorry; I don't.

When it comes to creating the best of environments I personally believe that there is no one right answer. My intention here is to give you an insight into the builders mind and what makes a builder happy; motivated and productive not just to stick around but to rope in other builders he knows.

At the very grass-roots level; creating an environment of this sort requires three fundamental things:

1. Time.
2. Thinking like a true builder and having genuine empathy for your employees. 
3. Common sense.

That's easy Pops --- you say. Well personally I believe that getting your organization to genuinely adapt to these three simple bullet-points is going to be the hardest thing you might every do in your current job.

During the course of this book we'll look at some obvious common sense driven aspects most organizations; managers and HR professionals seem to miss out on completely. We will also talk about a few things everyone sees but no-one cares about; even when some of these things are hugely important.

Before we start with these stories in the posts that follow; lets end this one with three simple questions for you to think about.

Do you look forward to going to office on a Monday morning?

How would you rate your work environment on a scale of one-to-ten?

Is your organization even interested in collecting your rating and then acting on it, dear reader?

Discuss.

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

Free And Open Source Field Level Database Encryption For SQL Server 2005 and Later.

At work we design and build financial applications. When you are in the business of building financial or banking applications your database will contain sensitive information including account numbers and accounting information that you want to protect obsessively.

Multiple layers of security becomes important in cases like these.

The first layer of-course is the SQL server built-in permissions and security.

At a second level you want to lock out everyone's access on the production servers so that they cannot grab the data-files or access the database directly.

The third  layer is encrypting certain pieces of information at the field level and encrypting sensitive fields so data inside the database cannot be read by anyone even if he has direct access to the database --- this includes even the database administrators and the support staff who will be managing database servers.

Making your life simple with adding this third layer of security is exactly what SQLDBCrypt does.

SQLDBCrypt is an in-house SQL Server 2005 based encryption engine that we developed as a side hobby project.

Put simply; at a basic level SQLDBCrypt does exactly what commercial products like XPCrypt do; except that SQLDBCrypt is free and open source.

We have been using this product to encrypt and decrypt sensitive data that goes in an out of our applications for over a year and are very happy with the results.

The story behind SQLDBCrypt was somewhat on the lines of 'an idea conceived and implemented by a single builder'.

Abhijit Ghosh; who gives you a very sinister smile when you ask him if he has a blog or a web presence; is a very capable DBA and a programmer rolled into one; who works on my team at work.

Sometime a couple of years ago he conceived the idea and decided that he wanted to take this project up as his official assignment.

Early on in the project; we decided to give him time to do get a prototype done; get him everything he needs, wish him luck and get out of his way.

A few weeks later we were playing with a working prototype using which; we were able to get it adapted inside of eFORCE as a formal product with a formal testing and development team that would move the product forward and use it in some of flagship products.

Within a few more weeks we had a working version which was fully tested and which was being used in some of our financial applications.

We have been using SQLDBCrypt internally since then.

When you work in flat organizations where even the top most management understands software development; decisions of this sort are often done without any meetings or any committees. After more than one year of usage in production environment we at eFORCE recently discussed the idea of taking SQLDBCrypt to open source and were able to get a green signal literally in less than three days. No long-winded discussions; no meetings and no committees.

We moved the code base on CodePlex for you to try it out and give us your feedback; dear reader.

If SQLDBCrypt interests you; we suggest you start by visiting the Product Home Page on CodePlex. 

We're licensing this code under the New BDS license which allows you to use this product even in commercial projects without any of the typical restrictions that you get in commercial products and other open source licenses.

The source code for the project is available live; so if you really want to review the security aspects of the code and send in your suggestions; you can totally do that.

The project started as a fun project and slowly matured into something which was reliable and something we could use in our own product stack. We clearly did not have any intentions of competing with commercial database encryption companies out there but when we were done we did some basic benchmarking of the product with other commercial products like XPCrypt and in cases of huge data sets found SQLDBCrypt to be around ten times faster.

While we are talking about comparisons it might also make sense to talk about limitations of SQLDBCrypt while comparing it with other products out there.

While most commercial products like XPCrypt support multiple encryption algorithms we are starting with support for MD5 for hashing and RC4 (128 bit) for encryption.

We will be releasing support for other algorithms moving forward and are expecting community contributions for adding support for additional algorithms moving forward.

To add to that; while commercial versions of products like XPCrypt work on older versions of SQL Server; SQLDBCrypt uses SQL CLR and requires SQL Server 2005 or later.

Currently we are keeping the team size really small but going forward we will be adding team members as and when required.

We will be doing a formal series of benchmarking tests, posts and examples of how you can use the product going forward; but if you have a need for this product we would encourage you to try it out; beat it up; bench-mark it yourself and let us know your comments and feedback.

We are calling the current version a beta release for the next few days till we reach decent packaging and add all the bells and whistles of a formal product to it. Having said that; we really want you to download this version; play around with it. See if it meets you needs; if it does go ahead and use it in your projects. Feel free to let us know your thoughts, ideas or any bugs you encounter while playing around with this product at the Project Task List on CodePlex.

If you would like to start added discussions around the product or any of it's features feel free to use the product's discussion board at CodePlex.

If you like the product; and the fact that we have decided to release it as a free and open source component; go spread the word. Tell your friends; blog and tweet about it.

If you do not like the product; please do tell us why and where you think we can improve the product.

We love the idea of supporting whatever it is that we write and would love to take in suggestions on changes or features which can improve the product.

As much as I would like to recommend this product highly to everyone; the fact of life is that it addresses a very specific problem and if you do not have the need; the product in all it's glory is not going to make any sense to you.

If you are building a Library tracking system; this product is clearly something you do not want to waste your time investigating.

On the other hand is you are building a system which is going to store information worth protecting obsessively; examples being; banking applications; finance applications; or anything that stores sensitive information like account numbers; credit card information etc; --- go give this application a try before you go and buy some of the commercial products out there.

Do let us know your comparative analysis and what you think.

More announcements and open source goodness coming soon.

Stay tuned.

Selfish, Lazy And Not Big On Being Ethical.

I'm the Frankenstein's monster.

I'm talking about downloading office space trailers from you-tube using the office bandwidth.

A 'Few Good Men' working for the best interest of the organization stare at me like I've just dropped a stinking dead carcass in a meeting room.

"But that is not very ethical" --- says someone.

This is it.

The moment when the room fades into the grayness and you can clearly see the white differently from the black.

This is when I am hit by an instant flash of lighting.

I know exactly what I want from the candidates I interview to join my team. Besides, technical competence and a truck load of qualities I already talked about in this book; I am going to pick my builders based on three simple additional qualities:

1. Laziness.
2. Selfishness.
3. Does not bitch about ethics.

Of-course; I know you're knitting your brows already. I know I owe an explanation to what I just said. So; let's get on with the explanations.

Get Me Someone Who Is Lazy.

I'm staring in awe at Fred as he demonstrates his sort-able grid view. He spent months building it. He is flexing his engineering mussels. He is one proud hard working builder.

I'm sorry.

I would prefer someone lazier.

Someone who would just go out there and... buy a sort-able grid.

Honestly.

I have no problems with you building stuff; but going out there and building the thousandth sort-able grid isn't my idea of innovation --- unless of course you are in the business of building grid views.

If you're not you might consider not flexing your engineering mussels of heroism and you might consider buying that freaking grid-view out there.

Having said that; genuine builders love the idea of building stuff. At work; when we landed up with an application needing fifty reports we decided to get lazy and build an ad-hoc reporting system which would allow the end-users to do their own reporting.

Genuine innovation doesn't happen by building the same grid view, reports or CRUD application a thousand times over.

It happens by indulging in the act smart laziness.

Get Me Someone Who is Selfish.

At work my every single day revolves around my selfish interest which over a period of time has co-incidentally intertwined really well with my organizational interest.

When that happens and interests intertwine builders stick around. 

During my days as a young and budding engineer; I was conducting three trainings a week on topics ranging from .NET to usability. Even today I try my best to conduct regular trainings at work.

Anyone who tells you that he is conducting these trainings or knowledge sharing sessions for the best interest of the organization is giving you a truck load of horse shit in it's rawest form.

I conduct trainings because:

1. I get to learn new things which I am going to train others on.
2. I get better at communication.
3. I get to flex my engineer mussel and show-off how smart I am.

Training; is just an example. I pick it because conducting a knowledge sharing session seems like the most selfless of acts. I am here, dear reader, to tell you that it isn't.

Nothing is. 

Builders don't work under the false pretence of doing a favor to the organization or working for the best interest of the organization.

Anyone who does that is a hardcore whiner.

Make no mistakes.

Every single genuine builder out there who is worth his salt; is going to work for his very own selfish interest.

Organizations that align themselves to the best interests or their genuine-and-totally-selfish-builders; win.

The famous twenty percent time at Google is just one over hyped example of this happing in the real life.

There are tons of others out there.

Keep your eyes open and you can come up with your very own remarkable ways of taking the most selfish interest of your builders and aligning them with the interest of your organization.

Try to make your builders work for the best interest of your organization and you will end up doing is indulge in the act of sending your organization down the boring road of mediocrity.

Someone Who Does Not Bitch About Ethics.

Genuine builders tend to love what they do.

Besides their life long passion for their work and a consistent commitment; most builders that I have worked with are amazing fun loving people who do crazy fun loving things.

Walk into a software 'thinking' development shop and it isn't unusual to see a few programmers with their head buried deep in their monitor; their ears stuffed with head-phone.

Quite a few of the builders I have worked with have varied kinds of music they like to code by.

Others have a hilarious collection of funny videos.

Some of into Sudoku.

Others are into X-Box games.

In fact; even when it comes to software development and work; most seriously kick-ass developers live outside their cubical.

If you're going to be constantly bitching about how much of your time and bandwidth usage is for work and how much of it is for personal reasons like fun and growth; software development isn't for you.

What you need to do is get a job at the car-factory-work-shop or an Indian-call-center.

Now stop hitting that stupid ALT+TAB window and switching from you-tube to the code window every time your manager passes by.

Try not to obsess about what is ethical and what isn't. Instead; consider having a blast and shipping some seriously kick-ass innovation.

Seriously.

At the end of the day it's like this --- those who bitch the most about ethics; have very little of it.

Now; go hire a few selfish programmers who do not constantly bitch about the best interest of the organization or ethical code of conduct. All they focus on is just their very own selfish interest of growth; building stuff and having a good time doing that.

I wish you good luck.

Oh; and one more thing --- if you are reading this from your office don't forget to watch the office space trailer on you-tube using your company bandwidth --- parts of the movie are what I call utterly hilarious.

How many times do you hear big words like, right, wrong, discipline, ethical and unethical in your workplace?

How many times does your organization expect you to work for the best interest of the organization and not give a shit about your own interests?

Does your organization work on factory rules and no trust; or is it an environment where builders are genuinely empowered, dear reader?

Discuss.

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

I'm Just Working For The Best Interest Of The Organization.

"All I am trying to do is work for the best interest of the organization."

The next time you hear those words --- run.

As fast as you can.

And whatever it is that you do --- Don't look back.

If you just heard those words from someone you know; with all due respect to this acquaintance of yours; chances are high that he is either of these three:

1. A certified prick who utterly and thoroughly enjoys being an asshole. 
2. A Hardcore whiner who is also a self proclaimed well wisher of the organization.
3. A cheap Indian programmer who in all probabilities is working off a cheap Indian outsourcing shop.

"But Pops; you are hyping this up" --- you say.

No I'm not.

I know what I am talking about.

Trust me.

I've heard these words countless number of times and every single time I've heard them; the bearer of these words have fallen in one of these three categories.

Still knitting your brows; are you?

It's time you take you back in the depths of time and dig from ages that have rolled behind a few stories from the war fronts of software development; that shall illustrate my point dear reader.

Flashback time!

I Removed The Reporting Server

Multiplitaxion Inc, is a new client of ours; their product is struggling to cope up with the traffic during afternoons. We have been called in as a consulting organization to figure out how we can speed up the performance of the application.

The programmers are introducing level-2 caching into the system; the DBA is tweaking the stored procedures.

We've spent days analyzing at our end. Our findings are simple --- the afternoon loads are heavy; the system could do with another reporting server having a specialized reporting database.

Here is the creepy part however --- buried deep down in the physical architecture diagram of the system created a couple of years ago; is a box called 'reporting server' which stands proud and tall. 

Confused; we decide to interview the entire team including the Database Administrator who is working on tweaking the stored procedures.

'Oh the reporting server --- that was costing us a lot of money. We got rid of it. We can get this to work by tweaking the stored procedures'. --- it is the database administrator speaking.

Silence.

Sounds of crickets chirping.

I turn around to the CTO; suspecting the highest in the pecking order of usually being the asshole in these cases; throw a simple question --- 'Did you ask them to do this?'

The answer is a cold --- 'No'.

More silence.

More crickets chirping.

"What? I still feel we can run without spending money on the reporting server. All we need to do is tweak the stored procedures" --- we are hearing the database administrator speak; but a very few people in the room understand the language he is speaking.

You have to give the guy some credit.

After all; he was indeed working for the best interest of the organization.

We're just trying to make sure we utilize the company bandwidth for official purposes only

I can't seem to figure out how I got here.

I am staring at a snickering system administrator who finds the idea of downloading videos from you-tube using office bandwidth as grossly unethical and amusing at the same time.

There is one little problem however; the video is a hilariously funny and inspirational; I want to share with my team.

"We're just trying to make sure we utilize the company bandwidth for official purposes" --- I am told.

I hail to the self proclaimed well wishers of the organization.

Then I buckle up to take this further with people in the organization who have the enough power and common sense to understand.

We can reward him by giving him more challenges.

Jack is working hard. Seriously hard.

We've been struggling to get this release out and Jack has been up practically all weekend.

The project has just shipped; the sky is blue and the birds are singing.

His project manager gives him a complementary leave to rest and heal from the bruises of a difficult war. 

In the copy-list of the email are a few others higher up in the pecking order.

Someone responds --- this gentleman who is responding after removing Jack's email from the trail; thinks that we cannot be giving off complementary holidays as easily as this. He proposes:

1. Cancel Jacks complementary holiday.
2. Offer him more 'grow opportunity' by giving him more challenges; spelt ---- "more work".
3. We all collectively work for the best interest of the organization even when rewarding team-members.

I'm not directly connected or concerned.

I decide to shut the fu@#k up.

The Late Marker And The Break Time Calculator

Fred is interviewing with us. Here are his achievements besides work:

1. Suggested development of a 'late marker' that marks employees late if they get in after nine in the morning. Three late markers results in a leave getting deducted.
2. Suggested development of a break time calculator that is going to track the number of minutes individuals spend during their break time.
3. Developed the perfect Frankenstein style - 'employee cloning system' and cloned a couple of hundred micro management zombies.

Well actually, he didn't mention the third one; but while he was at it; working for the best interest of the organization; he might as well have designed a Frankenstein Employee Cloning system used to clone a few micro-management-zombies like himself.

Self Proclaimed Moral Police

I could go on with the stories for ever. In fact, given my observations I could probably write a dedicate hilarious book on this but it would mostly end up having a Daily-WTF flavor to it. 

For the time being however; let's not even go there.

Lets focus on the point here.

Every organization that I've visited, worked for, worked with, built a project for or observed has a few whiners who like to think of themselves as the 'well wishers of the organization'. People who have a 'job' of defending the organization from the scum of other employees.

I like to call them the 'self proclaimed moral police'.

They individuals; will try to protect every single square inch of the organization they can; starting from the internet bandwidth; the disk space on individual hard disk of developers; to printer paper by monitoring the number of printouts each developer is firing on a daily basis.

After observing countless number of these guys; screwing organizational morale; in my career; if there was one thing I learnt; it was how to spot these whiners in an interview; keep them out of your team and keep then out of the organization.

Spotting them is easy.

All you have to do is keep your ears open and look out for the golden words --- "for the best interest of the organization".

And when you hear those words, run.

As fast as you can.

Whatever you do --- Don't look back.

How many Daily-WTF-type examples under the name of the best-interest-of-the-organization have you witnessed?

How many whining self proclaimed moral police have you had a pleasure of working with?

How many of these decisions taken for the best-interest-of-the-organization ultimately ended up fu@#king up the organizational morale and eventually nudging it in the realms of mediocrity where cheap Indian body shops haggling over per-hour-billing-rates reside; dear reader?

Discuss.

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

What You Think

Don't be a bullshit passer.

If you are having a bad day as a manager --- deal with it --- without passing on the badness to your team.

'Yeah Pops' --- you say --- 'easier said then done. I've got a angry client or a lose tempered vice president to report to and he wants the application done before the road show. What do you propose I do?'

Surprise.

That is supposed to be a question you needed to answer the day you accepted your promotions and became a manager.

That's when your team expected you to know what to do in situations of this sort.

Having said that, the real question here isn't about what you do.

It is about what you 'think'.

Do you 'think' what your client or your vice president expects out of your team is justified or is he just being an asshole?

If he is just being an asshole for the sake of being one; your job is simple. What you hear in these meetings where the vice president or your client decided to throw a truck load to shit on your backyard; should *not* translate into action items or an unrealistic dead-line for your team.

How you do it is your seriously problem.

Look at him in the eye. Talk to him. Breathe. Convince him. Beg. Weave a story. Tell him what the word 'quality' means. Tell him why you are different from a million Indian programmers sitting in funny body shops running out of India. Kidnap his child.

I don't care.

Ok; the kidnap-his-child bit was a joke that wasn't even very funny --- but you get the idea. 

If you 'think' he is being unrealistic and acting like a prick --- don't let the shit run downhill.

Just because you are stuck with a bad boss or a bad client doesn't mean that your team needs to open their IDE and start slamming their keyboards to write some code that will get the application to crash on the day of the big road show.

If you 'think' however that your boss or your client is acting like an asshole but what he expects out of your team is realistic and what he wants will genuinely help the product --- you and your team need to open that development environment.

Long story short, whether your team opens the IDE or not should *cannot* be decided by how big an asshole your manager is.

It has to depend on what you 'think' about the requirements at hand.

Remember; before you go up to your team --- think.

Do you think what he is telling you to do is going to help the product?

Have you decided that you are going to ask your team to open that development environment and write some code?

Wait.

Before you ask them to do that; you've got a few humbling exercises you need to indulge in.

Get Naked.

The --- "we're working weekends because we need to get this done by Monday" --- doesn't cut it.

No, it's not 'all they need to know'.

You need strip naked.

Tell them everything. The story so far; who wants it; why does he want it; who is being the asshole; why you think it will genuinely help the product; how will it save your job; why you want them to work weekends; why you want their help. Everything.

You cannot be keeping secrets and expecting people to give you cover-fire in battles.

Remember; this is a save-our-souls signal you're sending out and you're the one who is being rescued; so get the perspective correct when you go out to 'request' your team and ask them to work weekends or push seventeen hours a day.

The getting naked part is hard.

As someone who has requested his team to work in pressured situation more than once; for years; and have been lucky to have the best of builders on my team; I can personally tell you how hard it is to get naked the first time you do it.

What I cannot do however; is teach you how you can do this without feeling a little embarrassed.

If you're going to learn how to lead a team of genuine builders; you're going to have to learn this getting-naked part; by doing it yourself.

I can't tell you exactly how to do it; but If there is one thing I can tell you; it is that bossing around and being an asshole does not work.

If We Fail No-one Gets Killed

Say it.

Mean it.

Even when you know that if it doesn't work out; the sky will fall on your head and you will be left to die under a scrap load of shit.

When you're naked your builders can sense the importance and what the stakes are. The whole idea of If-You-Are-Not-Able-To-Do-It-Someone-Is-Going-To-Get-Hurt helps no one.

If you lack insight into your builder's brain I'm going to lead you into another little secret here which is going to be a life changing moment in your profession; particularly if you are managing a team of genuine builders.

Ready?

When your genuine builders walk up to you and start a conversation around how important the task is and ask you if they 'really' have to get it done by the end of that day; they are not looking for an escape route so that they can go home and sleep with their wives. They are just telling you that they are going to pull of a serious productivity stunt here; a magic trick that might fail and if it does; they want you by their side.

They aren't looking for an escape route when they ask you if they could ship on Monday instead of Friday.

All they are looking for is a safety net; and room to maneuver.

On a subtle; subconscious and psychological level they are testing if you are in it with him.

If they fail; and get stuck; are you going to give them cover fire or are you going to turn around and run like a rat.

I've had multiple cases of Can-We-Ship-Monday on a Friday evening. Some of them have been embarrassing. Walking up to a client and apologizing isn't easy. Having said that most of them times when it has happened - I've  said "sure" - and meant it.

The result?

We've either shipped on Friday itself or we've shipped something better that the client absolutely loved on Monday.

We've technically failed more than one dead-line so far; sometimes by a day; sometimes by a couple; but here is the funny part --- the sky is still blue; it's still up there and no-one has got killed. 

Learn How To Say Sorry Followed By Thank You And Mean It Too.

Somewhere along the line; after spending countless weekends and late nights in office; I ended up telling myself that I would try my best to see to it that my team members 'can' get out of office by six thirty. If they 'want to' stick around and work --- we're good --- but they shouldn't have to.

The reason to take this stand and to try to make it possible for them to get out by six-thirty is simple; every time I get an assignment done by requesting people to stay late, push harder or work weekends, it just means this:

1. I fuc@#ked up at planning. 
2. I was incompetent at talking to the client or my managers and getting more time.
3. I expected them to complement my lack on planning and incompetence with my team's added effort.

If you find yourself in this situation as a manager; remember;  pushing the idea that the sky is falling and if the team does not push harder, work late-nights or work weekends, everyone will get screwed isn't going to help.

Let's face it dear manager; you fuc#@ked up and unless you work with a team of idiots chances are that they know that it was you who fu@#ked up.

You might as well come out and say it.

Try topping that with a sorry; followed by a thank you.

Then try meaning both the sorry and the thank you.

There are multiple ways of 'meaning' it.

For me; if you usually work a holiday; it is followed by a couple of complementary day offs when you do not have work.

I usually like to top that off with a team lunch or a party that's on me; not on the organization.

It doesn't compensate for my screwing up; but it's my way of saying three things:

1. I fuc@#ked up.
2. I am sorry.
3. Thanks for the rescue and the cover fire when I was stuck.

You might have your very own style of saying sorry followed by thank you; but if you aren't saying it; and then 'meaning it' using concrete actions not just words --- you're just trying to pretend you're this big highly competent manager who is making an incompetent team 'push harder' when all you are doing is being an asshole and not even knowing it.

You're what we call, a whiner; a bullshit passer and a mail server.

How many times have your team performed a rescue operation for you?

How many times have you genuinely admitted your fu@#cking up followed by a genuine thank you; not just by words but through actions?

Do you have managers for whom you would happily indulge in rescue operations; or do you just do them because you have to; dear reader?

Discuss.

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

The Problem With Being A Bullshit Passing Whiner.

"My manager is a pompous asshole in pressure situations." --- you say.

That's a lame excuse for taking the shit and passing it over to your team when you find some on your own backyard.

Remember; organizations are all about observation.

You see, the whole act of morphing into an asshole that your boss pulled off when the sky started falling; you were watching that.

Closely.

Weren't you?

Now; just in case; if you didn't realize here is another secret.

The builders in your team; they were watching it too.

Not just watching your manager; they were watching you as well; to see how you are going to deal with the shit that your manager threw at you and which is now safely lying out on your backyard.

Unless you have observed organizations and builders at work very closely; let me turn you on to another secret you may not already know --- ready?

They expect the worst.

Your builders; I mean.

Time has taught them to expect the worst. They're prepared; waiting for you to throw the shit in their backyard and get on with your comfortable life.

You can do it right now. Take the truck load of crap --- throw it over the fence straight at their backyard and forget that the problem ever existed. Be rest assured they have both; the competency and the courage to clean up the mess for you.

There is just one tiny little problem with doing that however --- at the first act leaving the shit in their back-yard you've just disassociated yourself from the team of builders; you have just sent out a very subtle, silent It-Is-Not-My-Problem message to your team.  

Do it just a couple of times and your team will start perceiving you as a 'manager' followed by an 'outsider' --- not an integral part of the team who is support to play definite role in the larger scheme of the team dynamics. 

Do it a little more frequently and you are not even a 'manager' or an 'outsider' any more. You are now just a 'problem' that the team needs to 'deal with' --- just like hundreds of other problems they have to deal with while they indulge in the act of building stuff.

You are no longer a partner in crime.

You are this pompous prick the team needs to 'take care of' or handle.

By indulging in the mere act of passing shit from your manager to your team; you go from a team member --- a friend --- a partner in crime --- to a being a problem that the team needs to deal with; in one simple and easy step.

Of-course; there is no secret builder's meeting where they officially denounce you as a pompous prick and a problem they now need to deal with.

It all happens with silent clicks-and-ticks in the minds of builders as they observe; watch and draw their own conclusions from what they see.

As smart and sleazy as you might try to act; depending on what you might have learnt from your past experiences; be rest assured; a tightly knit team of builders will have tools and mechanisms for finding out if you're a part of the team; a genuine supporter or a random outsider who is going to run at the first sound of trouble.

During my early days at Multiplitaxion Inc, we worked with quite a few of these bull-shit passers.

We had a name for them --- we called them "mail servers"

All they did was take a flame mail from a vice president, change a few words here and there and passed the message on to the rest of the team. We did their shit cleaning for them. When the shit was cleaned up; they took our emails, added a few more words to make the message as vague as possible and passed the message along to the vice president.

During my early days at Multiplitaxion Inc, I've been with a team where we've lost track of the hours or days spent at office; we have also seen an instance where one of the individuals actually ended up having a physical nervous breakdown followed by a hospitalization; because of the amount of shit was thrown on our backyard.

Did we die?

Heck, no.

All that happened was simple --- we got stronger.

Our bonds as a team grew deeper.

As far as my life is concerned; most individuals from those times, including the builders and bullshit passers have gone their own ways.

We meet every now and then; accidently; in a cafe or a restaurant.

As strange as it might sound, even today, the presence of a colleague from an old time who happened to be a bullshit passer, in the same cafeteria or restaurant makes me feel a little uncomfortable.

On the other hand, let the restaurant, have a team member, a builder or a partner in crime and I would have changed my table faster than you can think. Before you can realize, you will see us laughing and talking about the times when we went from "we're screwed" to "we made it" --- together.

In all probabilities; you will; almost invariably see us giving each other offers to join the organizations we currently work for; because working together again; is something we look forward to.

After all, who doesn't like a partner in crime, watching over his back and giving him cover fire on the battle field especially when you are building remarkable and fun products together.

If you're a young and budding manager; who accidently landed with a team of builders; you can take all your shit and pass it over to their backyard. Be rest assured; they will clean it up for you; before you even notice. There is just one tiny consistent backside to doing this however. You will go from a manager; to a problem passer; to being the primary problem of the project in on simple step. 

The next time you are having a bad day --- remember --- if your boss is a pompous asshole -- it is not your team's problem.

Letting the shit run downhill; is clearly not a 'management style' that works; specially when you are working with a team of genuine builders.

Of-course; you're having a bad day.

Of-course the sky is failing.

Having said that; at the end of the day; if they find out the magnitude of the 'badness' of your day --- you are not a builder --- just are just a bullshit passing whiner and just one of the countless problems your builders have to deal with when they indulge in the act of building stuff.

Have you worked with a manager who expected your team to work harder by forwarding a flame mail from your boss over to your team?

Have you worked with a manager who gets a strange perverted kick in ordering your team to stay late?

Have you worked with a manager who prefers to go home and get a 'status update' in an email while the rest of the team works late night?

Have you worked with a manager who thinks that he can get more output by pushing the team harder?

Have you ever had a bad day just because your manager is having a bad day, dear reader?

Discuss.

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