Staying Relevant at Work

There is a lot of talk recently about the forced voluntary resignation at TCS.  I'm not going to comment on that till I see some facts about the attrition rate and head count compared to the previous years.  Then, there are posts that are trying to spread the following sentiments - 'honey-money period coming to an end for IT', 'IT employees deserve this', 'IT employees have become use and throw products' etc.  I’m not going to comment on these sensationalized opinion posts either.

I’m rather interested in discussing and understanding what’s happening from an employee-employer standpoint and what we can do to try to prepare ourselves.  Essentially, the company is trying to push out people who are “in its eyes”, under-performers.  Even if (assuming) the company is doing this for financial reasons, the company would still try to retain its top performers.  The company’s (real) reasons for doing this, the accuracy (or inaccuracy) of the evaluation methods, the morality of this process, the impact to the lives of those who have lost jobs are difficult questions and open for debate.  But I’m not going to get into that either.  Those are all topics that deserve a separate in-depth analysis.

Wake-up Call

I would like to think of these recent events as a wake-up call for myself and this post is about me trying to gather my thoughts on how to stay relevant in today’s industry.  The school/college notion of hard work is - enter the premises on time, stay back late and complete the “given” work.  Yes, these could help but unfortunately, in IT, time is not equal to amount of work done even though at times we are rated on this.  In IT, work is about adding value; in other words, taking responsibility and completing a work that adds value to the client/project.

Amount of work vs value of work

What does it mean?  It means that when a lead asks his/her developer ‘why hasn’t this bug been fixed’, the reply ‘I spent 8 hours on this & I even stayed back late yesterday’ is not going to help.  Either the developer doesn’t understand the issue, in which case he/she should’ve asked a colleague for help after the first hour of analysis or, the requirement/design is incorrect, in which case he/she should’ve discussed the potential flaw with the lead.  Sometimes, we get so caught up in work or debugging (and our null point exceptions), that we forget this big picture.

Clarity

When a task is given, the person doing the work should try to understand the work being done and why it’s being done.  Following someone else’s instructions instead of understanding what’s happening is also why most mistakes happen.  We should also be in a position to explain the work to others because without that skill, no one would understand the importance of our idea or work.  I’ve seen people give explanations like “I’m working on it and it’ll take time; I can’t explain this because you don’t have the technical knowledge in this area”.  In my opinion, they either don’t fully understand what’s going on or lack the skills to explain it.

Responsibility

If I leave my project today, how many work items in my project will get affected?  Am I suggesting that we hoard information to stay relevant in the project?  No.  Collect as much information as possible from others and provide as much as possible to others, but what we do with that information is what really matters.  Say for example, I find out that there is a recurring issue in one of my applications – that’s knowledge.  Taking steps to resolve it – analysing the issue, setting-up calls, building the fix and deploying - that’s taking responsibility.  A lead would always appreciate someone who takes responsibility and would think twice before letting him/her go.  After completing two years in IT, if we are still waiting for the lead to assign us with work, then, we are doing something wrong.

Taking Responsibility vs being a Workaholic

In the course of analysing the issue, the developer might stay back late, have lots of conversations with his lead, ask a lot of questions to his colleague, etc.  This doesn’t mean that he/she is a workaholic or he/she has managed to befriend the project lead.  It means that he/she is getting the work done.  But if the person regularly stays late to complete a 10 days’ worth of work in 5 days, then he/she is a workaholic.  In IT, if someone takes responsibility for a work, they would have to work late for a day or maybe a week or two during analysis and/or deployment.  But once the work is done and deployed, they should be back to regular routine.  If the person is assigned 10 days’ worth of work and is being “asked” to complete it in 5 days, then he is in the wrong role or wrong project.

Prioritization

Often, too much work is assigned to one person but this is not a bad thing from the individual’s perspective.  When a lot of work gets assigned to the same person, it could mean that the lead trusts him/her (more than others) to get the job done.  But the person needs to identify the important tasks and prioritize.  Because we have only a limited amount of time every day.  At the end of the day, if only two out of five tasks are completed, the lead could get upset if the completed ones are the least important ones.  Prioritizing the open tasks is extremely important even if the task wasn’t assigned by the lead.  Say for example, a person is given three tasks but he/she realizes that there is a long pending fourth task that others in the team have forgotten about and not completing that task would turn into an issue next week.  In that case, the person should bring it up with the lead instead of worrying about adding burden.  Prioritize instead of worrying about the work load.

Go-to Person

Finally, we need to be the go-to person in either a technical area or a business domain or some skillset.  Every office will have a person who others consult with for JAVA (or any technology) related issues.  Or a person who everyone reaches out to, for questions regarding the client’s business.  Or let’s say that you prepared a document for the client and now your lead asks you to get it reviewed by a person who is unrelated to your project, then, he is a go-to guy for documentation.  These are usually people whom the lead or manager considers as key members. 

In summary – take responsibility, get work done, prioritize and be the ‘go-to’ person.

Let me emphasize that I’m not saying that these will guarantee job safety.  Also, I’m not saying that the people who were asked to leave did not do any of these.  I’m simply suggesting that, in an IT career, there are certain skills that we need to learn and develop.  Asking “which technology/book should I read to retain my job?” is irrelevant.  Instead, try to understand the work, the current project and the business.