Tag: Productivity

Anti features

When evaluating new technology, framework or library; a lot of importance is given to the salient features. While it is very important to know the positives, the negatives usually tend to be glossed over. Being aware of the shortcomings of a framework gives one the ability to anticipate problems down the road.


For example, let us take NoSQL databases. A lot of time is spent on singing paeans to the scalability, malleability etc of NoSQL databases while hardly thinking about the negatives that come with it.

Two simple techniques which give a good visibility on anti-features:
1. The very obvious one, Google for the shortcomings. Someone would have written a blog post on the interwebs highlighting how a framework or technology let them down. For example, take this post by Uber on how Postgres did not work as expected for them.
2. Comb through Github and/or JIRA peeking at the bugs raised and enhancements requested.

Both of the above will provide a good picture of the shortcomings. If you are evaluating a closed source proprietary technology, the above may not make the cut.

Once a mental note is made of the negatives, ponder on the scenarios where this might affect your usage. It helps to spend quality time on this as this will save one from a lot of future trouble.

If you think about this, this might sound very obvious but tends to be highly neglected. We get so caught up in the positives of something that the negatives tend to be ignored and this usually comes biting us back later.

Taking calls

Making decisions is part and parcel of being a leader. It might feel empowering to take calls but the hallmark of true leadership is in enabling others to do this. The smoother the decisions making process and lesser the blockers, the better it is for the organization.


One route to get there is to create frameworks, rules, and principles for decision making. When your team wants to do something and are confused as to how to get there, they just clawback to the principles and use them. For example, take hiring. Having a clear-cut framework for hiring that covers all aspects starting from what questions to ask, how many rounds of interview, how to reject or accept candidates, what qualities to look for in candidates aids the hiring decision process. By having this, teams are allowed to make hiring decisions on their own.

Also, when taking calls, openly articulate your thought process. Make it clear as to what assumptions you did, what questions you asked, what data you looked at, what trade-offs you did. Laying out in the open the way you arrived at a decision helps others to traverse the same path on their own the next time.

To summarise, instead of just taking calls on behalf of others, go that extra mile to create a framework which enables them to do this independently the next time. Also, laying out the decision-making process in the open gives everybody an opportunity to peek at your thought process so that they can borrow it the next time.


Sapiens, the book, gives an amazing perspective of the context in which today’s religions, society, social practises etc evolved and how in the current context, a lot of these are irrelevant. One of the core ideas presented in the book is that humanity, during the course of evolution, favoured social stability over individual liberty because trust was necessary for human advancement and the basis of this trust was a common belief in the same God, social practises, etc. Today, science and technology as well as robust social institutions and concepts like democracy, liberalism, capitalism etc form the basis of trust. In short, the context does not hold true today but we still continue with the practises. We can draw parallel with this to the way organisations blindly adopt technology, frameworks and processes from other places without understanding the context around which these evolved.


During the course of my professional life, I have heard a lot along these lines; Netflix does micro services, let us also do that; Google and Facebook subject interview candidates to intensive data structure and algorithm questions, let us practise the same. Adopting something without understanding the context is a recipe for disaster. As a thought experiment, let us take micro services. Micro services evolved in tech organisations with complex products handled by multiple independent teams craving for control and autonomy without stepping on each others toes. Also, for micro services to succeed, you need to put in a lot of effort into alerting, monitoring, orchestration, devops etc. Without these, micro services is a bomb waiting to explode.

When borrowing technology or processes from other places, a lot of effort needs to be put into first understanding the context around which these evolved in the said place and also what is needed to make these work. Blind adoption usually leads to unmitigated disaster.

Altruism FTW

Have you observed the way Google maps asks for info about local joints and places? They word it in such a manner that it sounds like you are helping others to make an informed decision along the lines of “Give us more info to help others”. What they are doing in effect is appealing to the altruism in all of us to generate more info to make their product better.

I think this is a great way to ask for more data in this world of user generated content. Instead of asking to review a restaurant how about wording it as “Review this place so that others can discover great food”. Instead of asking people to rate your app how about saying “Help your friends discover the app on playstore, rate us”. It would be interesting to A/B test this and see the result.

Release early, release often

Releasing early and often can make the difference between life and death for new age internet companies. Most of the successful dotcoms like Amazon, Google, Etsy etc do hundreds of deployments per day. If you are a small organization, your magnitude and frequency of deployments might not rival these big organizations, but it is always a good idea to release early and often.

