Wednesday, 14 March 2012

How well do you handle truth?

How do you react when someone in your team honestly owns up a mistake? Do you flip out or do you react constructively and help take corrective action?
What I've learnt from my personal experience is - if you become angry in such situations, then gradually most of your people (except for the really upright kind) will stop being completely truthful to you. They will start building elaborate lies to protect themselves and/or their peers/subordinates. Eventually, you will fail to get crucial information that would have helped you steer your project away from trouble.
If instead, you appreciate the honesty and react to it constructively, then you can be sure of getting the right kind of information every time.
The key then, is to be able to handle the truth dispassionately but constructively when it comes to you. This applies not just to managers, but to organizations as well. Organizations that are more open to honest criticism and incentivise (rather than penalize) honest data collection are bound to do well in the long run.

Saturday, 17 September 2011

The Agile Pyramid

(The story is not mine, but this is the best analogy I've known for Agile.)


There were two pyramid contractors in Egypt (guys who built pyramids for a living that is) and they are both hired by a really old pharaoh for building one for him. His requirements were.


1) It should be the biggest possible pyramid that can be built

2)It should be ready when he is dead.


Contractor A: Decides to build the largest pyramid ever. Bigger than the biggest. He estimates that this would take him a year with the laborers that are available to him.


Contractor B: Has a good long look at the pharaoh, and realizes that the pharaoh may not last that long, maybe a month or two. He decides on an interesting approach. He decides to build that largest possible pyramid that he can build in one month. The next month, he’ll build an even bigger one on top of that, the month after, an even bigger one.


The pharaoh died in 3 months.


Thursday, 1 September 2011

The obvious and not so obvious benefits of Test Driven Development

The basic principle of Test Driven Development is simple. You write your test code before you write your implementation code. Counter intuitive when you first hear it, but after you start doing it, you ask yourself why you haven't done it all these years (well, aren't most great ideas like that?)

The benefits are obvious and also not so obvious.

1. Big picture thinking. As you write your test case, you start thinking more about how your application is supposed to behave. You start catching gaps in the specification well ahead of implementation and integration.

2. Test coverage happens automatically, since unit testing is no more an afterthought - test code is the fist thing you write. By the time you are done with your application, you are left with a test suite that covers every line of code that your wrote.

3. Effective multi-tasking. Most important but not so obvious, TDD helps the developer focus on one thing at a time and there-by multitask effectively. Good multi-taskers possess a knack for dividing their time among multiple tasks throughout the day, while giving their undivided attention to each single task when they are at it. The challenge, where most people fail is in dividing tasks into small enough and un-ambiguos units, with un-ambigous results. TDD, I've found helps a great deal in this. Each test case defines an unambiguous unit of work, with an unambiguous result - the test either passes or fails.

4. Context switching. Another not so obvious benefit - even if you are distracted during your work by something urgent and you pick it back up hours or even days later, you know exactly where you left it by simply running your test suite and checking which test case is failing.

For a detailed reading on the subject>> http://jamesshore.com/Agile-Book/test_driven_development.html

Thursday, 25 August 2011

The good mentor

As people move up the management ladder, mentorship becomes a very key part of the job description. Invariably, it gets attached to their goal sheet and targets. While this focus is good to see, I often feel that somewhere a fundamental aspect of good mentoring gets missed. It is that a good mentor has to be selfless. Which to me means the following things.

1. Putting the interest of your junior ahead of yours. If your mentee fails, then you take it as your own failure. You stand up and take the blame.
2. Don't mentor someone just to meet your own "mentoring targets", but because you genuinely want to bring someone up to your level. Your meeitng your target or not is simply a by-product.
3. Be patient. Spend time, teach, guide, show the way sternly as you would do to your own son or younger brother. But if you see your efforts are not bearing quick results, don't lose your patience and give up on him or her. Try again. Maybe you are not doing it the right way.


Saturday, 17 April 2010

Perception, Visibility, blah and blah

Years back, a colleague remarked during a casual conversation that "it's all about perception management". It didn't somehow seem right then, though I didn't know exactly why. I thought I'll learn to accept it with experience. It didn't happen; now I think I know why I felt it was wrong.

Perception is just a by-product. If you are being perceived wrongly, then

a) There is probably something wrong somewhere else that needs fixing first, perception will automatically happen.

b) The perceiver is wrong. And in this case, there is nothing out of the way you need to do. There is a school of thought that tells you need to go out and manage the perception of the perceiver - to which my answer is - it's nonsense, and it's not worth it.

So, please, do not let people tell you that you need to manage your perception. Fix the real problem, if there is one. If there isn't, just stay put.

Friday, 19 March 2010

Incentives - again

A true performer is driven by his passion for duty - not the fear of losing or gaining carrot at the end of the stick. How then to reward such a performer? Because, he definitely doesn't work for that carrot...or does he?
Your comments please:)

Sunday, 14 February 2010

The selfless midfielder

The most effective team player is often someone who is prepared to spend time and effort for others in the team - not expecting anything in return, but for the sheer fun and personal satisfaction he or she derives out of it.

This may sound high, but I've felt this is something that makes a lot of practical sense. This is how I think it really works:-

1) The more you help others, the more your expertise grows, simply because of the breadth of problems you get to tackle
2) The more you help others, the more you get it in return (not that people keep track, but, what goes around, naturally comes around)

Consider this - 5 out of the world's top 10 paid footballers are midfielders.