Control Vs Empowerment

We all are control freaks.. Yes I mean it.. We all are born to be control freaks.. We need as much control on things as we could get, no matter what you are doing. Don't agree?

Ask the Finance Minister isn't he controlling the economy?
Too far? Ask the Finance Director of your company for that extra dollar and see what and how he reacts?
Everyone sitting in any chair is a control freak.. for Good or for Bad.. they want to control, We want to control.

Anyways... the point is not to tell who is control freak and who not.. The idea of the post is how do we know if we are control freaks...

I had a discussion with Ani a few days ago...during the discussion he said that when 2 people get into a discussion, 1 person tries to dominate the discussion and the other gets bullied.. How would one have a fruitful discussion in such case? I agree... I have seen Managers going into discussion and not letting scope to have a discussion, result a unsatisfied orator... A meaningless argument, a odourless debate..

One of the major issues with several managers is that they think by controlling things they can do what they want to get done or vice versa... I dont believe so... A few months ago my kids were pushed into swimming classes.. the fear of drowning into water resulted in lot of yelling and crying when the tutor tried to get them even into knee-deep water.. Several attempts made to force, to throw them into water , to shout at them and to punish them to get into the swimming pool did not get them roll there hands and legs in the pool. Surf pads, floaters nothing was helping.. The tutor then caught a simple way to get them in... they were made to lay on a water bed where they could float and sleep.. a couple of days the water bed was pooled out without air and they still remained calm in water, a few days later they chose a double floater that would float them no matter where in water they would stand.. the fear started vanishing, confidence grew... result they started swimming.

The lesson I learn from this was simple...

The moment you try to force your or someone else's wish onto others it drives a human being to think that it is control, results in resistance no matter if it is for good or bad for them.

Control also has a very short life( Watch movie Matilda).

Control creates unhappiness.

Control drives dis-comfort.

Control invites dependency and troubles

Control creates arrogance

Control stalls growth

So how to not control?

Discuss

Suggest

Ask

Debate

Never impose

Never force

Never be pushy

Enable to make decision

Help in understanding facts and making decisions

Back up and support pre and post decision period.. no matter what the result is

Learn to listen, Learn to adapt to change

Learn to hear out

All of this will help the person do things you want him to do, on his own, realising the objective and trying to achieve the same goals... Yes that is what is Empowerment...

Control would fail, today or tomorrow... Empowerment succeeds always.

Read More

Where is your SWAT Team?

2001-02 While working with the organization I was working then, We faced a very critical issue. We wanted to work on a stronger road map for the product then and were always back pulled by issues around the smooth execution of the production systems, customer issues and rants etc etc. Every time we started working on the development windows we were pulled back either by down times or customer requirements , issues.

This hurts the road maps always and badly. A new feature would be compromised to an issue that the customer wants urgently. We killed almost a few important months of your roadmap that ways. The moment it was decided to have a dedicated Team to handle such issues... We formed a first unit of 2 Development engineers, dedicatedly working on critical day to day issues. Issues that were raised by customers and were urgent. Issues that needed quick response. Effect was, in 3 months time we were able to add up things that we were not able to get in 1.5 yrs.

The output was clear.. A dedicated Team working on second line issues and customer client issues is always a gem. Very Very High ROI.. because the Team actually sets to become the domain experts due to the variant area exposures.

We did the same thing in the organization we worked, in times of high delivery pressures and low Team sizes.. The SWAT Team we named it after (Special Weapons And Tactics). All through the last few years it has helped us balance our Teams and resources and Knowledge about the product. To that matter even the Trainees got to become the member of SWAT and got control on the product. we made our mistakes by pulling people from main stream development

Now this was us. How about you?

Do you shuffle your resources from your main stream Teams just to get some immediate issues resolved?

Do you focus on customer immediate issues than product future?

Do you compromise critical features for urgent customer issues?

Do you believe that your development Team produces much slower than it should?

Do you believe that your velocity is bad?

Well if any of the above questions go in a YES, Boy think over and find where your SWAT Team is.

Such a dedicated team to support urgent issues helps the product move forward. It is always in my experience that when development teams are shuffled in tasks it kills creativity , performance and of course above all the frustration that the teams face juggling tasks and work every other day.