If you plan to carry out multiple deployments a day, it is critical that you do not have downtime during these deployments. When your shiny new code is getting deployed, your end users should be able to access the site. This is usually done by routing all your traffic through a load balancer. The end user does not directly hit your application server, he/she hits the load balancer and it is the load balancer’s responsibility to route traffic to your application servers. In addition to this being the recommended architecture for server side software, it gives you the agility to deploy code without having to worry about down time. You take a server out of the load balancer, deploy your code on it, add it back to the load balancer and do the same with the other servers that are part of the group. Two of the most popular load balancers out there, Nginx and HAProxy, allow you to do this dynamically(while the load balancer is up and running you can add and remove back end servers) and I am sure that other load balancers let you too. If you are running on AWS, Elastic Load Balancer lets you do this.

Also, your deployments should be as simple as possible, even a monkey should be able to deploy your code to production. More the complicated it is to deploy software, less the enthusiasm of developers to do it. Using a continuous integration tool like Jenkins helps to make this as painless as possible.

Enable a kill switch for all new features. Your app should have the ability to turn on and off features in seconds. This gives you the power to turn off a feature if you detect any problems with it in the early days.

Also, gradually releasing features is a good idea. This lets you whet out performance and other issues on a small scale before it becomes a site wide issue. Release to 1% of your users and then slowly ramp up to 100% keeping a close eye on the feature all the time.

If you are working on a feature, you do not have to wait for feature completion to release. As and when you finish off logical steps, keep releasing. Your end users might not see the feature yet but this helps you to get away from the situation of one big bang release and everything going down. These incremental releases help to detect bugs early and build confidence for the final release.

Set alerts for all your key performance and business metrics. Post deployment, if any of these metrics go awry, you get an alert and you can set things right. In addition to alerting, having the ability to graph these is tremendous. Post a deployment, you can check your dashboard to see whether the deployment has had an adverse affect on your response times, key business metrics, etc. This adds to your confidence to do multiple deployments without having to worry about your new code degrading performance or adversely affecting business.

These are some of the simple tips that help you deploy code to production on a regular basis. I have not touched on more advanced topics like automated testing, integration testing, automated provisioning etc.


We had an admin interface from which people could download an Excel report. One day, we got a mail saying that the report format is Excel version so and so and it does not work with new Excel versions. The scramble began to find out which version of Excel was used, which version our app produced, how we can upgrade the library the app uses to create Excel documents to the latest version etc. For people not in the know, it is a pain to programatically work with any Microsoft office format in Java, you invariably feel like pulling your hairs out. In the middle of all this madness, I asked a simple question, instead of creating the document in excel format, why do not we create it as CSV? The report consumers were neutral, they were like we do not care as long as we can open it in excel.

As programmers, a lot of times, we blindly work on product requirements without questioning the intention behind them. As it was in our case, the person who gave the Excel requirement did not have any idea as to the difference in the amount of work one would have to put in to create an Excel report versus a CSV, nor the technical debt of the two approaches. From his perspective, it was all the same.

When a requirement comes to you, take a step back and go through them, see if there are chances to simplify. If some of the requirements sound absurd to you, tell it to the stake holder, if some of them might take a long time to implement, talk to him about this. The person providing the requirement has absolutely no idea that some of these features might be technically difficult to pull off or take a long time to implement or there is a better alternative that might not meet the criteria strictly but will not take eons to implement. Bias towards action is good, but a trigger happy one hurts everyone.

The disconnect

I used to sit next to the CS(Customer Service) team for sometime and I heard them instructing certain steps to customers to redeem campaign codes the second time. The dev team had put some extended efforts to exactly prevent this sort of scenario, these campaign codes were not to be redeemed twice. Why this sort of disconnect?

In small organisations without any sort of processes, most of the requirements usually come on the fly, they are briefly discussed through mails, the dev team gets into action, once they are done and testing is through, it gets pushed to production. Then starts the barrage of mails asking, How do we prevent fraud? I need these reports for the board, how do I get them? CS does not even know this feature is live, how did that happen? I need an admin panel to do so and so, why is it not there already? How well is this feature performing, how do I check that? Are we measuring so and so? etc etc.

