Wednesday, 14 December 2011

The No Whining Zone

How much of negativity do you see around when you sit on your desk? How much of those vibes hurt your development? How much it affects your moral and productivity? How much you start whining yourself? I am sure, answer to a lot of these questions are not known to you. A lot of us basically dont even notice or consider the whining around to be actual whining. For several reasons whining in office spaces have become the basic necessity and believe me you would certainly see moral and attitude troubles in places that are whiner-land.

So what and how does this whining affect us? I recently happened to visit a Travel agent, a small office clubbed with around 8-9 people who would help the clients book hotels, flights etc. I wanted to get my vacation planned with them and since the tour planner was running late I got a chance to sit in the crowded place. A few moments I noticed that that the girls around were talking, I could not avoid over-hearing but they were cribbing about phones, about customers behaviours, about bosses, about people.. during the same time they chose to have their working lunches and I noticed the whining increased in mercury levels.... there were arguments, complains and raised voices... huh.... Before I left the office I asked my planner on what was the issue with the girls working there, he said they have several and sometimes they just crib about everything..

I realised if your office space is a whining area.. where people choose to do nothing but complains.... you are soon de-moralizing your teams, building wrong attitudes in people and of course affecting your over all growth and productivity. Whiners spread there magic like fire and when they spread the negativity they dont care where they do it, how they do it and who it affects.

In today's era we all are burdened with a lot of work, deliveries, quality, customers and deals. Hence we all need that sympathy soul who can hear us out... most times whining is done to get away from responsibility or blame others for things not happening. A engineer can whine if he is consistently working hard on deliverables, if he see's not so good quality work coming to him, if he sees issues in the work place, if he notices any troublesome factor.. sometime he will wine if he see himself working more than others, if he thinks he is paid less, if he thinks other companies pay better and the list continues.... all these situations and talks happen in work desks, passages, smoke area and pantry rooms.

The Book Whining : 3 steps to stopping it before tears and tantrums gives a superb view of different types of whining that happens in a house, family. But it is not bad to link it to a workplace where the effects are much broader and affects bigger audience.

So how do we create the no-whining zone in workplace?

1. Make people accountable.. if they know how to take responsibility there will be lesser reasons to whine.
2. Make people responsible, if they know their responsibilities well there will be less reasons to whine
3. Suggest people they talk positive.. Unless they speak good things about even the worst possible elements there wont be those negative whining vibes.
4. Suggest people to have smiling than frown faces.
5. Put boards across office asking NO WHINING PLEASE
6. Create whining zones which are distanced than the work place and people can be noticed... it is important to let the whining not affect regulars or the motivated.

Last but not the least... whining is a problem.. try to fix the issue that matters... changing whiners is a difficult task.

Make your workplace a fun area not a whiners paradise

Thursday, 14 July 2011

We love Unhappiness? Do we? Really?

One thing I have learnt in my 32 year life is that humans are most insecure, dissatisfied and whining fellows. We just don't know how to be Happy or rather we just don't want to be Happy. I mean a few days ago I was playing the Age of empire, a strategic game. You build farms, food, infrastructure, you build your empire, make friends, allies and what not. Eventually after I spent around 8 days building a good set of empire, I started feeling uneasy, I decided to build an army, I wanted to grow my power, money and designation in the game. I was unhappy about them and I wanted to do more... In turn I made a few allies, attacked others. Huh? Tension grows.. wars, battlefields, blood... Darn it, even in a game? One can just not stay happy.

No??? tell me one game you have played that where you are happy and you keep playing? Lets take caveman.. once he is reaching his destination after playing all those difficult levels.. the Game ends... For that matter even the movies... it starts all good, romantic then some blunders and unhappiness, sadness and then the moment you get to be Happy the movie ends. Huh?

I think we humans are trained to become unhappy :). OK OK.. I am not teaching you about happiness here. Last when I wrote about Happiness quotient I emphasized on this part. In fact when I asked the question If I am happy years ago, I learnt I tried to be one. Well we spent most of our times at work, and hence work plays an important role in our happiness.

A few years ago the place I worked got me the experience of happy and unhappy people. I still remember the lessons and I have to say I am happy I learnt them. A few days ago I overheard someone whining to others about morning, traffic, day, office, parking, work, salary, job, role and I don't know what not, it made me feel he/she was not Happy. Since I wrote in my previous post about it, I asked the person what is it that is keeping him blocked? Why is he/she not able to enjoy work, be a part of the momentum or create one? I guess the answer I would say as for all whining lords was missing.

Unhappiness is an attitude, that gets more and more deeper into you. The more time you stay unhappy, the more your attitude turns ugly. It reaches a level where you have no turning back. I think over period I have realised that several companies spend their energies not in making their workforce happy... they spend there effort on working to not have them unhappy. The later is disastrous. I have experienced it, the more you try the more it grows, because the one's that are unhappy will always be unhappy. But don't get disappointed some psychology experts have figured out that Love can help improvise the situation.


Ask yourself, your teams, people who surround you to answer the following questions and actions:

1. Do you love the people you work with? If not what will make you love them?
2. Do you think the people you work with love you? If not what is it you think can make them love you?
3. Do you love what you do? If not what do you love to do? and can you tell the people you love on what you want to do?
4. Do you enjoy what you do?
5. Do you tell what you are unhappy about others?
6. Do you tell yourself what you are unhappy about?
7. Do you like to admit your mistakes? Do you like to improvise?
8. Do you think love can make a difference?
9. Do you love to be happy? If not unhappy? insecure?
10. Do you enjoy love and being loved?

Ask these and a few more, confront, talk, speak, learn and yes Love. Happiness at the place you spend most of your time is as important as oxygen. If you cant be happy and you have not made any efforts to be happy, you maybe on the path to be a whiner or a looser. Lets change path. Lets find ways to be Happy with people you are surrounded with.

Wednesday, 13 July 2011

Are bugs hurting your backlog?

I ended up in a discussion with the team last week on how bugs cause a unmanageable link to the Technical debt. The debate was how should bugs be treated. my argument laid with bugs that hurt the current development and the future backlog. As a agile team a product backlog is key driver in defining what we do for in every release, the known unknown here is the bugs that are generated out of the current development. Let's say your product backlog is 200. If your team of 10 is burning say 100 user stories in a release of 10 days we can say that the velocity is around 10. But if in the same situation your team is burning 100 user stories in 10 days and creating 20 bugs that take 5 days to fix, your velocity is dropped to less than 7 + on the release day your backlog increased from 100 to 110 say a 20% increase.

Gauge the effect bugs can have in your system. Now go a bit deeper, assume you can only only resolve 10 of the 20 bugs in 5 days. The other 10 bugs go sit in your product backlog. When you cant get them in the current release and put them up for the next they take 20 days to resolve (Due to the time spent in between it no longer is hands on) your velocity rate with the bugs regards is then 100 user stories in 25 days (Just around 4?) Now if these 10 bugs are mapped for a future unknown release???? The technical debt it had created can be high, very high and would lead to say 10 more bugs getting created [causing you 8 days or maybe 10] your velocity with regards has now gone to ?????? less than 3 and forget about the qa and discussion cycles, customer unhappiness, quality quotient. Your product backlog spanned to 120 which is 20% more than what you expected to burn.

So next time when your release user story is generating a bug, go shout on your developer and tell him/her that the bug is a part of requirement and when you go live you want the feature to be done, not debted.

