Category Archive : Grey Matter

Build a relationship; even if it means pushing targets out

You can hear what a client/partner needs and you can just meet their needs.


You can listen to them, and start building a new relationship and lay the foundation for a long-running gig.

You can only succeed in that partnership when you start by focusing on solving immediate paint points but never lose track of the big picture. Even if have to tell the Executive Management, that they have to wait for 3 more months for what they want the partnership to achieve because there are more burning issues that need resolutions now, more often than not you will be surprised how happy they will be with the simple fact that you 2 teams are building a relationship of trust because that will only result in a win-win.

P.S.: On a side note, please do not ever sugar coated No one in the world is stupid enough to not see through that. Truth is preferred even if it isnt’ sweet.

We are in Alpha – is a lame excuse

Alpha releases are done to test functionality for early feedback

Alpha releases do not run for 6 months

Alpha releases are not exposed such that consumers are able to consume and create content

Telling your users, that your software is in Alpha after 5 months of launch is a lame way of telling people that you do not care and you rather spend your time on something of more importance. If you are going build a software (a product) and you care about it, and more importantly you want the people using your software to continue to use it, you have to accept the fact that you are liable to fix defects faster. Hiding behind an Alpha tag is a slow death.

Wake up, take accountability and stop saying you are still in Alpha. Have the balls to listen to your consumers, prepare a road map and then MOST importantly fix some of those issues on a consistent basis. Most people do not ask much (unless they are paying you), they will be very satisfied with a few bugs getting fixed every month.

Also, remember there will be 90% of the people who do not care, and will potentially support you. They are not your friends. They (most probably) do not have ideas to help your product grow. The ones that shout most, the ones that take the pain and effort are the ones with real feedback. Alienating them by thinking they are just 2 (maybe 3 people) of the community of 20 of 50 is the biggest mistake you can ever do.

Good Luck!

Do it differently