I am not saying this is always the case, but most of the time this is how it plays out. Why does this happen? Usually there is some sort of disconnect between the various teams as everyone is busy doing their own shit due to lack of time/resources and abundance of problems to solve. Also, there is this constant pressure to throw things out as soon as possible in the name of existential threat/out pacing competition that details not in your face tend to be over looked. For example, a dev may not really think about an admin panel as during development he/she can play around with the database or some config file and get around the problem that an admin panel solves for a non technical person.

How do we fix this? The simplest and the least resistance way to fix this is a project management tool. I have expounded on this before, but let us look at it again in light of this problem. Avoid discussing features over email and do this through a project management tool so that everyone involved has a 360 degree view of the problem. Also, have a template for each task with sub tasks, for example each task can have the following sub tasks(not an exhaustive list and in no particular order):
1. Admin panel.
2. CS briefing.
3. Executive reports.
4. Code review.
5. Testing scenarios.
6. Analytic requirements.
7. Fraud.

I am sure you can add to this list based on your domain but the bottom line is have a template with the obvious listed out. How this helps is, when we have things on our face, we tend to actively think about them. Also, the unintended side effect of this is self documentation for coming generations and preventing blame game later on :). How many times have we heard this typical conversation, one guy says “I had told you this, why was this not done?” The other retorts, “We never discussed this, what crap are you talking man”(Exaggerated for dramatic effect).

Other ways of solving this problem is what big organisations do, having a strict spec review and sign off process, holding regular meetings where all the stake holders are present. I prefer a much more informal process of self documentation and processes which give you the feel of lack of it, your mileage may vary.

Hands on manager

When I was new to the software industry, I always used to wonder why managers/leads just delegate and ask for status updates instead of being hands on. This article is dedicated to the young novice naive me.

Let us take a hypothetical manager in an organization who has taken upon himself to deliver a feature. The feature has a tight deadline of tomorrow. He is furiously working on it today and suddenly the CS(customer support) person calls him and up and says there is this issue a lot of customers are reporting which needs an immediate resolution. Now, this dude has no other option than to discontinue the task he is currently working on, look at the CS issue, figure out who in his team can work on it, assign it to the appropriate person and let the CS in charge know that so and so is looking into it. Now with the CS issue at bay, he happily rolls up his sleeves and starts typing the next line of code when the product manager walks up to him and says, man, this feature that we released last week, the company board is asking for numbers, can we assign someone to work on it, I need those reports like yesterday. The manager furrows his eye brows, does a mental calculation of all the tasks going on, which can be de prioritized, who can be pulled out of their current work and be assigned to this adhoc task or should I say no to the product manager right now and bargain for some additional time. Ok, with that out of the way, he hopes at least now he can get back to his task and he is about to begin when a team member walks up to him and says we need to talk about this design trade off of using a new database table for this feature versus accommodating it in the existing scheme of things. By the time this is over, it is already mid afternoon and time to take stock of all the current tasks, clear road blocks, plan for future tasks etc. There goes the poor manager’s day and no progress on the task which he was supposed to deliver the next day.

Is the answer to this not doing any hands on work and just delegating? No, take on tasks which do not have a tight deadline, which are good to have but always keep getting pushed out due to some higher priority user facing or revenue generating features. For example, right now you do not have a scheme to version control your database changes, you are doing it through some ad hoc ant tasks. Database versioning is an awesome thing to have, but it is not needed like tomorrow and has no visible revenue/user impact, so it is ok if you plan to release it tomorrow but gets pushed out by a couple of days.

While choosing these sort of tasks, try to work on those that touch different components of the system, gives you a good mental model of the whole product, familiarizes you with the day to day issues faced by you team members, gives you a good understanding of the inner workings of the critical code paths in your product. If you do this, you have hit two birds with one stone, you are no longer just a delegator of tasks and to top it up, you have a very good understanding of your product and can empathize with the team.


Employee appraisals are a cause of butt ache in almost every organization. Majority of the people I have known/worked with hate this time of the year. In most of the places, appraisals are done in an ass backward way, where in, during some pre defined interval, you fill a form with all the potions you invented to cure cancer and then expound on how this has revolutionized the medical field(sic sic).

I feel there is a better way to do appraisals. Let me outline it. Regular one on ones should be mandated by the organisation with whomever you are reporting to. During these one on ones, the manager/lead jots down what went well during the time, how did you contribute to this, what was your role, did you go out of your way in putting the task on a fast track, did you do something that not only benefits this particular project/task but the organisation as a whole, did you help anyone when they were stuck etc etc. These questions can be mapped to the vision/mission statement/OKRs/whatever of the org. Also, the manager asks each of the team member as to did anyone else in the team help them in any significant manner. This is peer feedback on a regular basis.