Obviously for those "Think Realistic" atheists this wont sound good. But remember your product backlog is piling up with the bugs, your velocity decreasing, your debt increasing and your cycles of qa increasing... in other words nothing in favour of better product.

What do you do to bugs that get created from your development bug and found during the release?

Wednesday, 6 July 2011

The Art of un-informing

Yesterday my day started on a bad note, heard news of passing off of my father's aunt (grand mother) and had several production issues that were waiting for me. During the funeral I realised that I had missed to inform at work, and by the time I did it was probably too late. Bunch of calls and last minute meeting cancellations. I can imagine the frustration it caused others.

I couldn't stop thinking of it and hence about writing on it as I know it hurts not just you but everyone else. Over the last few years of my managerial experience I have learnt people fall into 3 broad categories :
1. Who intend to not inform
2. Who misinform
3. Who inform.

You would always love the 3rd type, You worry about the second and you hate the first. Today I write what hurts us Managers the most...The first lotte

"I couldn't come to work yesterday, Were trying for a baby and the doc said yesterday was the best chance."

Well I am sure this doesn't sound that unfamiliar? You may have not heard something like this but the types that intend to not inform are the types that make such excuses. The "I don't want to inform" types intentionally leave the information out for various reasons as follows:

1. Fear : Fear of leave getting rejected. Someone who makes an excuse is still better in this regards as he/she doesn't leave you in jeopardy. Fear of facing a rejection of request, makes such people do this. Some times it is also the fear of what the Boss would say (About lot of leave, Performance etc).

2. Ignorance : Sometimes this is just done out of ignorance. I remembered a friend of mine who worked on a collection counter for a government office collecting last minute penalties on property taxes, never realised that people have to face a extra buck if she is not on her seat.

3. Get Away attitude : A lot of them think that if no one remembers they can easily get away. This is the most hurtful of it.

The big issue with this type of people is that it brings you into a big crisis at times, and they never realise the importance of informing because they get away one way or the other out of the crisis issue. How do we fix them?

Well honestly there are several ways... lets put this in a funnier way

1. Make them feel what they just lost: I remember once I had a team mate who was really fond of some specific type of food. After noticing that he deliberately not informs the team about his absence we a couple of times had indoor lunch / dinner on the day he would go missing.

2. Add the surprise : Once a friend of mine who is a manager bought printed old passes of the person who would go uninformed with passes to a rock concert followed by an invitation for dinner with the popstar. Of course it was a fake one, but it kept the person pinching for his life time.

3. On a serious note : First time itself it should be informed. If they get away once they would make it a habit.

4. Punish sweetly : A little embarrassment can do.

I am sure you might have faced this and handled it.. what are your ways? Do share....

Friday, 24 June 2011

Things to Know - Who owns the Technical Debt

A fresh release for us is due next week, have to say it has been put up with a serious effort of around 8 months with a lot of hard work and agility and comes with a lot of development contribution that is beyond coding and testing. Now that we are almost there, I have been reviewing the bugs created by our test team, ran an eye on the code to check through the code quality, ran on de-scoped features, made a list of items we could not do for several reasons. Going through this one thing kept on reminding a discussion Me and Savio had way back in 2007 when reviewing code for another product topic was "Technical Debt". For those of who are new to this term technical debt is the leftover or unfinished things in your development work [precisely a product/feature] that links to documentation, design implementations, re-factoring, coding. In other words if you choose to finish your product faster and in a messy way you leave a big technical debt behind. The day your development team starts saying that X things which probably is a small feature will take more time, snap out that you have some technical debt on you.

Technical debt is similar to financial debt, the only issue is it is not measurable in figures. You can find how much you owe to someone when it comes to money/interest, but with regards to a Technical debt its the price the entire Team pays by putting additional effort to do some basic things. Technical debt is caused by Deliberate Motives or Ignorance, though the quadrants may differ you can broadly say that technical debt cleaned earlier the better...

Typically deliberate technical debts are caused by

1. Lets do it now and we will see whats the impact later
2. We need to release this by X date
3. Put a todo list and we will revisit it later
4. Not now
5. Its too much work

Out of Ignorance causing technical debt can be serious..but usually you would see it happening due to skills and comes from freshers unless you don't have good technical resources. Many a times technical debt created out of ignorance comes due to the fact of ignorance in writing code, unawareness in knowing the best definitions of technology and language or available design patterns that can be applied. A lot of times ignorance is caused due to skill and understanding too.

Whatsoever said.. You can know your technical and the severity of it by :

1. Counting the number of bugs raised once the development build reaches the QA.
2. By the amount of effort your team spends on adding features to the developed items.

Eventually most in disciplined teams do not care about the technical debt, they live for today. Letting the code die a cancerous death tomorrow. This is another reason you would never find a owner for repaying the technical debt or someone who works on it in such teams. Of my discussions with Savio and have seen him work I have a few traits identified I think I must mention them here;

1. Everyone in your team owns the technical debt; everyone hence should share it and repay it whenever they can.
2. Code review ad-hoc times apart from the stipulated and process schedules.
3. Add TO-DO lists and log them into some place [Wiki / JIRA] so that they can be put in a roadmap sometime.
4. An Architect defines the technical roadmap to repay the technical debt.
5. Product Module owners have to visit and identify what needs to be done. The lazy bone's should be thrown out of the process.
6. Re-visit code based on the bugs raised to ensure priority is given to severity
7. Value the quality, talk about it to others and show them how to execute it
8. Every release should have at least 1 technology effort put up. This would be one way to encourage new joiners to contribute in quality efforts.
9. Project Management should be introduced to technical debt earlier in the project.
10. Introduce group code reviews and multi code reviews randomly to find and fix the needed.
11. Prioritise your debt; keep it listed and updated. Know it to fix it.

Certainly if you have more than 1 code owners in your team, who value the size, quality and robustness of your code base, day is not away when you will have a highly qualified code base that can do best to your team. Question to ask yourself:

1. Do you want to invest in creating these owners?
2. Do you believe that technical debt is killing your product?

Thursday, 23 June 2011

Development : What does Quality mean? - 2

Continuing our efforts on working and understanding quality let's now focus on the other side of quality for developers and development teams. What we should do before, after and during the development cycle's is the bright known side of the coin, but to be honest you may be well equipped to write the best products, but quality is not just ensured by writing very good code, planning better, reviewing.. there is another aspect of development that one should consider, specially for development teams. As a developer in my career I felt the need of some of these several aspects which were just not about programming but affected quality in several senses and ways...

Here are those other things that should be avoided / done to ensure development sticks and values quality..

Enjoy Coding, Love Programming,Live Development
It's not the same for those who think it is there are big differences. Coding is about putting syntax together to make something do what is needed. Programming is more complex, it is putting a design in place to get things work in the way they should be.. Development is about bringing a lot of pieces like coding, architecting, designing, programming, analysis, testing together. If you think just writing code is making you a quality developer, you are wrong. Get your gear up for the later..

Find your blockers first
Many of developers don't know what blocks them from doing quality work. Over years I have come across so many factor's that affected quality of developers work from silly to serious. Years ago I knew a developer who consistently wrote code which had several review comments, upon asking we realised that there was a clock placed right above his desk that would tick every second, give an alarming sound every 30 minutes, this would distract him so much that he started to put his focus on it.. funny? Meetings, Noise in the workspace, sitting arrangements, external sources like people walking in and out, people calling loud, ring tones etc make it difficult to concentrate.. obviously long term they start affecting what you do.

