KPIs – R is for relevant

It is commonplace for an organization to use the S.M.A.R.T. rule for their KPIs. This rule, in short, states that KPIs should be S.M.A.R.T. – Simple, Measurable, Attainable, Relevant and Time bound. While this framework definitely provides a good foundation it is rather easy to end up with KPIs that do not achieve the desired results. The reason often is the misinterpretation of the ‘R’. Most people make the R about the enterprise, i.e., KPIs should be relevant to company goals.

What about the individual who has to work with these KPIs? Simply put it is not possible for the KPIs to be adopted across the company if they are not relevant to the individual worker.

At Captain Dash when we counsel our clients on KPIs we focus on aligning individuals to the KPIs by keeping the following factors in mind:

Target Audience

The first thing is to understand who has direct impact on the KPIs of the company. How can a KPI be made relevant when the person who directly affects it remains unidentified?

People Study

The next step is to understand the environment in which the target audience functions. What are the factors that have an effect on their ability to deliver, what motivates them, what are the constraints they function under, what are their personal goals for their work, how do these goals align with the intended KPIs?

Gap Analysis

The last part about goal alignments is extremely important. A misalignment between personal goals and company goals can have a negative effect on KPI selection. Once the goals of all the stakeholders have been identified a gap analysis needs to be performed. This gap analysis serves as a blue print when choosing KPIs that are beneficial to both the stakeholders and the organization.


The last step to selecting relevant KPIs is to make sure that they are actually actionable. KPIs that individuals have no control over serve to do nothing more than add frustration and a feeling of failure, neither of which is good for an organization in the long run. Moreover it is impossible to motivate people with something they have no control over.

Once KPIs have been shortlisted keeping individuals in mind all that needs to be done is discuss these KPIs with the respective people under whose domain they fall and help them align their teams to these KPIs.

So, while there is no ‘R’ in KPIs remember that there are no KPIs without relevancy.

Written By: Meghna Verma

Micro Services - Code Small Enough To Remove

As a general rule the delivery rate of all commissioned software is pretty low when we take into account the total amount that are commissioned versus the amount that are actually accepted and used by a somebody. Over that when it comes to business software in particular the average life is about 5 years before it becomes obsolete – dead! When software is created one usually ends up with big hulking monoliths that have very tightly coupled components, thus, making them difficult to deploy. To ease that developers add layer after layer of complexity until we are left with a system that is too big and too complicated to actually function.

One can say that most of the work created a software engineer’s lifetime is sooner or later non-existent. The reason behind this is that historically most software has been so difficult to change that it is easier to kill it and start anew.

This killing of software systems is a strange thing considering that the world we live in is made up of extremely complex systems that thrive and function for years. The biggest example of that is the human body.

With everything one puts the human body through it should not survive for years at end and yet it does. Why is that? The answer is that it is self-regulating. The human body constantly discards cells that are irrelevant, old or have lived out their lifetime and replaces them with newer cells.

If we want software that lasts for our entire life times then it needs to be easy to change and should weather the changing technological environment. For this we need our software to mimic the human body!

In order to do so we would have to discard parts that are becoming obsolete and replace them with newer and better parts. For us to be able to do this with a systems architecture we would need Micro Services.


Because these parts would have to be small, very loosely couples components that can easy to discard because they aren’t coupled and replace because they are not long and complicated.

For these parts to be high performing the best route to go would be for them to be written in the language that works best for each individual part. Additionally it is difficult to tightly couple components that are written in different languages.

This decoupling of components leads to failure. The good thing about knowing that you have increased chances of failing is that you are prepared to fail, thus making it easier to recover and create better codes.

These are all factors that Micro Services make possible. Micro services make it possible for us to create code small enough that we can remove it without fear and systems that can live forever.

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma

Micro Services Allow us to Innovate!

In our two last posts on Micro Services we have discussed anti-fragility and the ability of Micro Services to survive failure.

 Related to both these qualities is innovation. Micro Services facilitate innovation at a very fast pace, thus making it possible to not only be disruptive but also remain so.


A traditional Monolithic application does not give us much opportunity for innovation. Due to the way it is built, changing things and experimenting can be risky due to the fact that the changes potentially affect every aspect. Thus, any kind of innovation is limited.

 Micro Services, on the other hand, respond very well to changes. The decoupled nature of this structure makes it possible to change each individual service in any way that works best for that particular service. The fact that this is a polyglot architecture gives the designers the freedom to work in the language that works best for a particular aspect of the system. This is not to say that the languages have to be different for it to work but just that the options are available.

Another feature that helps to keep the innovation constant and fast paced is the size itself. A small set of code is definitely easier to change and mould as need be compared to a larger set of codes. Smaller services are also easier to test and deploy thus making it possible to innovate and change faster.

The size and modularity of Micro Services ensures that even if a particular change brings down the application the entire architecture is not affected by the failure. This feature, especially, is what gives the teams the confidence to experiment and play with ideas without the fear of a complete shut down.

Anti-fragility, the ability to survive failure and finally the freedom to innovate is why we, at Captain Dash, consider Micro Services to be our secret sauce. They make it possible for our team to offer innovative, completely customised solutions for our clients – solutions that work!

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma Meghna Verma is the Content Manager at Captain Dash.  You can reach her on Twitter @M3GV3RMa .