The advantage with this approach is, when it is appraisal time, you do not have to fill a lengthy form and scratch your head as to what you did during this period or fill a peer review form because your manager already has it. Due to the weekly interactions and note taking, the manager has a very good idea of each employee’s strength weakness etc and can outline it in a coherent manner to the upper management and make a clear case for hike/promotion/demotion/pink slip etc.

I feel this approach takes the pain out of employees and makes the appraisals more meaningful rather than some namesake process.

Collaboration tools

Anyone who has been part of a team, be it as an individual contributor or as a lead/manager, would sense a feeling of deja vu after reading this succinct post. I personally have seen this being played in almost every organization I have been a part of. Having been on both sides of the table, I have also enforced collaboration tools on my team at FreeCharge. We started off with trello and found a very sweet spot with asana and the team has been happily using it for the past 6 or so months. This is not to say that the move was smooth or easy but it has now become a part of our workflow.

Let us answer the most important question, why a collaboration tool is needed when we have email? I am sorry to burst the bubble but email is not a team collaboration tool, email is an one to one collaboration tool. What are the shortcomings of email which prevents us from using it as a collaboration tool?
1. Gmail(de facto email :)) took a big leap forward with threaded replies but a task manager should have more levels of hierarchy. This is where asana shines for me, I love the infinite task hierarchy feature of asana, this is something that I really missed in trello.
2. Using email, it is a herculean effort to have a bird’s eye view of all the tasks currently in progress, about to end or scheduled to start.
3. A collaboration tool makes it really easy for you to track the progress of a task and see the wrenches in the system that prevent it from zooming ahead. This enables people to jump in and course correct things.
4. It is a single point of contact for you to figure out who is working on what and to whom you can assign something next. There is this really burning customer service(CS) issue, oh ok, Ram worked on this feature, let me see what he is upto today. Open the collaboration tool, click on Ram’s name and see when he is pushing the feature he is working on to QA. Wow, he is pushing it today itself, so, as soon as he is done, he can take a dig at this. Create a task for this CS issue and assign it to Ram. Also, make the CS agent the follower of this task so that he knows Ram will be on it soon and he can track the progress.
5. Someone higher up in the org wants to know whether the feature that was discussed a couple of weeks back is on track. You can be out of the loop and just ask the person to peek at the collaboration tool and he should have his answer.
6. Finally, the biggest reason for using a collaboration tool, documentation. How many times have you seen this scenario being played in organizations? There is a bug in some legacy feature, but you have no clue why the feature was designed like that in the first place. You ask your manager/lead as to why it was designed the way it is and he gives you a blank stare and says, let me dig up my email, we discussed about this. He comes back saying he is not able to retrieve the particular email thread. If only the team was smart enough to use a collaboration tool, this scenario would have turned out totally different. Using a collaboration tool you can aggregate all the discussions and decision points that went into a feature and you can return to it when in doubt.

Now that the reasons for using a collaboration tool are out of the way, let us come back to the question of making it a part of the workflow. As the article correctly points out, people use these tools for a week and then go back to email. Why does this happen? It is not because email is an awesome tool or that there is no better thing out there other than email. It is just the power of habit and to put it mildly, laziness. We have been so habituated to email that it has become second nature to use it. Also, individuals in the team do not see the reason for using a collaboration tool because an individual contributor of the team does not face the pain of task allocation etc which a collaboration tool primarily addresses. Since that person is not exposed to these problems, he does not see a merit in wasting his time on something new.

So, how do you make a collaboration tool part of your team? Education. Educate your team members as to the reason why this is being done. Do not just tell them that this is asana, going forward you have to use it. No, that is not the way to do things in a team. Tell them that these and these are the problems that you are facing and a collaboration tool will greatly alleviate these problems. Usually, when you are honest and people realize that you are trying to solve a real problem, they go out of the way to help you out. This softer approach has to go hand in hand with the draconian enforcement of the tool in the initial days. People always relapse and it is your duty as the lead/head to make sure that they start on it once again. When you see communication shifting back to email, let the team strongly know that this is not ok, this has to be done through the collaboration tool. A couple of these cycles later, you will have the whole team on board.

As said before, we have been on asana for about 6 or so months now and are very happy with it. Give it a shot, there is a free user tier which should suffice for most small organizations.