Find your Rhythm source
Some find music to bring them to rhythm others just a quite place. Each developer needs to find his own comfort space, and this comfort can yield focused effort, in turn support quality in work.
Stay Put
Focus is important. If you cannot stay put at your work place, you are more likely to be distracted by yourself than others. Obviously you are going to spend time doing things than finishing work that would result in slogging in the last minute to get things done. Obviously quality is the victim.

Garbage Collection is not just for Objects, for developers too
Many of you from technical world might know this term for those who don't.. it is a systematic recovery of stored resources used by your computer program that it no longer needs. Developers if understand that they put in a lot of thought in several things and they should have ways to recall some of that energy , thoughts spent in right time to un-exhaust them. This is just not about taking a break from your desk.

Google is not the only source
95% of times when asked to the interviewed candidate on what is the source of his/her information I got the same answer "Google". If I was a Googler I would be pleased. But as a Technology person no more. If a search engine is your source of information you are starting from step 1 and drilling down to where you want to go. In general terms Google is a right thing.. but is Google the only source?

I remember of StackOverflow, Experts-exchange been the general forums I referred to, Java ranch and Sun Java forums for Java, Quora for general startup things, Mashable / Techcrucnh for tech news etc..But are these not important sources? I have a list of 80 Delicious items that I know I visit every evening. depending on the last update index. You need to find the right sources and should turn to Google when you need it hard.

Make Forums your homepage
Forums... everyone wants to ask a question and get an answer.. but tell me, How many of you really give that answer? the quality of a developer improves with his contributions to the forums. Just reading and learning without contributing is shit. You may not be a good writer.. but if you share you learn, you evolve, you would unlearn and you would re-learn. Have forums your home page. See what industry or technology is facing as a challenge.

New Technology is a mirage
I have heard form many that knowing new Technology will boost there careers and help them write more performing, more scaling, more robust application. I am sure if you think that way you have not tried enough. Moving to a new technology is good. But the first attempt should be making the current one be good. Most guys who I found fascinated to change architectures with New Technology without sane answers are the same guys that would give excuse of technology limitations to do something.

Unlearn , Relearn always
Do you? If not start doing this.. A long ago I learn using java.util.Vectors was the best way to manage key/pair values. Unlearn things occasionally to re learn them in a better way. Now I know it is not. There are better options available and can be used effectively. This just doesn't apply to technology, just generalise this.

Yet again, I am sure there are many more things that will help you improve quality of the development process and what you develop. Point is.. The most important thing.. do you have a WILL to be a quality person, a quality developer, a quality craftsmen?

Wednesday, 22 June 2011

Development : What does Quality mean?

Let me begin by saying quality is over-rated and under utilized, under practised and over spoken. Most people do not understand the core meaning of quality.. for many quality means a bug free software, for others quality means anything working as expected.. it may be combinations of it, but been into Software business for more than 12 years I have understood that quality is a phenomenon that evolves and makes your life better. But anyways we are not talking about quality in general... let's begin talking with our focus on development first....

The prime element of a Software engineering team is the strength it posses within it's developer community. It means that these craftsmen who build the future of companies and the technology world are really really valuable resources. Now these craftsmen who build important innovations and structures are the one's who are most likely to define the quality of their art (Software they produce). Question is.... do they really understand what quality is? How to maintain it? Is better coding referenced as quality? What needs to be done to imbibe the valuable quality factor in the development?

I am sure there are lot more questions and dignified answers and clarifications to each of them with several more additional questions... When the development starts for a product, a project or a task there are a few things that your developer community needs to follow, understand.. if they don't your job will be to make them do...


1. Do understand the requirement
Superficial if talked about clarity of requirements??? It may not be well defined... yet it has to be understood and brainstormed... well you are right. You as a developer need to understand if you know what you are developing, for whom, when it needs to be done and why. The more clearer these answer's fall for the developer the better chances that the art will be fine...

2. Refuse
You need to refuse any demands of writing bad code.. I remember once asking a developer to produce code with some missing quality, in turn I got an answer "Do we need to build a baby with Polio?" You need to realise and make your team realise and hence refuse bad quality outcome's, un-realistic demands.

3. Define what?
It's important that you as a developer get an answer on what is the basic thing to be done, anything that is nice to have should be out. First get a primary list of what needs to be done. A feature list plays key role with importance and severity.. You can F**K the priority here.. I hate using that, because hardly few people realise priority is at the front end.

4. Can and Should
If you can doesn't mean you should. In the last few months I have realised that WE CAN is/was understood as WE SHOULD.

5. Pick what and when to do
Decide which features you would work on and when you will work on them. I know how much it sucks to work on a programming task when you have a severe headache... I remember Henrik (One of our UK Team members) saying... I am writing shit since my head is having a Diarrhea...

6. Choose your tools
Development IDE, Code repository, Integration tools.. All these help, review plug ins, code review tools etc.


1. Spend time sharpening your axe, not cutting the tree
Spend more and more time understanding the requirements, architecture, spend time in planning and designing than just taking up the task and coding. The more sharper your understanding the more faster you will write the code.

2. Test first, write next
First put your tests in place then write your actual code.

3. Do what is needed
I have seen many developers complicating the development process by throwing various discussions, scenarios, technologies and dependencies under hoods of unclear requirements, dependencies, technology limitations etc... do minimum of what is needed.

4. Keep it simple
Easy said than done. But try to write code that is understandable.

5. Document when you do it
Before you forget, write the code as you will die tomorrow and your son's bread and butter is going to be on the program you write.

I heard this very often. There is no first cut implementation of a feature... there is either a complete feature or a buggy feature. Write a code that completes the feature not just creates it...

Enjoy the work
If you are bored take a day off
If you love to work in a dark room, find one.
Set yourself into a real mode..

1. Review
Review your code, during the development, after you are done with it. Peer, colleagues, techies, experts.. just get anyone who can help review your code...

2. Re-factor
Re-factor when you feel it is necessary. Listen to the call of your developer inner soul. Re-factoring is like oxygen pill to the code, give it as much as you can.

3. Test Blind
Test like a end user. Don't wait for your testers or customers to find bugs for you. Reward yourself if you find a bug.

4. Re-visit
re-visit your code..whenever possible.

Well this is not it... as a development engineer the responsibility you hold is very critical and crucial... Quality has a broader meaning and as developers you can ease life of lot of others... in the end you are real Craftsmen not Robots producing some replica's

Monday, 20 June 2011

Things I learnt about Project Management

1. Managing one’s wants is the most powerful skill a person can learn
2. Projects success is dependant on executor's attitude's and not just effort
3. Budget should be the last thing to think of
4. Planning is over hyped, under utilized
5. The only time quality comes into action is when you are not reviewed
6. Manager's like engineers who fix things quickly.
7. Between the release date and code freeze lot of bugs are raised, requirements changed.
8. Requirements are changed like clothes (everyday), schedules like attitudes (never)
9. Lines of code fewer the better
10. Those who complain the most, accomplish the least
11. Features have incomplete requirements even after they are delivered
12. Agile becomes an excuse to not follow processes
13. Code review should be scheduled like checking emails are
14. The guy who writes the worst piece of code, is the guy who is more concerned about quality
15. Scope, quality, time and budget never meet at one point.

Many Many more, coming into phases.. What's your learning's though?

Friday, 17 June 2011

How to find an angry employee

Do you have an angry employee at work? Do you know how to figure out one? Well here are the quickies to start with and with your help we can build a good list here, of course we can then use the list to figure out the reasons and also find answers and solutions to them but let's say that these symptoms don't need to be merely due to conflicts they can also be due to pure unhappiness, unwillingness to co-operate etc, but it's a good start to build one...

