When "Communication" is Overseen!

I got a call from one of my friend. I could see my friend being disturbed from last few weeks. I listened and did not share anything as I know that person is going through his times and let that be discharged.

All I asked was,

• What makes you feel it that way?
• How it makes you feel?
• It's completely okay to be in state what you are, not a concern at all. See how you can hold that in your hands and just say you are done with it and pick something else. Tell me how will you do that once you feel you are doing it.

Being a friend and a senior to my practitioner friends, I feel, it is my responsibility to be with them, when I strongly think I should be there and assist.  

Shockingly, I heard, that friend was asked to take salary cut quoting "you are bad at communication; to help you improve we are deducting your salary and pay 30.x % of your salary". Is this a communication of an organisation or a leadership team or staff?  

I feel, I have no rights to speak about the organisation or about those people in leadership team.  I asked my friend, "are you not happy with your salary cut?". My friend said, "salary cut is not a problem at all. But how they gave me hike saying you are a bright employee and your hard work deserves it; now after two months I'm said you are not doing good in communication though you are brilliant in work and we want to deduct your salary for this reason."

Further my friend said, "this is making me feel more hurt and I'm unable to sleep and can't focus on practice."  He was one of the practitioner, who practiced on self with no much help and solved the problems that came up while practicing.

See what a communication of an organisation has done to a bright and talented practitioner! Making a bright talented employee to go into depression state is one of worst communication of an organisation and leadership team, is what I feel. 

My point of writing here is assisting a friend and not the organisation or that leadership team.  If that organisation and leadership team did that, they will continue to do that each time in new versions. Something like the bug fixed is fixed in a way but it is dormant in many other ways which is unknown and it is experienced at one fine time. 

All I wish to request for who wants to build an organisation and who wants to get into management leadership team is, understand communication if you are trying to emphasise on communication. Lead by example and not by the words of English. Do not mistake English or words of English as communication. The words are not communication! English is not communication! The body language is not communication, it is one of the out come and assisting factors of communication.  I see people joining organisation because of leadership team and their vision and I have seen people moving out of an organisation because of leadership team and communication of them.

Listen to your friends who practices along with you! It is mark of a team work and do best what you can. If the best is just listening patiently, do it and help your practitioner friend to discharge that emotions. The discharge time of emotions varies person to person, and all they need is that personal touch and feel of they are valued and listened.  That said, one should know how to pull it out collaboratively and emphatically.  I believe in it today, and I practice it.  I just don't assist technically but I do assist with personal touch.  My people are one of my strength when we want to accomplish the goal and set a new one!

The organisation is a HOPE.  The leadership team is the wings of the HOPE. The employees are the body to which the wings are binded.  The journey all together is the vision and mission of an organisation i.e. enabling the HOPE.

If something is not right with wings or hope or body, there is something fundamentally wrong which has to be fixed, before addressing anything else.

Problem Not From SDK; But, I Said, That's the problem. I'm Wrong!

Today's software is not like the software and hardware what I saw in 2006 to 2010.  I see the software which we are building today, it integrates third party software vendor's SDKs.  As well, today's software what we are building are not desktop application like in the 2000s; but the applications on the desktop and mobile which can connect everywhere else and serving the user.

Recently, I was testing a product which is in its initial state of MVP. It integrates four SDKs from different software vendors.  Among these, one SDK showed a behaviour which was unusual and the engineering team which I was part of, raised the request for support from that SDK's vendor.  While the behaviour what I observed in the product was uncertain and over a period of week, it took a stable behaviour.  When asked, I was said it is due to SDK.

Here is the miss, what I did for first. I took those words as I had got used to this behaviour for two weeks with no technical solution. I did not question enough that and debug around as the time what I had for testing was also crunched. I and other fellow tester owned the ownership of testing for the release. Stretching late nights and weekends, it all drove me to take words when said it is technical limitations and nothing can be done.  Here is the second miss what I made -- I took these words as the behaviour due to SDK and previous experience was consistent and synching very well.

The story got different in production.  One of the user reported the same behaviour and I was confident in my reply and said, it is as a known behaviour.  My other programmer friends had same opinion.  My programmer friends here are highly skilled and they know their job very well.  But we all were fooled by the software as the pressure which eventually starting building upon us. That was also due to the experience of us talking with that SDKs team.

I took up that behaviour for investigation again today after hearing from production and from a techie friend who said, "it should not happen for so long".  Yes, it should not happen for so long as I expect it should be gone after the synch is done, is what I think as well.

I started questioning myself and doubting what I have learned.  Isolated all the environments for my observations and started watching my actions, the requests, the responses, the pay load, the race conditions, the served and unserved data streams, the logs, and the breakpoints & values in code eventually as I did all these moves. 

I was wrong! Yes, I was wrong in what I said confidently to every stakeholders right form CEO, CTO to all other business stakeholders. Also the engineering team had the opinion what I had.  It was time to go back and tell them, "I'm wrong in what I communicated in behaviour of the client software and rational behind it".

I gave the reason why it happens, when it will happen, when it will not happen, the impact of the behaviour, work around for same in production, is it dependent on anything else and awaiting, and why it was a missed from our end technically.  It was not a problem from third party's SDK. It was a UI that got triggered each time when the activity got triggered. 

Though I have to investigate much lot for other problems in using that SDK, this behaviour is not due that SDK. It did work well in this case here.

What I want to say here?

• No matter how confident in the code and in tests, we will be fooled and are fooled each time
• There is no harm in doubting ourselves for second time on -- what we have listened; what we have ignored; what we have learned; what we have not carried technically while we observe the behaviour from the tests consistently
• Being non-technical in our observations and work helps a lot
• Knowing the benefits of not thinking technically each time
• Giving time to ourself so we sit back and investigate the behaviour which everyone claims it is due "that"

• If it is due to that, you will happen to learn about it so you can test it better
• If it is not due to that, then you will happen to learn it is not so and can figure out the cause of it; help team in fixing it

In this case I see no impact to user in terms of data and performance of product, but the experience is definitely annoyed.

So I learn again, that I should build the tests technically -- which will put the product into test for the experience of each feature; each UI; each actions of user on a UI; each interactions with backend and its outcome to the client; and evaluate the outcome of the same.

How will I do this? I can do this sitting in person and also with help of automation.  But the point is what is the scale where I have to be with my tests samplings to experience it and investigate further. This takes time to learn and it won't happen in crunch time of releases.  Having said this, it is not bad to go and talk with stakeholders and buy the time quoting the priority and impact of the behaviour. We testers will have to initiate and assist the stakeholders in learning when there is a need for it.