Builders, Story Tellers And Whiners - Part 4

Your Organization Is (Not) Hiring Builders.

When builders indulge in the act of building stuff what they are actually doing is building foundations of the organizations in which they work.

Given the fact, that remarkable products and services are the very basis of a successful organization you would think that most organizations out there would be going out of their way to hire the best builders that they can get hold of much like tea pickers pick the best tea leaves they can find.

Most organizations however, are not looking for the best of the builders.

The "not" in the above sentence is intentional. It is not a typo.

It is a rather important fact. A fact that you must know and understand fully well --- particularly if you are a builder, someone responsible for hiring others or an entrepreneur starting your own organization.

As a part of my professional and personal life, I talk to countless engineers and managers around the world. Strike a conversation around their recruitment drive and any budding manager will tell you that his organization is on the lookout for the 'best talent' that is available out there. Put simply, he will tell you that his organization is looking for some seriously talented, kickass builders.

This post is about shattering the dreams of that young and budding manager.

Irrespective of what your organization announces in those weekly newsletters --- Your organization is *not* looking for seriously kickass builders.

Knitting your brows already?

Ok, story-time!

Ready?

Let's have a quick flashback.

As young and budding builder at heart when I am asked to lead a team it seems like a simple task.

Leadership, I tell myself, means that you work harder; you take up bigger problems and if people are stuck they come to you for help. If they are not stuck; they go about doing their work and you go about doing yours.  If you're leading a team of seriously kick ass developers; every once in a while, your team also expects you to build something which inspires them. That's pretty much it --- leading smart engineers is simple --- all you need to do is help and inspire.

At-least that is what I tell myself.

Two weeks down the line I find myself looking back and reflecting on just how wrong my definition of leadership had been.

As it turns out, organizational definition of leadership, is different. Very different. 

In the real world where 'shit happens' --- leadership; has a completely different meaning than the meaning it has in your very own personal world.

Your being promoted to a leadership role means you will now be sending weekly documents called 'reports' to people who have no direct involvement in the project and are often referred to with fancy names like 'senior management' or 'stake holders'. People who can do nothing other than making things worse when your project starts failing.

In my case, leadership came with it's baggage of 'weekly status reports' which I was expected to send to my immediate manager who happened to be a part of the 'senior management'.

Week 1 --- I am excited about this whole leadership thing. I send out a neatly formatted, status report which takes me more than a couple of hours to write. 

Week 2 --- More formatting, more words, lesser real work; yet another status report goes out. 

Week 3 --- The status reporting thing starts sounding boring. Downright boring. I find other important things to do; like helping team members who are stuck and making sure that a fully functional build gets uploaded to a test environment so that everyone in the organization can try it out.

A day later I get an email from the 'Senior management' telling me that I had missed sending out my status report and that it was unacceptable for someone as senior as me to just miss sending out reports.

Week 4 --- I'm back to boring status reports again. The status report ships on time.

Week 5 --- I am stuck by a realization; a question and a curiosity all rolled into one. A couple of subtle questions are gnawing away at the back of my head. 'Do they really read this crap?' --- 'what do they understand about the project health by reading this crap?' --- Then a personal tiny little experiment is devised.

Before I describe the experiment may I suggest that you do not try this at your workplace. It is clearly an experiment which can get you fired if it fails. Ok, ready for the experiment? Here's what the experiment I decide to try out after five weeks of boring status reporting.  

On the fifth week I take a copy of the report I had sent the week before that. I attach it to the email; cross my fingers; and hit the send button.

The next day is fairly interesting. I look at my mail box, only to find out that life is good. No-one complains. No-one even realizes that it is the exact same file as the week before. No-one, is reading those status reports.

Week 6- The same document that was sent for the last to weeks is taken; the file name is changed; the file is sent. No complains.

Week 7 - Status reporting is now suddenly becomes really easy for me.

Sending a weekly status report from then on is easier than most young and budding managers can think. For as long as the project lasts, I send the exact same status report and no-one even notices.

Then the project ends. We ship the build, everyone loves it; the project is a success --- and the reports?

Question: Do you think this manager of mine wanted me to send the reports because he was going to read those reports or do anything with them?

End of flashback.

Let's snap back to life.

A simple dissection of the story and picking up the nuggets of lessons learnt of it will help. After all, if we don't do that, we are just as guilty of whining as professional whiners.

If there was one thing I learnt from the event; it was that most of the people from the so-called 'senior management' are often afraid of change. Change that threatens their existence. A team of three young and budding developers self sufficient at shipping is every whiners nightmare. It is in fact every organization's nightmare.

Why?

The reasons are two fold.

Firstly, because the pecking order has been genuinely made to believe that whiners have a specific function in defining the existence of the organization; that 'developers are not very good at communication' --- that builders need to be 'managed'. When a couple of genuine builders show up and challenge the conventional beliefs not by empty meetings and discussions but by consistently shipping concrete deliverable results; it is natural for whiners to feel threatened.

This highly respected project manager of mine for example, liked to believe that the project was on track because the team was aware of the fact that he 'might' be tracking the project through the status reports. He genuinely believed that the status reports were keeping us on track when in reality all these status reports were doing was wasting a lot of my time.

His role and function in the project was redundant. Removing him from the project would have helped us ship faster; and yet this dear manager of ours believed that he has a definite function and a concrete role in the project. He was the self proclaimed, 'project policeman'. 

Secondly, organizations like to believe that the whole 'organizational' arrangement of things is what causes projects to 'tick'. 'Always think of the team first' - 'you can hardly do anything alone' - 'team achievement is much more important than individual contribution' - 'we need to document stuff so that people are replaceable; after all someone might fall sick; decide to leave or might get his by a bus' ---  ever heard these statements in management meetings?

Organizations like to believe that it is the organizational structure that is hugely responsible for innovation; not individuals that they hire; while in reality the reverse is often true. We like to refer to our most remarkable builders as 'resources' and then we like to go out and prepare 'project plans' and 'resource management reports'. We like to naively believe that it is these reports and processes that make the organization tick.  

A couple of builders, shipping successfully without any organizational intervention feels scary to organizations which do not believe in the idea of individual contribution. Most organizations and managers alike; find it difficult to leave a team of builders alone.

This; dear reader; is why most organizations and even the so-called-managers out there are *not* looking for genuine builders who can build remarkable stuff silently; this is why most organizations out there are looking for professionals who can be programmed to follow processes and believe that they are just a tiny drop in the larger 'organizational' scheme of things.

If you work in one of these organizations; irrespective of what your Human Resource department tells you, chances are high that your organization is not looking for genuine builders. In fact, in all probabilities, your organization is shit scared of builders or anything that brings about any form of change. Chances are high that you organization is in fact, looking forward to hiring whiners and maintaining the whiner recruitment plan.

How many genuinely deserving candidates have you seen getting rejected in the interview process?

Why did these candidates get rejected? What reasons were sited by the whiners who rejected them?

How many genuine builders or story tellers are leading teams in your organization?

How many whiners that have been promoted to their level of incompetence?

Is your organization letting the builders take the back-bench and letting the whiners drive the organization, dear reader?

Discuss.

@BuildersAtWorkBookNotice