usually these symptoms range as :

1.Not completing work on-time
2. Gossiping about work, company, office, Boss, colleagues
3. Not responding to phone / emails / aggressive in language and tone if replied
4. Avoiding the morning wishes and day end see off to colleagues, team members, Bosses
5. Trying to find excuses on behavioral changes
6. Hoarding information that should be shared
7. Complaining , whining
8. Blaming others for their acts, sometimes openly, sometimes in groups
9. Verbal abuse
10. Not attending required meetings, popping up late
11. Uncalled expressions
12. Absenteeism
13. Physical violence

There can be many more small things but they fit into one or the other of them. The type of behaviour an angry employee pick also signifies the mode and nature of conflict/issues. So do you see any angry colleagues? How can it be reasoned out? How can it be solved? How do you turn your angry mates love you? Well a part of the series that I started at How to get loved by your Team can be used in building this solution... So what more do you see?

Working with Talents

I recently asked our leads a question "Who are your Star team members and who are your mediocre performers?" the objective of this question was to put a clear vision on how to map the average performers to be the star team members. I am very sure with your teams you may be facing the same issue, a whole bunch of average performers and a small lot of star performers. Swami called this term "A Pyramid" the top performers are like the tip. Although I have to say that marking talent into various cadres is really pitiful, but you are left with no choice when you calculate the value these talents bring to your organizations. Let's take an example of an engineer working for your team, To ensure that he does what you want him to do you set his KPI (Key Performance Indicators) or Key Result Areas, you define his role and responsibilities, the expectation from him. When you review his/her performance you would realise that someone who is just able to achieve his/her KPI's is termed to be doing average/good, someone who is doing it exactly how you would have expected and maybe bit more is considered to be the Star performer in the big groups/organizations. In this regards most times organizations/managers want people who can just do what is asked with some support/supervision/help. They all form a group called C level talents.

Accessing talents across you would realise that most talents that stroll around project teams in bigger or smaller companies (Not talking about startups) are the C level talents. Most of the C level talents struggle to fulfill their roles and need supervision and help in the fulfillment of their jobs. To be honest most of the C level talents do not know how to do their job well. While excuses of no clear specification, other factors, motivation, growth, capability and skills drive them to be C level talents, they can be worked upon and mentored to be B level in a long run. Most of the organizations that do recruitment through job portals, consultants and web portals really hunt for the C level talent.

B level talents are hard to find.. I have to say they are hard to find in big or small companies (Again leaving startups out) specially because apart from doing what they are expected to do they take an extra mile in achieving more. B level talents drive your teams to do more. These talents play crucial role in evolving processes, outcome's, results and are committed to the future of the organization and growth of the team in all possible ways. B level talents are the initiators to improvise things, they are participative, vocal, hard working and ensure that they contribute in many ways. B level talents have hunger to succeed and want to make a difference in shorter span of time, another reason why you would find a lot of B level talent in startups and Innovative companies.

Now with the above 2 explanations you may have learnt that the real stars are A level talents. They could be the Ninja or rockstar engineers of your team. They ensure challenges are handled, things are done without been asked for, improvisation is inbuilt. They are the real go getter's and are drivers in educating, implementing and executing success for the organizations. They define direction for the teams and organization, products and vision of the organization. However A level talents don't come through job boards they have to be found through their proven skills and by references.

In plain words.. Anything below the C level talent should be made hard to find ;) and startups should focus on making C and B level talents innovate, learn , make mistakes and evolve.

Thursday, 16 June 2011

Happiness quotient, you and work

I had a classic debate a day ago with one of the colleagues talking about Happiness at work. He mentioned that the happiness drivers for him or anyone are good work, good company, good money. When I asked what is replaceable, he said as often 1 of them has to be compromised... Misery eh? So being into a renowned company, earning great money bring smiles to your professional face? I am not sure.. the matrix's of these 3 can be different and have different meaning to different people.. What if you are working for Facebook or Google and doing a shitty job? What if you are working for a very small company, doing great work and earning peanuts? What if vice versa?

Well you cant link your happiness quotient to good Company or money, they are external factors really, they change. I remember when I started my career my happiness quotient always started and ended at "learning's", as long as I was learning I was happy. Things evolved and they tuned to improvise and factors affecting happiness increased..Now 3 things that drive my happiness quotient at work remain to be constant:

1. Am I working with great people
2. Am I working on challenging assignments
3. Am I contributing to the ones who are working with me.

Either of them fails, it hits this quotient,drills distorted view in my routines, creates pragmatic effect on work and professional life. My understanding with the drivers of happiness quotient is fair and simple..

1. If you are working with great people you will learn, evolve, achieve expertise.1 important thing that I have learnt working with great people is that they empower you to do critical tasks, jobs , things that you are told and not told.In other words you can grow leaps and bounds with them. Great people throw challenges at you, make you work effectively and also ensure that you are guided appropriately. Eventually it is great people that make companies good and good companies guided by great people ensure good people get paid well and are happy.

2. If you are working on challenging assignments it means that you are skilled and challenging work enhances your skills. If you are highly skilled you tend to achieve growth as it is an inherent part. Not to question challenging work will show where you stand every time you do it, as if it is a kind of reviewing your skills and potential.

3. If you are contributing to others one way or other, technically or non technically you are improvising your skills and making yourself great within(Teaching is learning again). Everyone likes to be (called) great, contribution to co-workers, mentoring and coaching demonstrates your potential leadership skills in turn exposes your greatness.

Considering these factors.. I happen to believe that extrinsic factors cannot define one's happiness at work.. it is the intrinsic element that drives your happiness. If you really want to be happy at work you need to first figure out what is it that drives your happiness? what defines your happiness quotient at work? Think over.. come back.. let us all know...

Wednesday, 11 May 2011

The Burning platform

You don't know where inspiration would come and strike you.. today it did to me through this post that talks about a memo from the Nokia CEO Stephen Elop . I read through the post and I read through the memo... let me be very honest and tell you that though I would not wish any of your company CEO's to write that It wont be a bad thing to get to read that... With the memo written in the post I don't know what it did or will do to the employees but I am sure it changed one thing for me sure....

It makes me realise that You are always standing on a Burning platform and you need to make that quick decision & decide if you should make efforts to get the platform out of fire or jump in the freezing water and run-away. I was always a fighter and will be so I choose to Fight it back...

In the memo that is very much open and clear the last part puts more ignition to my burning desires...

How did we get to this point? Why did we fall behind when the world around us evolved?

This is what I have been trying to understand. I believe at least some of it has been due to our attitude inside Nokia. We poured gasoline on our own burning platform. I believe we have lacked accountability and leadership to align and direct the company through these disruptive times. We had a series of misses. We haven't been delivering innovation fast enough. We're not collaborating internally.

Nokia, our platform is burning.

We are working on a path forward -- a path to rebuild our market leadership. When we share the new strategy on February 11, it will be a huge effort to transform our company. But, I believe that together, we can face the challenges ahead of us. Together, we can choose to define our future.

The burning platform, upon which the man found himself, caused the man to shift his behaviour, and take a bold and brave step into an uncertain future. He was able to tell his story. Now, we have a great opportunity to do the same.


As employees and leaders each one of us needs to think about how we can do what to ensure growth of the company and not what we feel right... We all stand on burning platforms and if we don't react in individual and team perspective it wont be far if we will be Ashes....Nokia may rise and shine, they have the people , the money , the vision, the force and above all the commitment to their ONLY platform... Do you? Will you?