This is not a technical post, but more of philosophical. I generally post such stuff on my personal blog( but this time, I am going to make an exception but because “do it differently” will be a theme of several of next posts and this just sets the context.

If you do what you always did, you will get what you always got

Someone recently said to me – “I am not doing this for the first time” to a review comment I provided to the person. Of course, I was too pushy (like I am always am, and people tell me to back off – still learning to strike a balance) but this quote just stuck a chord and esalbert einstien-quotespecially this one conversation I had a few days back.

While we all have our experiences and most often we are tasked with something because of what we know already, the ask is to apply the know-how and not really do what we have done in past. The idea is to use our experience of things and make it better, Do It Differently. We often time forget that and what we end up doing is exactly what we did last time – the same good things, the same mistakes. And then when we are done with that next project we wonder – why did the journey seemed more or less the same?

Well…. it’s because

I am not doing this for the first time

This part of my life is called “Chasing Quality”

Chasing QualityAs far as I can recall, one thing that always stuck with me is the OCD around doing things the right way. No matter what I did – could have played a game of cricket when I was a kid, my studies and needing to score a perfect 100, the time when I was fixing computer monitors, writing scripts in fox, writing code in Java/.Net and even now when I am defining architectures.

Morale compass pointing north around Quality means nothing if we do it at the root. If a developer, a lead, an architect and me decide to drop focus on quality at the first instance of delivery delays.

I won’t go back all the while, but I will cover what quality meant to me when I was a developer. While my quality compass is still pointing north, it has been a while since I have sat down and defined what I want to do by the time I deliver this project. Of course there are expectations like “Deliver on time”, “Deliver against scope/requirements”, and then there is that “Deliver as per quality”. Of these 3 the first 2 are fairly easy to measure and clients do it well. It’s the Quality one that has become that beast – and as I have transitioned to working in an industry when we have to deliver websites (.com) where the user base is just unknown the expectations that clients now have are very different from what they were in a behind the locked doors of “enterprise CRUD application”.

I have had The Quality Conversations several times in past but I wanted to do something different

Today in a few hours I walk in a room with 6 of my architects and talk about Quality. I know my vision of quality, but that means nothing if in a few weeks, we will make decisions to drop quality measures because we wont be able to meet the Go Live Deadline. That Vision means nothing if my team has different viewpoints of quality.

Quality meant, once my work is done it’s done.

As a developer

This goes back to the time when I was just coding and there was no team leading, no program management responsibilities on my shoulders:

  1. Quality used to mean to send a story to my QA track and knowing that they won’t find even a single defect;
  2. Quality used to mean that when I would get time, I can open the code and refactor knowing that my unit test cases will tell me what I broke as I improved my code for quality;
  3. Quality used to mean that when I will commit the code, and when CruiseControl fires up it will not break the build;
  4. Quality used to mean that when a colleagues opens my code to enhance with a functionality (s)he won’t have to come back to me asking questions; (s)he won’t have to refer to an external documentation to know what this code does
  5. Quality meant, once my work is done it’s done. There is nothing more that I had to do.

As an Architect

My goals mean nothing if the team I am working with don’t share the same goals.

I am asking myself – if those 5 simple rules that I followed 10 years back worked well for me – should they change?. Does my role today means I need to do anything else. Yes, I produce some design documents now, I write some code, I prepare presentations and yes I own all of quality including whatever my team produces, but why should those simple 5 rules change one bit.

We are as strong as the weakest link.

So the question is not really – what quality means for me, but what it means for those 50 people on my team. Do they want to meet these 5 goals or do they want to do something else. Yes, I will share what my goals are, but I also now need to know what their goals are. Then we have to make a journey and do it fast is to find the least common denominator and sign up for those (as a start). Next, we need to work together to find what herculean effort we have to fill those gaps.

Chasing Quality

My Goal today – Never spend a minute extra in office. Deliver on time, Deliver on scope and Deliver with Quality – something that makes everyone smile.

My bigger task is – make sure no one on my team is spending an extra minute in office.

So I continue to find the perfect formula. I haven’t seen that happen and the several articles and books I read tell me there is no secret recipe and I have almost all forces of nature working against me, yet it’s my task to make it happen for my team. Let’s see how it goes. Now start yet another journey to meet the almost impossible.

What does Quality Mean for me

We will see how this goes. But, for now the 5 rules for quality for me stand even today are:

  1. Deliver an artifact and make sure no one can find a defect;
  2. I can refactor the code knowing it won’t break anything;
  3. Code commits work like a charm and i can deliver code in environments quickly and with certainly;
  4. When I send this application to my dear friends in operation, they don’t hate and curse me;
  5. Once my work is done it’s done

Stories and artificial intelligence

Ravi Pal aside from being a dear friend is someone I respect a lot; he is a technologist who wows me every time I talk about something. I recently came to know he has been writing a blog.

I managed to read only 1 post till now and the very first post is amazing. I’d to share with all of my readers and I quote him to

As a young soul I was always fascinated by stories, stories of Rama and Arjuna, stories of freedom fighters and stories of superheroes (guess we all have been fans of larger than life heroes). It was always fascinating to hear about the superpowers that these heroes possessed, how they were able to overcome the odds and how they had a personal story – a wonderful journeys of their own ups and downs. As a kid it was almost as if I wanted to live their lives, always felt connected to their emotions.

stories and artificial intelligence.


It’s all about laying blame

I heard this in House MD

Good things happen often, Bad things happen sometimes.

If you are are talented and skilled you will try things that others are afraid to try out and because you are going to live dangerously there will be times when you will fail. What you did and What the outcome is are 2 different things. You can fail or succeed but that will have no bearing on whether you are right or wrong. So next time you have to make a tough decision where the chances of failing are high don’t be afraid – do the right thing.

There will be some who will try to lay blame but eventually you will see – people will realize that your process works because you succeed and disrupting your process makes you ineffective and no one wants to do that.

Motivated or Skilled?

It’s interesting how when we have to select a bunch of people to be on our projects we immediately latch onto the skilled ones whether or not they are motivated and the average guys are first ones to go even if they have a vested interested in our success (as they succeed along with us).

Next time when you have to make a choice of keeping someone on the team, pick the one who will do anything to make you successful and you will be surprised what that person will do to gather all the skills needed. He will do everything and a lot more to make him/her successful and in the process you will see success beyond your wildest imagination. You just need to provide them some mentorship – thats all.

Alternatively, keep finding ways to motivate people but don’t forget The Paradox of Rising Expectations.

Just Write away…

I have been meaning to write a few articles for “let’s just say someone” but that publication will mean a bunch of reviews and approvals. I get the fact that I am getting publiched in anotehr brand and they need to make sure it (if not represents) fits the bill. Having said that, the fact that a person is reviewing my article may have very different opinion on the topic and that difference of opinion will impact how my article is reviewed and if gets selected or not.

This article is my POV and what I want to tell the readers, and not what this reviewer thinks and what he wants to get out. This is not just an “edit” on punctuations and language but on my thoughts is my biggest deterrent on writing for any other publication and I realized that those 2 articles have been sitting in draft mode for 18 months now. It just gets “uuggghhh…”

So my advice to myself here and to all of you out there – “just write away.. find a way where you just get to state what you think // dont get stuck into that review trap”.

Don’t be afraid to course correct

When driving a car if you sense a flat tyre; do you stop and fix it or do you just go about driving with a sluggish pace which eventually will lead to an accident?

I guess we all know what we will do! So when we see a problem on a project why don’t we take the time and fix it? Why do we get afraid of telling stakeholders that something has gone wrong and we need to course correct which might lead to an increased cost or a bit of a delay in schedule?

I am sure the counter argument would be – we do fix it or inform it. I am sure if you introspect enough you will realize that we do one of the following:

  1. It’s trivial and we can deal with it ourselves – leads to no communication and eventually there are enough stacked up trivial(s) which eventually leads to cost of schedule gone wrong or;
  2. It’s a engine gone wrong and the cost is already so huge and I will blamed or it will taint my reputation of not being able to handle it well so let me fix it

Either ways you will find yourself screwed compared to if you would just tell the stakeholders who will more often than not be able to share some ideas of how to fix the problem faster. You may still end up bearing the cost (which you do anyways) but your journey towards delivering the project will be so much relaxing and i can almost guarantee your relationships with the stakeholders will be lot more trusting.

Start by getting familiar

The level of confidence a team can get for the number of functional defects that a client can find in UAT has a direct relation to how much they know of the application they are building. You can write any number of scripts (manual or automated) but unless you get yourself to be in a position where you are like a user of the site you will never know if what you are testing will meet the client’s end requirements.

So at some point in time, get to know the application upfront even before you write a single line of code or test script or find someone who does. It’s no different from how our mind works when we travel from home to office or to a new place – either we know where we are going and our eyes and brain give is immediate and instant feedback if we go wrong or we need something like Google Maps to tell us (even though it is a bit delayed).

This is a step that you need to have to be able to deliver Quality on any project