If you dont have one .. Go find your SWAT Team

if you got one and abuse it ... Reform

Read More

Minimum Viable Product, Need for today, Necessity for tomorrow

Every one wants to launch it big, hugely big. A hype, A marketing base, plans and communications , blah blah blah.... in an attempt to make this big.. there is always a lot of bigger effort spent.. the bigger the effort the bigger the issues. Thus bigger your first version, bigger the problem. A while ago working with my current organization, I saw that the Team decided to build something new.. a shorter / mini version of a content management system, more robust , more architecturally strong, more envisioned. Perhaps the first version was a very very primary version.. a version that would just do the needful. There is no doubt that it was hugely successful. Bought by a major giant , having some real cool features, and scope to add new things in near future. All of this went by because of the simple and pragmatic approach was taken "Build what is atmost necessary".

We learnt, a bit late but we learnt it hard and well. We now start to work on a new feature addon to the system, A feature that would change life of the system and usage and sales and future. So I decided to ask this question to those selected few who are key and critical developers.... My question was

" What should we build? A Elephant or the sledge runner?"

The Team threw up all their ideas, brains and pros and cons.. in the end they concluded that the smaller they start and make it available the better they can make it for future. Experience backs it well. Define the minimum needs, instead of acting greedy and building everything in once. Avail the real-term feedback and then improvise. Define what is minimum instead of going with "Customers want this" because in the end customers dont know what they want.

Thats what Agile says, isnt it? Build in small phases , deploy regularly , get feedback and improvise?

Then came another question...

"How to define that Minimum of the Minimum Viable Product?"

A tricky question. I am sure this needs a better thought process than just a definition of X, Y and Z items. Its a iterative process that needs to be defined, Ask the question "Am I there yet? after every few days when you are defining the requirements."

I remember we did a documentary a couple of years ago... We started with a script that was conceptualised to be a city tour, it turned that we needed a proper theme to get attention of the audiences. We changed it. Then came the phase where decided cast of the documentary, we thought its too much, we changed. In iterations we went on and on to make a minimum script that would help us make a small piece that we could show others. As we progressed, we changed a lot of things based on the feedback that came out of the process. In the end it turned out that we were closer to make a commercial drama to make what it needed "Gather Audiences, and Get Applause". I know thats what they do with those Hollywood shows and movies.

A lot of times we make decisions driven by demands and not needs. MVP techniques you to help build a basic expectation first.

So when you plan for a feature, product ask your Product Owner on what is the MVP of the whole thing....

More on Minimum Viable Product here

Read More

Why Feature needs a owner?

We usually think that the Product Owner owns everything associated with the Product... though in a broader terms this is OK... in reality this is a big headache.. specially when your product is getting bombarded with new Features....