Thursday, 5 May 2011

Product Roadmaps can be Dangerous

I had a long discussion today with a friend today over products and roadmaps, though I have to say I am not a big roadmap basher myself but I am not a big fan too of roadmaps in the state that they are usually presented. The discussion emerged when my friend explained how much trouble it is to meet the expectations of the customers who are been promised things, specially those visionary things that are put on paper and do not or might never be in the product yet they are promised to those customers by our vicious sales personnel who by now are gone leaving your company to develop something that may not be of any use to the product.

Roadmaps may be beneficial for products, but when it comes to roadmaps not many companies put their thinking hats effectively. I see a lot of issues occurring from roadmaps made public and with this post I would also like to share a few ways on how to cover the roadmaps so it becomes a win win situation.

First lets talk about the challenges a company faces when dealing with roadmaps :

1. Agility : Assuming you created a roadmap for more than a year, and in the middle of the 1st quarter you get a customers who demand a huge feature in your product [Even ready to fund] what would you do? If you have a roadmap promised to world, you are either going to have fund a full new development team or think about going back on what you promised to your customers. Long term roadmaps cause a loss of Agility if not managed well.

2. Your roadmaps work against you sometimes? I prudently remember a few sister companies having similar product lines using X product's roadmap to show how that product is not ready for a specific market and why they should sell Y product only. If internals can have this issue think what competition can do to this. Of course there should be no competition / race internally in an ideal world.

3. You promised X in 2009 but its 2011 and you have not delivered it yet, heard something like this? Well if you sold your customers your vision and how your product would look like 2 years later, you run a risk of facing this. You have potential to make your customers unhappy if you do not present them your plans in the right way.

4. Expectation burden : This is usually the problem. Most roadmaps are done with a specific view. If a roadmap gives you say a 1 year release of a product the expectation around it usually becomes so high that it results in a expectation crusher when the release is actually done.

5. Customer clashes : For small products this may not be the case, but when roadmap's are shared in councils and customer forums, there usually comes an argument that there is nothing in this roadmap that I will be benefited from. Misery?

Well so some of these challenges we have faced, more precisely we were victim to the roadmap concept in a whole. So how how does one really handle this? By saying this I want to say that I don't think you can work without a roadmap. But here are things that can be done to handle above challenges and win confidence of customers, internal staff and provide a better and effective vision plan that can be termed as a roadmap with some alterations.

1. High Level Only
Roadmaps have to be very high level. A view that looks like a eagle view. talks about where the product is moving. Does not detail features at all. Brings consolidated modules together to form complete end result and how customer would benefit from it. A long time ago I had seen a roadmap from a product that is now a revolution in the CRM arena and has become a global force and platform. The roadmap listed customers, expected features, modules the company stratified and how they liked up together.

2. Visionary not time bounded
No April-2011, No Jun-2012.. It should be purely visionary with very high level time lines in years... I know it is difficult to answer if a customer says why.. but isn't it your roadmap? If your customers are asked to push things in they will want every thing in quarter 1 and you will be left crying for the rest of 9 quarters for other customers?

3. Not to all
it should be presented to a very few. Why show it to the world and then apologies if you could not do it for any reasons. We were in situations where bulky roadmaps were released to customers and then when economy had down turns and no development teams to fulfill those roadmaps we had to face the customer anger.

4. Negotiations?
Never show and negotiate roadmaps, if you do so you will end up running behind development teams to change things and behind customers to deal with.

5. Phased
Roadmap should not release bulk modules. Phase them into multiple releases. So if something is not ready by X date you have a easy way to manage it in a year in a phased manner without affecting the customer satisfaction.

6. Compact
Make your roadmaps and presentations compact. Do not bullshit to sell. more than 2 quarters is a problem more than 4 quarters roadmap is a disaster.

7. No Sales
Do not involves sales in roadmap presentations. They buy everything from customers to sell it to them. VP, CTO or Product managers are the right people to demonstrate roadmaps in 4 chair conference rooms with customers. If you are really having a team of attention seeking individuals ask them to present things on Launch.

8. Creators
Be careful in choosing the creators of the roadmaps. The more inputs from the sales the more the disaster. Have a person in this creation process who fights for usability not users.

I am sure there are many more things to discuss to ensure that the roadmap is better and effective and doesn't cause credibility issue to you and your company.

Tuesday, 3 May 2011

Want to learn Agile? Get to the source code

If you are confused with the title No I am not kidding here, and if you are making fun of my knowledge about Agile there are not many better ways of knowing what Agile is than watching this smart movie "Source code". My last weekend was busy, tied with flock, lot of work , shopping and busty busy release. Hence I picked time on Monday night (Yup a school night) and watched the Duncan Jones directed "The Source Code". If you are in India then the stars are not so known lead by Jake Gyllenhaal (Prince of Persia) and supported by Michelle Monaghan (Made of Honour) and Jeffery Wright (The CIA guy who funds James bond in Casino Royale when he is loosing the poker game).

To cut the story and theme you a bit about what kind of learning's on Agile you get with the movie.. the story revolves around a guy Col. Stevens who sees himself alive in a capsule lead by Dr. Rutledge (Jeffery Wright) and Col. Goodwin (Vera Farmiga). There is a system named source code that gets Stevens to life and is planted in a body of a teacher who is travelling with his girlfriend in a Chicago train ONLY for 8 minutes. Source code lets people go in past to find things out [not change them]. The objective of the mission is to get Stevens into the train and find out the person who bombed the train and what are his next targets.

The story moves on Stevens several attempts of 8 minutes on how each time he goes and finds a different clue to find out the next target and find his own identity. Watching the movie was pleasant as flavours of Inception took the movie to a supper height while there was no confusion left in the movie due to fantastic writing. Every 8 minutes spent by Stevens in the train improvises his actions and in turn the result. Just like Agile.. every iteration give you ability to learn from your mistakes, let you improve, help you improvise and of course definitely improve the quality of results...

Unlike in source code where you cannot change the past, Agility allows you to revisit your code and refactor it. Agile is the theme behind source code... though I would keep the climax and rest of the details of the movie hid to let you see it and experience it.. I have to say that Agility is all over... Its one thing that can help you do things better and better.

Design Agile...
Build Agile
Review Agile
Sell Agile

Earn Agile ;) ... I think you should watch Source code if you want to know better on what Agile is...

Monday, 2 May 2011

When should I leave? When is the right time to quit?

There is never a right time, and nothing is ever too late.. You always are in a war of thoughts specially when it is about the thing that you are tied for most of your time.... yes Work, Your Job. Every bad day you have at work or every tiring day you spend once for a moment you have this thought triggering... "Am I doing the right thing being here?" sometimes "Is it time for me to leave?"

With reference to the IT industry and the trending attrition rates, I have to say that most people do not know on the exact reasons why they want to leave or most times do not know if it is time for them to leave or not.. a bunch of last few interviews I did, just refreshed my memory and affirm this thought... There are those passive job seekers who had a few months/years ago posted their resume on some job portal and now out of blue some consultants have started posting and patching them up for interviews, eventually they are forced to look for opportunities.

"I want to change the domain and learn new things"
"This technology is not great and I want to work on different technologies"
"Its too long for me here and the new company is offering exciting opportunities"

