While reading this article on the stickyminds - a great web-site containing various kinds of information on software project related activities, especially those centering around software testing - I found this idea to improve the work habits and environment of the entire team. It's a very common sensical, logical approach to building a great career for the individual members in a team, but rarely adopted as a practice. If you check with people individually on what they like to do in their free time, I bet, 60-70% of the times you will get the same answer, that is typical of most people of most sorts and ages - reading books. Book reading is treated both as a hobby and serious culture, by different classes of people. Advantage of reading books is not within the scope of what I'm planning to discuss - there are plenty. Those who pursue it as a hobby, mostly does it for passing the time by reading fiction based novels, classics, short stories and innumerable other forms of lighter reading materials. Those who pursue it seriously, read such materials as biographies, self-help books, books related to specific professions - and anything, that is not just for eyes, but also help practice and habitualize themselves. Habit of reading is so deep-rooted in our culture that it is one of the most obvious, and hence over-looked methods of learning for the rest of us.
By the way, let me clarify a bit here about professional reading materials - such are not limited to hard-bound books, written by well-known professional authors and released in multiple editions, and that are normally sold in heavy duty book-stalls, but any information in a structured format like - but obviously, not limited to - white-papers, articles or even lecture notes. When we talk about articles, there are again many different forms of them - some containing advices, some others with tips&tricks, those offering full-blown help documentation on specific areas or those with tried and tested techniques fully illustrated with case studies. With the onset of the internet, there is no stopping whatsoever on this not-so-well practiced form of learning. If you aren't very organized, you can get deluged by the abundance of the information in this ocean of knowledge, and either drown in it, or prefer to stand on its shores awed by the enormity of it.
So, the safest bet is to go with the tried & tested method of learning - the books. There are so many of it, in various shapes, sizes & content. One thumb-rule that I normally employ while choosing books for my own book-shelf, is to select those with highly-specialized stuff, and that you normally will find useful, and not 'just irresistible to buy' and that you normally won't find anywhere in the public domains like internet. Keep this in mind, again as a thumb-rule: unless you've some idea of when, where and how you'll employ the contents of the book usefully, you're better off than buying it. After you carefully chose one and bought it, don't let it just 'hang-around' in your library and decorate the shelves, but systematically go through the contents (preferably chapter-wise) with the aim to practice it at your job/life some time. Most times, it will make sense to carry out the reading and the practice simultaneously, for otherwise you tend to forget some strict nuances on the subject if you wait till finishing with the whole book, mindfully ignore some of them, or even end up confused (typically, with the present 'on-slaught' of information , one tends to switch between different sources of information even while trying to comprehend any one of them).
I've seen and felt the impact of books in my life, but so far not tested it with my own teams (in fact, the idea never struck me, until recently). But, now I believe that books can help right from defining our work better to enjoying the fruits of our efforts, thus becoming a great booster to confidence and motivation levels of people, and at the same time aid in career building. I'm going to initiate creating a team library of various kinds of books and encourage my people to use them. No doubt, I will face challenges, but I hope to over-come all those. I'll come back to you sometime with the results...
Sunday, January 13, 2008
Friday, November 30, 2007
My few 'Indian paise' on ways to improve work culture!
Good to see you all back! Today, we'd an interesting assignment from our VP in the organization I work for, who challenged all managers to come up with ways and means to shoot down the 'what-is-my-motivation-to-do-this-work syndrome that haunts some parts of our organization. Thought and thought on the subject, and here are my few Indian paise!
- Celebrate employees' day and Managers' day in the company. This idea can also be extended to an HR day, an engineering day, a finance day etc! On this day, highlight all good stuff that the respective team did during the whole year (or since the last time, the day was celebrated); publish it. call for a dedicated meeting held in the company premises for all employees, honour the achievers.
- Encourage celebrating employee birthdays at team level; this is normally done in all teams, but the difference is in the innovative way employed in collecting money into the b'day kitty - Penalize the last guy (or who doesn't attend at all) that comes into the regular team meetings. If there are people that missed attending, money can be levied from those guys too. Given that a team typically has 4 team meeings in a week, we can collect Rs.100/- in a month, if we collect Rs.25/- per guy! ON the specific day, team makes a dramatic presentation a of small momemto to the birthday guy. What a fun!
- Must celebrate all the various days - Mother's day, Father's day, Valentines day etc. Identify the event co-ordinator (only employees) during such days, which could again be through some interesting system - who will plan out all activities for the day. Separate budget allocation needed. Hold games, competitions at a common location within the office campus, where people may come and join, whenever they wish. Restrict the people that may join the celebrations. For example, only mothers can attend Mother's day, Fathers can attend father's day. HR should actively participate in all these and should come up with some mechanism to decide on the genuinity of the respective class of attendees!
- Make it a practice at the HR team, at least to send personalized greetings to all the people on their birth/marriage anniversaries etc.
- Encourage people to celebrate the little things that they achieve. This gives them a sense of accomplishment.
- Rotate lead/management responsibilities - not all, but certain, like conducting meetings that normally leads/managers conduct.
- Open house sessions with Sr.management, once a month; I don't think this needs any explanation.
- Prevention is definitely better than cure; start the people welfare activities early on, and don't give the impression that the management is trying to patch up something, when something irreristably appreciable is observed about the guy. Have team building exercises more often.
- Finally, involve HR/facilities team increasingly in deciding all people related stuff - Rewards/recognition, Work culture. I've heard certain wonderful ideas from these guys in the past - infact, anybody who works in a people supervisor role.
Monday, October 01, 2007
“Mr.Manager, but what do you actually do here?”
I work for a product company that works from multiple geographies, as a Software QA manager. When I joined this company 6 months ago, it was almost as if I was a new-born (Exactly, that's what it means, I'm a 6 months toddler now!), for lot of stuff were unclear to me on the processes and operations side of things, not to mention the numerous discussions that spring up almost daily on the product side, that made me feel in front of the rest, like a buffoon, to say the least! Although on the product side of things, I started to see rays of hope during my discussions - that turned into learning sessions, but unfortunately almost always gets unlearned after a couple of manager meetings - with the leads and other members in my teams, the processes part of it still was a big hollow for me. Though, my senior manager tried to explain a lot of stuff to me, there were many of those gaping holes in the system and most of those that I consulted with were unsure about the solutions, and sometimes even were unable to assess the size of those holes or their impact on the general working of the company. Initially, I was skeptical about my ability to understand and appreciate the system, but as time went by I realized that more or less everybody shared the same plight as I did, but only didn't speak out.
I tasked myself to work (and sometimes, re-work) on several areas that were left unattended/incomplete by my predecessors. It has been a bit (quite that!) extra work for me, but this helped me to learn - and continue to learn - a few things, develop ideas and play with them. More than anything, it helped me sharpen my thought processes. I'd always liked anything that stimulated the right part of my brain (which was rarely though - I've to admit!), hence slowly I started to like the whole thing. In the next few upcoming posts, I'll share with you some of those...No doubt, there is so much more to work on. I've just started to scratch the surface of it! This is really not an exaggeration at all, but most organizations that claim excellence in processes are still at this stage, and some even more pathetic.
If there is one thing that I learned from all of this, it is the futility involved in blaming the organization and/or the system for the way it is and instead, realizing that we're the ones who make it that way! Unless people do initiate it, things will not move even an inch from where it was an year ago, or even a decade could prove short in time. I think, it works phenomenally well, if everybody can tickle their brain cells, do some thinking. See for yourselves, how things will fall in place, only if we're determined to change it!
Within a few weeks of my joining the company, I was a bit embarrassed by a very innocent question from one of my team members that almost translates to "Agreed, you’re my manager, but what exactly do you do here, when I am the one who get all things done?"!. A very valid question, I started thinking about it. I didn't ask anybody for an answer, for it seemed to be a very trivial question and my ego didn't allow somebody else to define my role. I was afraid that somebody will ask me, 'Having worked for 12 years in the industry, don't you know even this?' I was terrified as the very prospect of somebody humiliating me like that!
I searched all over the internet, but I failed to come across any such article/white-paper/magazine columns that would even come close to defining the roles that I wanted to elaborate. So, I set out to define the roles and responsibilities for the various roles that are already present in the system, followed in our organization. I drafted one within an hour or so, but soon, I discovered that it wasn't as easy as that, since I had 2 more people in my team - a technical lead and a project lead - who were almost always barging into my territory of responsibilities. What am I doing here, if 2 others are constantly trying to repeat everything that I do? This particular aspect got me more interested on this exercise. So, I prepared a big list of responsibilities that possibly belonged to a similar system as ours, based on my prior experience. Now, the maximum confusion occurred while I tried to sieve out everything else from this list, except my own. I worked and re-worked for at least one full day. Here, I present the result of this almost fundamental, sometimes ridiculous, or even eccentric effort...
There could be a lot of responsibilities that, I realize, may need to be custom-created to the system itself, so these thoughts may not universally apply; but I feel that this could be a good starting point for somebody who is facing a similar situation (as I did before I set out on this task), to take these points and refine on them. Definitely, comments are welcome...
Technical lead
- Act as an interface between Developers in all geographies (represent the team during engineering discussions, QA-Dev meetings, and Mail/phone communications with developers)
- Technical mentoring of staff - including presentations, Q&A, knowledge base.
- Owns tracking of defect metrics (weighted defect count), help manager to assess on bug quality and follow-up activities including devising and implementing newer ways to better the team's performance on these aspects.
- Assist project lead in defining and own setting up of the test beds.
- Owns document reviews
- Leads the team over participation in exploratory testing, betas (beta forum), and code/bug bashes.
- Drive the innovation efforts from the team and encourage participation in internal programs like bug catch of the month/writing whitepapers/patent submissions.
- Owns Automation plans and frameworks
Project lead
- Daily task Management
- Planning
- Test Stripes & Prioritization
- Estimation & Scheduling
- Own test case/defect repositories and their maintenance.
- Owns test execution, regressions.
- Tracks and identifies any new requirements of hardware/software, help manager decide on whether to procure or swap with other teams in the same geo.
- Assist Manager with managing the expectations from remote teams.
- Status updates to manager
- Assist Manager with Risk Assessment/Management
- Assist Manager with MBO goal settings and reviews.
Manager
- Own team's productivity and follow-up activities.
- Own quantity/quality of the bugs reported.
- Own risk assessment/management.
- Own attrition.
- Status updates to higher management.
- Help teams mutually set clear and achievable expectations.
- Co-ordinate among various geographies and help define plans for efficient and effective product testing.
- Check on the team's confidence level on the product from time to time and keep rest of the team updated on each other's confidence levels.
- Owns long term planning on the team's structure to suite product/project requirements and individual aspirations.
- Update the team with visibility and road-map into generic/specific areas of product.
- Take stock of the team's performance periodically and work with technical lead to define ways for improvement.
I tasked myself to work (and sometimes, re-work) on several areas that were left unattended/incomplete by my predecessors. It has been a bit (quite that!) extra work for me, but this helped me to learn - and continue to learn - a few things, develop ideas and play with them. More than anything, it helped me sharpen my thought processes. I'd always liked anything that stimulated the right part of my brain (which was rarely though - I've to admit!), hence slowly I started to like the whole thing. In the next few upcoming posts, I'll share with you some of those...No doubt, there is so much more to work on. I've just started to scratch the surface of it! This is really not an exaggeration at all, but most organizations that claim excellence in processes are still at this stage, and some even more pathetic.
If there is one thing that I learned from all of this, it is the futility involved in blaming the organization and/or the system for the way it is and instead, realizing that we're the ones who make it that way! Unless people do initiate it, things will not move even an inch from where it was an year ago, or even a decade could prove short in time. I think, it works phenomenally well, if everybody can tickle their brain cells, do some thinking. See for yourselves, how things will fall in place, only if we're determined to change it!
Within a few weeks of my joining the company, I was a bit embarrassed by a very innocent question from one of my team members that almost translates to "Agreed, you’re my manager, but what exactly do you do here, when I am the one who get all things done?"!. A very valid question, I started thinking about it. I didn't ask anybody for an answer, for it seemed to be a very trivial question and my ego didn't allow somebody else to define my role. I was afraid that somebody will ask me, 'Having worked for 12 years in the industry, don't you know even this?' I was terrified as the very prospect of somebody humiliating me like that!
I searched all over the internet, but I failed to come across any such article/white-paper/magazine columns that would even come close to defining the roles that I wanted to elaborate. So, I set out to define the roles and responsibilities for the various roles that are already present in the system, followed in our organization. I drafted one within an hour or so, but soon, I discovered that it wasn't as easy as that, since I had 2 more people in my team - a technical lead and a project lead - who were almost always barging into my territory of responsibilities. What am I doing here, if 2 others are constantly trying to repeat everything that I do? This particular aspect got me more interested on this exercise. So, I prepared a big list of responsibilities that possibly belonged to a similar system as ours, based on my prior experience. Now, the maximum confusion occurred while I tried to sieve out everything else from this list, except my own. I worked and re-worked for at least one full day. Here, I present the result of this almost fundamental, sometimes ridiculous, or even eccentric effort...
There could be a lot of responsibilities that, I realize, may need to be custom-created to the system itself, so these thoughts may not universally apply; but I feel that this could be a good starting point for somebody who is facing a similar situation (as I did before I set out on this task), to take these points and refine on them. Definitely, comments are welcome...
Technical lead
- Act as an interface between Developers in all geographies (represent the team during engineering discussions, QA-Dev meetings, and Mail/phone communications with developers)
- Technical mentoring of staff - including presentations, Q&A, knowledge base.
- Owns tracking of defect metrics (weighted defect count), help manager to assess on bug quality and follow-up activities including devising and implementing newer ways to better the team's performance on these aspects.
- Assist project lead in defining and own setting up of the test beds.
- Owns document reviews
- Leads the team over participation in exploratory testing, betas (beta forum), and code/bug bashes.
- Drive the innovation efforts from the team and encourage participation in internal programs like bug catch of the month/writing whitepapers/patent submissions.
- Owns Automation plans and frameworks
Project lead
- Daily task Management
- Planning
- Test Stripes & Prioritization
- Estimation & Scheduling
- Own test case/defect repositories and their maintenance.
- Owns test execution, regressions.
- Tracks and identifies any new requirements of hardware/software, help manager decide on whether to procure or swap with other teams in the same geo.
- Assist Manager with managing the expectations from remote teams.
- Status updates to manager
- Assist Manager with Risk Assessment/Management
- Assist Manager with MBO goal settings and reviews.
Manager
- Own team's productivity and follow-up activities.
- Own quantity/quality of the bugs reported.
- Own risk assessment/management.
- Own attrition.
- Status updates to higher management.
- Help teams mutually set clear and achievable expectations.
- Co-ordinate among various geographies and help define plans for efficient and effective product testing.
- Check on the team's confidence level on the product from time to time and keep rest of the team updated on each other's confidence levels.
- Owns long term planning on the team's structure to suite product/project requirements and individual aspirations.
- Update the team with visibility and road-map into generic/specific areas of product.
- Take stock of the team's performance periodically and work with technical lead to define ways for improvement.
Monday, August 06, 2007
CNR - try this on a software tester!
Long time! I know, but I'd been quite busy with loads of things.
This time, I don't have much to share, but a bit of insight into my own work area - software testing, that I thought I can share with my colleagues. One of the most serious problems in the software testing any day, has been about non-reproducible or un-repeatable bugs. I bet there has never ever walked/lived/slept (all the same!) a software tester in this world, who hasn't experienced it. It shows up its ugly face in all software shops and occasionally at customer places too. It has been a phenomenon that is nothing short of a night-mare for most test engineers out there. Its effect are so devastating that most people on the job gets perturbed when confronted with the situation (and a few of them, even upon hearing about such situation elsewhere in their vicinity!), and then triggers off a chain reaction of all 'dirtier' things - bad feelings, less morale being quite commonly observed among these. This issue almost always occurs at the most inappropriate situations, including the day before the grand release of your software, leaving you wondering whatever you could do to save your face (if you're a manager, your grief is doubled)! How much ever you talk about this darkest side in a software tester's life, it isn't more. Every piece of what I described about it has maintained status quo since I started working a software test engineer 11 years ago and the scenario hasn't changed a bit today, if not worse.
Today, I read an article about the precise problem we were talking about so far. The author tries to give a newer, fresh perspective into this. It's a ray of hope for all the unfortunate testers, who didn't have an idea where to start looking for a solution. I feel strongly for it, and think must be attempted by all to root out this problem. While reading it, two statements of caution however. Don't be under the impression that you can remove the problem for ever from the face of the earth. Let's accept the fact, it's going to remain a problem, till software exists. We can only reduce its impact, but that in itself is worth all the effort. Secondly, this exercise is definitely not for the weak-hearted. Without sweating it out, you aren't going to solve it; that's for sure.
With all this introduction in mind, go ahead & read the article. Following are some points I quickly extracted from the article, and that I felt were critical.
• 'Unrepeatable' bug is a myth!
• 'Can do' attitude is essential to crack those especially nasty ones.
• Collaboration is important, especially between testers and developers.
• Look at the big picture.
• Keep notes of all your work.
• Watch for patterns among the different sightings of the bug.
• Hunches are often right. Follow them.
• Develop a catalog of failures and their causes as you go.
• Be humble, courteous, and respectful of others’ decisions.
• Don't believe what you see always, for the GUI sometimes creates a wrong impression about how it actually works.
• GUI may not be the best place to repeat all bugs.
• Keep yourself updated on 'state of the art' in architecture, programming & testing techniques.
• Automation is the way to go! Repeat bugs with less pain.
PS: CNR means 'Cannot Reproduce'
This time, I don't have much to share, but a bit of insight into my own work area - software testing, that I thought I can share with my colleagues. One of the most serious problems in the software testing any day, has been about non-reproducible or un-repeatable bugs. I bet there has never ever walked/lived/slept (all the same!) a software tester in this world, who hasn't experienced it. It shows up its ugly face in all software shops and occasionally at customer places too. It has been a phenomenon that is nothing short of a night-mare for most test engineers out there. Its effect are so devastating that most people on the job gets perturbed when confronted with the situation (and a few of them, even upon hearing about such situation elsewhere in their vicinity!), and then triggers off a chain reaction of all 'dirtier' things - bad feelings, less morale being quite commonly observed among these. This issue almost always occurs at the most inappropriate situations, including the day before the grand release of your software, leaving you wondering whatever you could do to save your face (if you're a manager, your grief is doubled)! How much ever you talk about this darkest side in a software tester's life, it isn't more. Every piece of what I described about it has maintained status quo since I started working a software test engineer 11 years ago and the scenario hasn't changed a bit today, if not worse.
Today, I read an article about the precise problem we were talking about so far. The author tries to give a newer, fresh perspective into this. It's a ray of hope for all the unfortunate testers, who didn't have an idea where to start looking for a solution. I feel strongly for it, and think must be attempted by all to root out this problem. While reading it, two statements of caution however. Don't be under the impression that you can remove the problem for ever from the face of the earth. Let's accept the fact, it's going to remain a problem, till software exists. We can only reduce its impact, but that in itself is worth all the effort. Secondly, this exercise is definitely not for the weak-hearted. Without sweating it out, you aren't going to solve it; that's for sure.
With all this introduction in mind, go ahead & read the article. Following are some points I quickly extracted from the article, and that I felt were critical.
• 'Unrepeatable' bug is a myth!
• 'Can do' attitude is essential to crack those especially nasty ones.
• Collaboration is important, especially between testers and developers.
• Look at the big picture.
• Keep notes of all your work.
• Watch for patterns among the different sightings of the bug.
• Hunches are often right. Follow them.
• Develop a catalog of failures and their causes as you go.
• Be humble, courteous, and respectful of others’ decisions.
• Don't believe what you see always, for the GUI sometimes creates a wrong impression about how it actually works.
• GUI may not be the best place to repeat all bugs.
• Keep yourself updated on 'state of the art' in architecture, programming & testing techniques.
• Automation is the way to go! Repeat bugs with less pain.
PS: CNR means 'Cannot Reproduce'
Tuesday, June 26, 2007
Meeting time!
This article on meetings is from stickyminds, and is great...I always wanted to write a similar one, but didn't get the time and energy to think:-)
Thursday, June 07, 2007
Just explore.
Here is the scenario. Recently, the lead in my team at the US came up with the idea of using exploratory testing as a means to unearth better defects in the product under test. Hence, my team at Bangalore were asked to do exploratory testing for half a day and report all defects they find in this process, expecting a significant turn-over than normal days. But, looking at the number of reported defects during the next day, she obviously got disappointed and immediately wrote up a mail to me expressing her concern (although, in gentle words!) and asking for my thoughts on whether to have such bug-hunts in the future. This was my reply to her.
NOTE: So, this is what. Sometimes, I get impressed by my own writing after I finish it up and want to show it up to the rest of the world. Part of the reason for this post to appear here is that, but partly I want to drive home the point that if you care about product quality and want to go bug-hunting, rely on exploratory testing. Everything else is of lesser priority.
"I am a great fan of exploratory testing.
This kind of testing allows to explore relatively 'unknown' areas using relatively 'un-tried' techniques and for this very reason, I strongly believe that this works best when we go on bug-hunting. Test cases are good, as far as they are looked upon as guidelines. However, what I've seen happening in the team during the past 3 months, is that repeated execution of them leads to boredom, errors and the result is missing defects and less productivity. More mechanical and less creative work will miss some great scenarios. Testers no more think like customers, and at this point the whole testing becomes another mundane, ineffective job.
Now, all this said, I think the team is receptive to this, but not set in the right mood for exploratory testing as yet. People are so used to the routine test case execution that their brain started rusting over the time. It will take some more (maybe, a lot more) time to exercise their minds before we can expect glorious achievements from our testing team. Nevertheless, I believe it is possible, with a lot more stress given to such exercises in the future. Encourage people to go all out to do exploratory testing as frequently as they can. While they engage in this sort of testing, let them take notes of what all they've done and discuss with the rest of the team at the end of the day. This will not only help individuals' defect counts, but also help team level communication that will ultimately end up in improving productivity. Just to clarify, I am by no means saying that test cases should be ignored. Test cases are the guidelines and should be seen as such. I am also not against test case execution since it rates the product's ability to work correctly using the 'knowns', but all I'm saying is that it is equally or even more important for us to know how the product performs using the 'unknowns'.
Now, to answer to your other question about the less number of defects filed yesterday, I didn't talk to the team in detail, but chatted with them for a few minutes. The feedback I got was that the product is in a much stable state now and hence the defects are less. It could be right (in which case, we all ought to be very happy), but I tend to think bugs are still hiding in the product very much, but just that people are not capable enough to exploit the 'power to explore' fully. So, I am afraid, if we stop encouraging people to do more of this now (because of whatever reasons), then people will go back to their old self and start rusting their brains again and, in this process, we had only wasted half a day yesterday!
After all these days, a long mail from me, for a change:-) Now, you may differ in your opinion and you've all rights to! I just described, what I think we must practice to see a change, especially if you want to see people enjoy the testing...it's all based on my own experience
Expecting a good debate on the subject and some important decisions that will help our team grow to the next level...
Regards, Anand Iyer"
Friday, May 11, 2007
Money matters...
It pains...a lot.
The pain is not physical and is beyond words to express, because it is my mind that aches. Nobody will see this or ever notice this, but I've been through this really badly during the past few days. On the contrary, I was on the other side until then, extremely happy and convinced to have done something neatly, up to my satisfaction for the good of my people.
It is about my own people. Of course, I consider all of them near and dear to me, although I've known them only for the past 3 months. So, what am I talking about? Go ask a manager, what is you worst nightmare? I bet a good 99% will say, appraisal time! Mine is no different, and I am awfully stuck this time.
During the past few days, people didn't even allow me to breathe! Discussions aplenty, everywhere you get to hear the same stuff; and your responses to all of them are pretty much monotonous. The only thing that was discussed was about that so called life's necessity, that thing which helps build/collapse one's life, one of many people's favorite metrics of their achievements - the 5 letter disaster called 'money'. I am starting to get tired of it.
Why do people break their heads so much, fighting for this 'differentiator' that creates such a gaping hole in the otherwise closely knit society, I wonder? The only other hole in the society is that created by our religions, but, the extent of divide created by money is shamelessly superior to anything else - not only within the society, but within ourselves. The minute you start thinking about money, even the most saintly mind will wander into the 'till now' unchartered territories; including mine, so I deliberately avoid any thoughts related to this thing! We all yearn for more and more and more of that.
Don't misunderstand, I agree that money is a necessity. But, first look around to see how much of that you already've, how much more you need, keep aside that selfishness and look outside of your own or your families' lives, into the rest of the society, and also ponder on this one question - what greatness can it bring me in life, than the life itself; don't you think that your life itself is your biggest gift, money is meant only to support it?
Ultimately, I am not worried for how much more of that I could've distributed amongst my people, but about how much their perspectives are different my own, how much importance our 'next' generation attaches to this tiny, innocent looking sheet of paper, how incapable I am to convince anybody on this...
Just would like to end the post with a note that even after all these, I consider it great privilege to take care of all my people and I still consider them my own!
The pain is not physical and is beyond words to express, because it is my mind that aches. Nobody will see this or ever notice this, but I've been through this really badly during the past few days. On the contrary, I was on the other side until then, extremely happy and convinced to have done something neatly, up to my satisfaction for the good of my people.
It is about my own people. Of course, I consider all of them near and dear to me, although I've known them only for the past 3 months. So, what am I talking about? Go ask a manager, what is you worst nightmare? I bet a good 99% will say, appraisal time! Mine is no different, and I am awfully stuck this time.
During the past few days, people didn't even allow me to breathe! Discussions aplenty, everywhere you get to hear the same stuff; and your responses to all of them are pretty much monotonous. The only thing that was discussed was about that so called life's necessity, that thing which helps build/collapse one's life, one of many people's favorite metrics of their achievements - the 5 letter disaster called 'money'. I am starting to get tired of it.
Why do people break their heads so much, fighting for this 'differentiator' that creates such a gaping hole in the otherwise closely knit society, I wonder? The only other hole in the society is that created by our religions, but, the extent of divide created by money is shamelessly superior to anything else - not only within the society, but within ourselves. The minute you start thinking about money, even the most saintly mind will wander into the 'till now' unchartered territories; including mine, so I deliberately avoid any thoughts related to this thing! We all yearn for more and more and more of that.
Don't misunderstand, I agree that money is a necessity. But, first look around to see how much of that you already've, how much more you need, keep aside that selfishness and look outside of your own or your families' lives, into the rest of the society, and also ponder on this one question - what greatness can it bring me in life, than the life itself; don't you think that your life itself is your biggest gift, money is meant only to support it?
Ultimately, I am not worried for how much more of that I could've distributed amongst my people, but about how much their perspectives are different my own, how much importance our 'next' generation attaches to this tiny, innocent looking sheet of paper, how incapable I am to convince anybody on this...
Just would like to end the post with a note that even after all these, I consider it great privilege to take care of all my people and I still consider them my own!
Subscribe to:
Posts (Atom)