Random Thoughts On Builders At Work - Part 5.

Builders Lead By Building. Not Managing.

Early on in my days as a young and budding developer at Multiplitaxion Inc; I heard a very mature individual talk about the philosophy of basketball and how that wisdom maps to software development teams.

His observation about the game was rather interesting:

When you are playing with a team size of five you need every player to score.

I've always advised young and budding managers roll their sleeves and continue writing some code. Scoring constant goals yourself is your only chance at keeping a team of genuine builders motivated and gently nudging everyone in your team to score too.

I've observed countless builders and story-tellers around the world and in all these years of observing them I am yet to find one genuine builder or story-teller who doesn't roll his sleeve and gets down to some real work himself.

Having said that; I continue to be amazed and surprised at how difficult most organizations make it for a builder; with just a few years experience; to continue remaining a genuine builder. James McGovern in his post on this topic; explains the issue rather articulately:

Being an architect in a large enterprise, the biggest challenge for most architects is in staying technical and grounded in reality. It is way too easy to become a buzzword parrot where one spends more time thinking of cool phrases that otherwise have empty meaning over focusing on producing credible architectures with integrity. I find it fascinating that we talk about business/IT alignment, cost reduction and other reasonable practices yet no one is asking the more difficult questions.

How can a business be successful in the use of technology if the vast majority of team members especially within IT don't understand it? I bet you work with teams that have one technical person, in the midst of various managers and other “developers” (usually off-shore) and find that one technical person does a majority of the work, takes the blame for the failures (of himself and/or others), yet is rarely credited for success. How come competent developers put up with nonsense and continue to take the rapings?

Should developers challenge their managers to look at their shiny, gold plated project plans that adhere to CMMI level 13, ITIL, Agile, garbage 2.0 and other worst practices and find a single item that someone else could take more than 10% credit for? At the end of the day, the vast majority of projects either still succeed or fail based on heroics. Sadly, we have realized that heroics are not the way an organization should be run, so instead of working on repeatable, sustainable practices for software development, we have morphed into repeatable, sustainable ways of doing perception management and throwing developers under the bus.

James ends his post with an interesting note:

I am proud to say that none of my reviews in the last ten years have ever had a single negative comment regarding my ability to deliver high quality work, in a timely manner and within budget. Much of the feedback is based on perception management.

The thing I think about almost daily is how I can live up to a  high standard not because of just personal motivation but because others are watching. This is the essence of leadership.

I don't want to be a manager nor should others be forced to report to one.

Early on in my career at Multiplitaxion Inc we ended up with a situation that was not planned. It was completely co-incidental; but then; having said that; the happening of the situation resulted in an observation that taught me the deep dark secret of management.

Smack in the middle of multiple projects; Multiplitaxion Inc; realized that a few of its managers were not working out well and got rid of them. Panic stuck and other managers; left on their own. In about three months since the firings happened; Multiplitaxion Inc; was a 'zero manager' company.

When I say 'zero-manager' I mean literally a zero-manager company. There was no-one in office who had a business card with the word 'manager' on it --- except one Quality Assurance Manager who was an amazing guy doing some serious hands-on testing himself. Given his way of leading a team; he had recently been promoted to the designation of a manager. People; including his own team; hardly knew the fact that his business card included the word 'manager'.

Other than this Quality-Assurance-Manager of ours; who continued to be a very technical-hands-on manager; developers at Multiplitaxion Inc, woke up one fine morning and literally discovered that all their 'managers' were gone. Just like that.

Any guesses on what happened when they realized that they suddenly had no managers?

The answer is what each one of us; as programmers; developers; builders or story tellers know deep down inside; but are too afraid to discuss or even say it out loud --- what happened is that the developers became much more effective and productive at what they were doing.

Things; dear reader; started getting done.

Am I saying that you go on a firing spree and fire all managers in your organization?

Of-course not.

Having said that; if you; dear reader; are a manager; try to see to it that when folks walk into your office wanting to discuss a problem; your monitor has a code-window open and not a Microsoft Project Plan.

If you want to lead a team of builder; you'll have to stand of the front lines of the battle march.

You can only motivate a team of genuine builders by building stuff and scoring goals --- consistently.

Remember; Builders lead by inspiring others to build stuff; not by managing them; and the easiest way to inspire others to build stuff is to build remarkable stuff yourself.

Now; dear manager; close that project plan of yours; open the integrated-development-environment and start talking the language the rest of the builders and story-tellers in your organization are talking.

I wish you good luck.

@BuildersAtWorkBookNotice