Is what you would hear from them when they quit. I don't say these are not valid reasons, I just say that it shows that people do not know if they really want to change or they don't know if the time to change is right... Most times they are not sure because they think they are earning good but not too good, the work is stable but sometimes flaky, the life is smoother but sometimes tiring and they are at the best role in the team but not the top. Many times they are having bad days at work every now and then and the few new entries on the job boards, those bunch of friends who are updating their linked in status as "XXXX is now Sr. Manager at YYY" makes these people convert themselves from passive to active job seekers.

So for those of who do not know if you should leave or not... here is how you can find what you should do and If you should stay or GO...

1. Are you satisfied?
Satisfaction should be the key :
a. Are you fulfilled.
b. Are you learning.
c. Are you challenged enough?

Most times people link their satisfaction to a comparative salary of others in the industry/friends circle etc. The prominent question you should ask yourself is... is what you are doing making you superior to what others at the same cadre elsewhere are?

If you are learning new things every other day, if you are exposed to challenging projects and situations, I think you are increasing your value to a better degree. If you are happy in what you are doing then its a NO GO. Because if you are happy and still changing you would be having the same syndrome affecting you in next few weeks...

2. How is your relationship with your manager?
Many times I have heard this jargon "People leave their Managers" I think it is true to a certain extent not entirely. If you and your manager are not getting along well, chances are that you will always be in a negative radar and thus dis-satisfied. If our manager gives you a peak of future, trusts in you, gives you opportunities... then its a NO GO.
3. Are you in a hurry?
Usually people tend to think that just because the job boards and full of opportunities the economy is booming and they should leave. As I grew I learnt that many times employers carry a different perspective... people who start looking for job changes right when the economy is booming are not necessarily the people who are laid of, they can be those opportunistic lot who care for growth or the hungry lot who will switch with time. Just because you think a lot of job postings means a economic boom and that you think you are missing it then its a NO GO. Wait, watch the season carefully and then step out.

4. Are there any internal good opportunities?
Have you check other opportunities available to you? I remember one of a very Sr. members in the past left us assuming that he would be constrained on opportunities and what he was doing was repetitive only after a few months to learn that he could have played a very very critical role in setting up a fundamental of a fast growing company. If you have not explored the internal opportunities enough... its a NO GO.

Well if the answer to any of the questions above is a NO... you definitely should GO. But if the answer to any or many of the above are Yes... then I guess, you need to take time, revolve around your thoughts and make a call after doing some better thinking.

Sunday, 1 May 2011

Product Features are not research materials

Ani [Our Sr. Dev team member] and me had a conversation this weekend over our 129th release. The topic evolved on how we released a small but smart feature that can help our customers do something very easily. However Ani triggered something that I cannot stop myself from writing. "We have so many small and useful features, most of users don't know about" I agreed, I agreed because the type of questions I receive from our Customer Services team reveal that there are a huge bunch of features that our customers(both internal and external) don't even know, don't even see'em.

I think one of the key element to the success of any product is the ability of that product to reveal what a user can do to save time and which features he can use. Most of the times the development team is aware of all those twisty features that the end users are not aware of. If you get set yourself on your product you would realise tons of features un-used just because they are not easily accessible to users and they dont know how to use it.

Take an example of Facebook if your news feed is bombarded by those Daily Horoscope feed items from some of your crazy friends who think that the Horoscope really falls true or who access it as one of their friends clicked it over or they enabled it out of ignorance and do not know it is spamming others you don't have an easy way to know to stop it. You have to take your cursor to a particular position and then click on a X button to avail actions and then perform a block [Freaky isn't it?]

So what do you need to do to make your product feature and feature knowledge RICH?

Here are some thoughts....

1. Make functions available at easily accessible place
If they are not available where your eye or sight can reach, its going to be useless. People cannot use a 500 page help document to find out about a feature they don't know about. Bring it to their sight and let them search for the answer or ask you about it.

2. Product needs to have a glossary so curious users can go and find things by themselves.
I always found a glossary useful. For most of the articles / books I read I prefer running my eye over the glossary once when I am in the middle of reading and once when I am towards end to figure out if there are certain terms and items that I haven't missed out.

3. Conduct frequent webinars from development staff to make people aware of features.
Developers are the key source to knowledge of product. An answer that I can get from YN or YT or Rupali or Vijay are not the answers I can find in help file or product documentation. These can be small tips , tricks and usage stance. Frequent webinars on different features make it easy for users to join out of curiosity and learn about features. Of course this brings your development unit closer to the customer questions and understandings. I am highly impressed with the amount of webinars done by Oracle on their Autovue platform, 3 sessions I attended and I already know that there is a easy way of clustering servers that we are not using at the moment.

4. Wiki features - Make the wiki available at right places
A product wiki is the most cool thing to have. Believe me a lot of problems , questions , calls and significant resource wastage can be avoided if you a product bible that can be filled in the wiki.

5. Provide help tips at all possible places.
Those little bubbles out there, can help increase curiosity levels and in turn product usage.

6. Create a feature feedback module
Do you ask if you find our search better? You may know the answer but you may also know what critical elements are missing in your search that your customers want. When can this help? Well imagine you put all your efforts to build a full new user interface just to learn that your customers are OK with what you have, they just wanted a effective color on the UI.

7. Iteratively initiate surveys that are real time and reaches specific high usage users not administrators only
Most surveys on products are done with administrative users, sometimes end users. It is quite important to involve users who login the most and/or use the feature most to provide feedback . This will definitely help building a good product vision.

8. Maintain feature usage stats, so you know where to put efforts on.
Do you have it? No..... Go do it. if you know your product is a content dump, you may as well improve the storage / retrieval part of it ;)

So over and over I have to say and conclude that no matter what your product is and how hugely successful it is... there are tons of features that the end users are not aware of and it may be hurting your revenues. Go figure out a way to let them know what they have in the right way, and yes... First Train your internal people.

Wednesday, 27 April 2011







Where do these lead you to?
What do these words signify?
Why should we ask them?
How best we can ask them?
When is the right time to ask them?

The Power of Why, When, How, Where and What... Go sit down, Look at what you are doing today , at this workplace, with this life and ask these questions to yourself... post the answer if possible.

Tuesday, 5 April 2011

Is work building your lifestyle..

Sunday I had a terrific conversation with an old friend who now works with a school in eastern part of the country, precisely in Assam. The school recently provided them fullton access to Internet and they learnt to use Skye.. The conversation that started from how schools are progressing ended up on a critical topic that I would definitely want to pull up here.. Yes the question does your work help you build your lifestyle..

The teacher friend really towed this thought in a certainly different but amazing way that leads me to ask and answer several questions myself...
"I now use Internet more effectively to keep in touch with friends and future. It also helps me in learning new things quickly than exploring books"
"Because our school children have sports as an integral part of the courses, we now exercise religiously"
"Because kids sometimes gets chaotic, we have altered role playing for kids, this ensures they get to see the further side of tutoring while they study"

Well been into IT, I have always heard the cribs about how people have screwed up lifestyles. "I work for 18 hours, don't get enough sleep, have pressure of deadlines" and "I work night shifts, takes me away from the my social life" blah blah blah... Well it is true, not for all but many of us. We spend 10-12 hours working at the office, 2-3 hours driving to work, another 2-3 hours handling issues/calls and conferences from home. We hardly get 2-3 hours at home with family and at home we just eat, sleep, have breakfast and come back to work. Weekends are full of finishing chores like laundry, grocery, shopping, kids blah blah... now is this what we call lifestyle? Or what type of lifestyle should one expect from this?

