Right time to React in your project

There is a thing about introverted data scientists that they put so much emphasis on technical work that they often overlook aspects of people skills which cost them dearly in their careers. I want to share one such experience which has taught me very valuable lessons in my life.

Before this experience, whenever I read about such stories, I somehow managed to convince myself that it can never happen to me but when it did, it hits me very hard. This happened to me in one of the projects. My technical skills advantage was bulldozed and I ended up being ranked as a below-par performer.

More surprising was the fact that during that period, everything seemed to work against me. It was not that I didn’t try to change my ways but nothing worked out and that was mainly because I was finding all the faults in myself.

When the project gets completed and I got rolled off, it wasn’t until 3 months into my next project that I realized what was wrong with my previous project and the team. By the time project was completed –

• 2 out of 6 people in the team have resigned from the company
• The client who had continued for the last 4 years did not renew the contract
• I had a fight with my seniors
• Another colleague had frequent health problems in the past 3 months

Something was definitely wrong but the question was, What? and who should be blamed?

Fortunately, I had a good team and manager in my next project. I have observed the same situations as the previous project, but now things are different. Everyone on the team was enjoying their work, the client was happy with the progress, and pressure situations went smoothly with collaborations.

I have summarised some key differences below based on my experience –

1. Saying NO —

I remember that during one of the client calls, an additional task came in and I was asked to take up that task. While I was going to say yes, just then I got a ping from my manager who was also present in the meeting to say NO. I tried, fumbled, and said NO indirectly.

Immediately, after this call, I got a call from my manager and he told me, Rhydham I observed that you were finding it difficult to say NO, you should learn when to say NO and say it confidently, say something as simple as “I already have other tasks on my plate so won’t be able to pick up the additional task in this sprint.” He also mentioned that we should recognize the client's priorities and try to accomplish the important tasks first. It seems like a small thing but this creates a huge difference.

I recalled that in my previous project, Neither my manager said NO to any justified/unjustified asks of the client and nor do I say NO when my plate was already overflowing with tasks. So in the end, we would fall short of targets and things would spiral to worse, all this despite working late into the night every day.

2. Setting the right timelines does not mean the most optimal timelines —

In my second project when I was going through the tasks list, I observed that some of the tasks include building an understanding and identifying the changes before diving into the implementation. I was shocked because that was never the case in my previous project.

I recalled that in my previous project, one of the major issues was that we could not clearly distinguish the tasks. A lot of changes were happening in the methodology but no time was kept for experimentation and ideation. The timelines were built according to the most optimal scenario case and that generally would never happen. Since there were no buffers, any delay would affect the entire plan which was not accounted for so the only option would be working extra time to deliver within unrealistic timelines.

3. Mistakes are not 100% your fault so don’t always let others put the entire blame on you instead discuss why it is happening —

It is easy when you deliver perfect work but when you make mistakes, it becomes challenging. I used to think that I will never make mistakes but this myth was also shattered.

I have always held this notion that if you make a mistake, you should take 100% responsibility for it, Is that a good idea? Yes, but you should understand the difference between taking responsibility vs taking the blame.

Because when you take 100% of the blame on yourself, you are giving a free pass to other issues that must be resolved otherwise the errors will not stop. And this exactly happened to me. When delivery requirements aren’t made 100% clear and you are working on a tight schedule, mistakes are bound to happen. At that point, take a pause and analyze what needs to change, and confidently present it to your team.

Is there a common theme in all the above points? Yes, it is the “Power of Expression.”

You should have the ability to express your opinions with reasons in a timely manner. First, make it clear in your mind that your opinion matters. Secondly, be open-minded to these situations and learn to deal with different scenarios. Of course, this is easier said than done but observation is key. So start there.

This will give you better growth in your career and it is as important as developing your technical skills. Always remember these 3 points as they will help you immensely in the corporate world.

Hope you liked this article!