In past I have realised that some features get built without thoughtful thinking and in attempts to tailor make the usage those features become a headache.. I once read a tweet (Don't know the source or remember the twitter-er) "Feature is like sex, one mistake and you have to support for life time" . Features need thoughtful thinking.. but more than thoughtful thinking it needs a owner... you may think that depending on the stages of the feature in development it can be owned by different people, theoretically this sounds Good... practically I think the approach has to be changed... You cant have different husbands for a women based on what stage your marriage is, isn't it? Similarly, Features need 1 owner for its lifetime... yet multiple people who support it in various phases..

So when someone says The Feature owner is :

• Product Manager : When the Feature is Ideated :
• Business Analyst : When the Feature is Documented :
• Project Manager : When the Feature is planned for delivery :
• Developer : When the feature is developed :
• Tester : When it is tested :

He/She is getting rid of his/her responsibility... The feature needs a owner and it needs 1 owner.. So why is it so?

1. If the feature is not owned.. it will be driven by some customer who thinks its the best way they can have it and fits to the best of their requirement....

2. If the feature is not owned : Developer will develop with his own ideas.. and though it will be pragmatic to the product it may technically be a disaster to extend the feature...

3. If the feature is not owned : It will be directionless... I have seen features not reaching its end..they go on and on and on.

4. If the feature is not owned : It doesn't have a legitimate customer, everyone wants to use and mould it in the way they like

5. If the feature is not owned : From the beginning to end it is going to be a disaster.

So how does one own a Feature:

1. When the feature is ideated, think over it. Brainstorm the idea with tons of people.

2. When it is documented , get it reviewed by customers, internal users, everyone who is somewhere associated with the product or feature.

3. Discuss the wire frames and usability with people who would use it and who wont use it.

4. When in development phase, have a look at it every now and then.

5. Test , Test , Test and Test when the feature is in alpha, beta or UAT phase

6. Brainstorm the usage and usability with testers.

7. Promote the feature to be used by customers.

8. Enhance the feature , think about new addons to the feature every now and then.

Though these things look pretty difficult... if it is made a part of strict rules, the feature will benefit diamonds out of it... Finally what benefits is the product...

So who in your Team can do this? Who in your Team wants to take the ownership to make it successful? Remember its not just the Product Owner... Its a lot of you if you are closely or farely associated with the Product.....

Comment if you disagree?

Read More

My Love for IE6 - The reverse Truth

Oh well... we crib and shit on IE6 so often. We blame and blame IE6 so often.. the issues we face as web developers working with IE6 are sometimes nasty... We change for 6 and then it fails for IEY and for Chrome and for FireFox A.. woof... so much of pressure in these browser wars.. so while our friends at Chrome and FireFox and Opera are making our experience better.. we still have IE6's to add to our sufferings... But how can I forget the good old days IE6 gave us... A small poem that demonstrates my Love towards IE6... In a Benjamin Button way ;)

Oh! Dear IE , When will you die?
Everyday I see u, I feel to cry!

Oh! Dear IE, When will you Go?
See the thought within, makes my face Glow

Oh Dear IE, its just about time.
We wasted our efforts and paid every dime

Oh Dear IE, I love you anymore
My upgrades are freeze and apps are sore


Oh Dear IE, don't feel bad
I know once upon a time, you made all other browsers look sad

Oh Dear IE, you were once a hero
You had your days, when in hearts you were Zorro

Oh Dear IE, you made web look so cool
And all the happy developers life was easy when they just got out of the school.

Oh Dear IE, I know you will be the best
You have just came alive and in coffins are the rest

Oh Dear IE, I envision you rule the world,
You will fly very high and be a free bird

Oh Dear IE, the world is waiting for you,
When will web be fast, they got no clue

Oh Dear IE, the maturity of browsers sucks
I hope you get Ideated and let us make some bucks...

Now that I wait for you again.. I hope they listen(I wait for IE10)
Instead of sending another a bullet version, they make you a piston.

Wow... Life and love with IE... I hope it gets better

Read More

Innovation and confusion models

While All my blogs are driven today Innovation and I get queries about confusions around Innovations.. I thought let me explain the different models different companies use to drive there Innovations... Well these are my definitions of it.. but I am sure you would understand that a lot of companies follow there Innovation models in these 3 categories at a higher level...

The Revenue Model :
The model where Innovation is directly linked to Revenue.. here the innovations are made to accelerate the companies growth and Innovation is purely driven by revenue model. E.g. Apple Innovations are driven always by a revenue model.. the Innovation comes on sale immediately after it is out.. Most of the time they are General.

In this model there is less scope of mistakes.. hence u see miniature bugs in Apple products (ignore the iPhone4) when they are launched.. of course no customer wants to pay for bugs..

The Trial and Error Model :
This model gives the Innovation to the word usually for free, initially maybe.. it is left to people for feedback and then once it matures based on community inputs and feedback it takes a better shapes.. I find most of the Open Source projects or even Google fitting into this model. See the examples of Google Wave , Orkut new UI , Buzz?


The Close to Object Model :
This model really drives company that Innovate only for there needs.. These innovations are more driven by internal needs than customer demands.. they are thoughts of 1 or more people who bring it to ease up jobs, they are no pure innovations but instead replicas to cater different needs.. Though these innovations have a certain value they don't have scope to become ultimate Innovations. I feel Yaawhoo falls under these category.. e.g is when Yaawhoo meme was introduced i feel it was a copy and not a Innovation. Yaawhoo Maps, Shopping etc

So what model does your company follow?

Read More