Well the answer is... it is not your work that is amending your lifestyle, it is you that is building this lifestyle for you. So for my "watch"ful friends.. working for 4 hours at office is not the answer to building a great lifestyle.. it is what you really do, that can build your lifestyle. Lifestyle is not about how much time you stay at home and at work... lifestyle is your behavior, things you do, habits and your actions with regards to things, people and places... Your work plays a major role in it, but its not about time, its about what and how you do things at work.

So how does work help you build a lifestyle?

Its simple... The person that sits beside your desk, if he keeps his desk dirty... there are very less chances that he will keep his house tidy or vice versa. Go check out. Now if he has got into a habit of keeping his desk dirty, he is not going home and cleaning up things. Don't wonder if you see socks lying around, laundry undone, stale food thrown over in fridge.. blah blah.

If you have an engineer who bluffs on why he could not complete his tasks in time, will surely bluff his spouse, friends on several things.

If you see a guy walking to office late, chances are that he will be late for most of the things that he do.

A guy who doesn't care about how he is dressed at office, chances are that he is never well dressed until been told to do so. If there is a dress code at work, it will help build a good dressing basics in turn help build a lifestyle.

A guy who often runs with hair and unshaven for days, chances are that he doesn't care about some hygiene no matter where he is.

If a certain set of procedures are followed, made to be followed... chances are that those procedures will help you be more effective in curbing your bad habits and making a few good ones to become your lifestyle. Well of course people will have to find a value out of these. Though I must say that I am against setting up RULES, there are those basic terms that can help build lifestyles.

I think its all about the quality of behaviour, habits and what you do at work that sums up to become your lifestyle. The guy who is passionate about a bug-free life would definitely much worried to take enough care of his code and quality of work. Now the question to each one of us.. is work building our lifestyle?

Are we concerned about improving it?
Do we action to improve anything?

We recently initiated a self help learning group as a part of fun@work.. A group that will begin to learn a whole new things on its own. We begin with a new language. We believe the attitude to learn something on oneself can help us improvise our lifestyles. I feel geared up for this experience and certainly those other 5 who join me in this. After all.... your lifestyle is more seen at work than anywhere else. And I certainly want a best one for me...

Now if you are doing some fun@work exercises at your workplace... ensure that you add a glimpse of building a better lifestyle for your team. We decided that we would do the following things in future as a part of fun@work :

1. Be a Chef : Having a day when the team will be asked to cook.. things that do not know , haven't heard of.. An exercise that will help them understand various cuisines in the world.. isn't that a better lifestyle?

2. Book reading : Picking up a best seller and reading it on a day out. Book reading becomes interesting when someone is reading it out for you.. in an effective way of course... isn't book reading a better lifestyle element?

3. Swim party : Our next party, we want it to be a pool party. People can enjoy been in water. Isn't swimming a better exercise? They would do it if they enjoy doing it.. and what fun if it is done with people you love.

So much more... so much more to do to improvise on our lifestyles... I am geared to build a better lifestyle for myself, right in the place where I spend most of my time.

Monday, 28 March 2011

New Joiner - Boot them, Board them

Booting up new members... a question that has been hitting for a while now...

Since August 2010, we in Pune have doubled up the size of our development Team.. while it is a good thing for any team and is a sign of upcoming prosperity to the Team and Organization... There is certainly a bigger issue to handle . To ensure that the new Team carries old values, improvises what we have and ensure that the characteristics of the company is not changed and at the same time the new member learns all of this in a much much effective way. If you run through the previous thoughts I have shared here you would certainly know why I feel it is important to have this process handled effectively. Also my previous post on New Joiners on the challenges we have faced in the recent past and the strategies we are trying to adopt to make our new joiners more effective... I take chance to put some efforts writing how we are planning to design our boot camp...

A few key ingredients to success of a boot camp is the fact that who runs the boot camp process.. I believe that the reflection of this runner is what takes the boot camp and the new joiner to succeed in boarding the team correctly... The basic elements of Team building form, norm, storm and perform can really be controlled and managed by this face who runs the boot camp. So while we define the needs of boot camp lets say, we put the prerequisite first, then sum of the process of booting the member to the team.

The biggest hurdle in organizations getting their new joiners boarded and started successfully is the missing role.. Yes you need a Boot manager. That guy who would co-ordinate trainings, sessions, tours and walk through and can also step in and be with the booters to bring them upto speed in right time.

Once you have a boot manager, you can build up a flow to manage your boot camp. Ideally I feel the boot camp should be a 4-5 weeks process. This process should be managed with the help of the most senior team members so that the values and organizational goals and clearly flown in the most significant way.

Here are the key elements a boot camp should hold...

1. Boot mates
Companies that have ability to hire in bulk can definitely afford to do this. Create a boot camp where more than 2-3 new joiners are involved. We have always faced an issue where new joiners join us in split of time and the gap is sometimes between 2 weeks to 5.. of course the challenge for smaller organizations is they never need people in bulk so most of the time the new joiner has no counterpart to learn from.

However an ideal situation, if you have boot mates it helps to understand the process effectively, discuss things within and have a better kick start. We have mostly been unlucky with the bulk joiners except for the trainees who really got a real help of joining together.

2. Culture tour
Most of the new joiners are confused on the cultures of the teams and organizations as there is no likely culture education one gets when he starts. Most of the new joiners learn about the culture with time(Though this is how mentoring happens) I favor a culture tour by someone very senior in the team, if someone like a CXO or head of the team can give a cultural walk through it can help the team member understand the team in the following days more effectively. Ideally a cultural tour should be split into multiple days and people [most of these key executives of the company or team]. If a new joiner doesn't understand a culture, he may not be able to contribute effectively. More less if he is a culture unfit.. it may hurt the team long run.

3. Vision
One of the most confusing factors I found joining previous organizations I worked in was lack of information on vision and strategies. I don't say that they don't exist, but if they don't flow out to the new and old members it causes a sort of confusion and clarity issues from a futuristic perspective. A sight of vision from various teams needs to be given to the boot camp members.. like Product Development road map, Technology road map, Services road map, company vision, local office vision. All of this helps the members to accommodate and build expectations accordingly.

4. Deep dive
Well nothing is more easier than getting a developer look at the code and start fixing bugs. The initial days of the boot camp should be architecture and code walk through to the boot camp members by Sr. Tech architects of the team and the process should involve them to do bug fixing right from development to release of what they have fixed. There is nothing more motivating than to see how your bug fix has made to the production and is helping a few customers on the product even before you get into the mainstream development.

6. Mentor
A new joiner needs to know who is mentoring him. A designated member needs to be definitely a key old member of the team who can help the new joiner get booted sooner and with less issues.

Apart from that there are many things the boot camp can contain, those few I found always helpful are listed down:

1. Get the new joiners trained by only senior members of the team. They are in a state to answer queries and they can guide well.

2. A view of infrastructure, tools , product and production environment should be done both by theory and action.

3. Get them assignments that can let them see how they impact the product even before they get to work in the mainstream teams.

4. Introduce them in steps to the entire organization fraternity, so that they can approach who they need to.

5. Get them a place where there trainings can see real time action. Once we put a new joiner in a war room where we were fixing some critical production issues.. Wont believe he till date has been key in getting most production issues handled by himself.

6. Make them fix bugs that they see, and that means those bugs that they see in the code no letting others to fix them in future.

7. Let them see a list of development items they can work on, so they can choose the best they find for themselves. If you are too small for this, then explain why certain project / module is best for them.

8. Keep the boot camp in work area so people can over hear and learn.

9. Do throw challenges at new joiners and ask them for improvements needed in process, tools and products.. they have a best view when they come from outside and this can definitely let them see those issues that you don't.

10. Let them walk free so they can do different things and ask different questions, let them challenge and get challenged.

11. Most of the new joiners somewhere have a feeling of insecurity when they look the surroundings, work etc in the early days of joining.. have regular meetings with them and address these insecurities. A boot team can get these issues in bulk.. but if not then have it handled together.

12. Always apply the same boot process for everyone in the team. This will ensure that all of them have a similar understanding when they join. the roles they play later can be different after the booting is successful.

13. Offer them to quit after the bootcamp.... I read this in Delivering Happiness by Tony Hseish... after the initial training he would offer the new joiners to pick a sum and quit if they did not like the work or team or company. This ensures that you have the guys who want to be with you and not those who would crib all their lives as they got into you. Earlier they leave better for you.

For all of the 10 you need to plan a few days and small exercises not just on technology but also on different topics so that they can alter themselves to the teams. All these exercises should definitely involve old and semi old team members.

Saturday, 19 March 2011

The inspiring friday tale - How to be happy at work

The Friday that passed away last was highly inspiring, believe me not all Fridays are very good part of my days for a few reasons like I like to be in Office and work, I feel pressure to complete all those incomplete things I have left over the week to be completed on the weekend, I find Friday nights lazy and Saturday and Sunday mornings dead as kids have no school on the weekends and everyone at home sleeps till late.. So what is it that made my Friday happpy and inspiring? (Catch the extra p in Happy yet?), well I had 3 reasons for it and I am going to blog about each of these reasons in the Friday's that make me Happy series, So let me tell you what those 3 things were so that we can continue our discussion further :

1. YT our Tech Architect gave us an eye opener, On Software Quality
2. I met an EX-MLA and got some lessons and tips about politics and life - Very fruitful and inspiring
3. I found a few more ways to be Happy at work

So taking a regular approach I think I will begin with the 3rd... In the middle of the day on Friday the 18th, I took some time off from office so I can visit a physician for my wife, on our way back we found a old time friend waiting by-side of the road for a Bus and offered him a lift home. I give a bit of our conversation before we operate it and I tell you my reasons to blog...

This conversation is post our greetings ;)

Me : "How are you doing?"
Him : "Okay, You tell me"
Me : " I am good.."
Me : "Where are you working these days? and hows work?
Him : "I work for a Software Company, XXXXX we are into blah blah etc etc" [Half of India works for Software companies so this was no brain teaser]
Him : "My Work? I Simply love it" And I noticed a broad flash smile on his face [This surprised me, half the people from the industry I meet are either whining about how there company is not good or there managers are ruining there lives...]
Me : "Cool" - My inner curiosity was killing me... I wanted to know the reason behind the smile and also wanted to find out what is it that the organization was doing that he was feeling so Happy...
Him : "I have learnt to be Happy"
Me : "Hmmmmm... so what is it?" - I have to say that Zappos has got me so inspired that I am trying to find all possible ways of building great cultures and happiness in the team and honestly I wish to imply every single thing that can benefit our teams too...
Him "Nothing, There are so many small things we do and we should take pleasure about.. why Whine, when you can feel Divine"

Believe me... the words made my day... This also comes because one of a fellow colleagues a day ago had asked me "What keeps you motivated to write a blog? there are so many issues, work load etc etc".. Though I answered "Passion" I know that there is much more.. I just think what inspired me to feel proud about is worth sharing here...

Yes.. I have found a way to keep myself Happy... and that Happiness really turns back to wherever I am ... at work, at home or any other place.. I have always been like this and these are the things that I do to be like this... i.e. Happy

1. Read a book unrelated to your profession
Reading is always a blessing, I have learnt this with experience... it has helped in knowing new things and new ways of doing things. A lot of us are scared looking at the breadth and width of the books but let me tell you it is not bad once you get in..
I made atleast 18 attempts before I actually started loving reading. Now reading keeps my momentum at work.. The recent book I am reading is "Worshipping false Gods" [A book targeted towards Dr. B.R. Ambedkar's life and decisions by Arun Shourie a BJP leader] . Prior to that I finished "Delivering Happiness" by Tony Hseish [This is more related to my work, culture but inspired me a lot]. Reading really keeps you involved and I am sure that if it is away from what you do regularly this will keep you busy in the evenings.

P.S. Don't start with Leadership and self help books, if you are not a regular reader.. start with Fiction or some suspense thriller novel...

2. Go visit an art gallery, Museum,
This will blend you into the oceans of art.. some paintings, some art work.. just go visit it once every while. A visit to a aquarium or a sports ground or a museum is also not bad... I visited the Kelkar museum 2 weeks ago.. and learnt a lot about Pune city's irrigation setup. Amazing I must say... A few weeks ago to the renovated Deccan Gymkhana grounds and took a tour.. you know the history and the players associated with it..

3. Watch Movies
I watch a lot of movies. 2 new movies a minimum a week. This keeps me busy, I know one of my weekend nights is going to be watching a good actor play things. Movies inspire you to improve in watching a sports centric movie always blesses me to do more exercises, watching Sean Connery, Amitabh Bacchan, Aamir Khan and Tom Hopkins get me improve my style [include all the Hindi players within too]. Sometimes running into Operah's and plays will also keep you Happy.

4. Blog your experience
Write about it. The more you write the more you improve.. Sharing is a new way of learning and blogging is a really nice experience.

5. Swim
It heals you. Believe me. If you cant find time to swim everyday, try and use your weekend to swim... I haven't seen another best way to relax oneself than swimming.

6. Exercise
A daily exercise or a morning walk can really really get you excited for the entire day. I have noticed that if the mornings begin early and start with a exercise they are surely going to turn you into a motivated factory ready to face the challenges of the day smartly and patiently. I treat Yoga in this section also.

7. Take a walk in the neighbourhood and find 20 things that you had not seen in your last walk.
Well not just neighbourhood, try this on roads and places.. you will find amazing changes and the effect of those changes too. I had done this in office building and noticed some changes that should be termed interesting, people, behaviors, attitudes and choices.. really inspires you... if you maintain the list you would find it worth reading a few years/months later.. if you want to make it easy... capture them in pics.

8. Sport
Stick to a sport.. cricket, soccer.. play it. Just don't watch it. Worst case watch it when it is played and not on TV. Sport is one of the best way to build patience, aggression and winning spirit all at same time.

9. Bowling Alley?
Go hit it once a while... this will bring flavours of joy in your routines.

10. Try an Adventure
Bungee jumps, adventure sport, rock climbing or scuba diving.. whatever you can do... ensure you do it once every few weeks.

11. Surprise your spouse, colleagues
With surprising elements... take them for a uncalled lunch or gift them something that they weren't expecting. This will keep them looking for you on what you would do next and in general improvise your confidence on doing creative things. Also it helps one gets creative.

12. Say a Thank You
A Thank you a day helps. See the smile that you would give someone who did good to you.

13. Donate your books, clothes
See how others would benefit from your unused belongings.

14. 1 Act of Random Kindness to your colleague
As it says... do this... A few kind words, a few polite and kind actions towards others..

15. Share your knowledge, even if not asked
Because if you do this.. you would learn more and the value of giving will earn you more....

So why not try and do a few things like this... there are more that I would want to share... but I guess I will keep them coming as we move on....