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.


Whenever I hear about the government upgrading some utility website, I die a bit inside. I am strongly of the opinion that the government has no business to be in the business of building end user utility websites. A government should act as an enabler, not as a provider. How does this apply to utility websites?

Instead of getting it’s feet wet with building UIs, which usually are crappy, government should concentrate on trying to build robust apis/backends and let the citizens exploit it to their hearts content. There is a huge demand for any sort of utility api, I can vouch for this after being in charge of FreeCharge for an year now. We are rummaging for robust apis for utility services, while the whole spectrum is filled with crappy government websites.

Take for example how amazing it would be if IRCTC was an api provider/consumer instead of the website it is today. Think of all the cool apps/websites people would have built around this api. How many travel sites would have mushroomed around this concept? Along with spiking curiosity and entrepreneurship in people, this would also have lead to job creation.

This does not apply only to governments, but in general to anyone. Open up the gates, let people clamor to build UIs over your services. There are two major advantages in doing this, one, you get out of the distribution problem, two, you broaden the reach of your services. A classic case in point, twitter in it’s early days.

Building robust user interfaces may sound an easy job, but being in the consumer web for the better part of my career, I can confidently say that it is not as easy as it sounds. Does the line “If you build it, they will come” ring any bell?

To move or not to move

In the initial days, when I was trying to bootstrap the FreeCharge tech team, my team members were always trying to make me move us away from svn to git. For the past couple of years, if you have not been living in a cave somewhere without a net connection, you for sure know that git cures cancer(sic, sic). My team members, being the hacker news reading kick ass engineers they are, wanted to be part of the latest fad in version control system. Whenever someone used to suggest that we move away from svn to git, my first question used to be, what problem are you currently facing with svn? The answer usually used to be zilch, nada. In some cases where they pointed out issues, it used to be that they did not know how to use svn properly to achieve what they were trying to accomplish. Instead of investing few minutes in trying to figure out how to get better at the tool that is already part of the infrastructure, they wanted to disrupt the whole process and be part of the latest fad in the tech world.

I am sure anyone who has been part of the tech culture has witnessed this phenomenon. There is nothing inherently bad about using/wanting to use the latest/newest tool/language/framework. In fact, it should be encouraged, it is a clear sign that your team is not happy with the status quo, they wants new challenges, they are ready to come out of the comfort zone and tread into new uncharted territories. But, as usual, it is not as black and white as we want it to be.

If you are starting from scratch, it makes some sense to go with the latest, because anything that is new is a product of someone’s frustration with the existing and trying to better it. Someone writing something new has the advantage that they can learn from the experience of current, better all the issues that they faced with the current and not repeat the same mistakes that the current did. But, at the same time, there is a flip side to it, an existing product usually has a strong community behind it, the product has matured through various iterations and solved all the warts that would have been there when it was the new kid on the block. So, when using an incumbent, you are standing on the shoulders of giants and taking advantage of the huge community behind it. On the other hand, something new has the advantage that they can be scrappy, respond to changes faster than an incumbent, the community in the initial days is very enthusiastic to hold your hand because they want their product to proliferate. So, choosing over an incumbent versus new is more of an art than science, there are no hard and fast rules here.

Coming back to the git versus svn story, if we were starting our product from scratch, I would have for sure gone with git, but we were working on an existing product where svn was deeply entrenched in the eco system. Moving to git just for the sake of being part of the latest wave would mean significant disruption in our whole process and a considerable investment of time. Along with this, there was the question of educating the team members on git who did not know about the git works flows etc. It boiled down to the eternal question of do we spend time in doing this just to satisfy our geek curiosity or can we spend that same time in trying to fix some real issues that we had with our code/infrastructure. I leaned in on the latter.

Fast forward to today, we have moved to git. Our team was growing, branching and merging were becoming issues due to the way svn branches work. We were facing a real problem which a better tool would alleviate. It was no longer a question of being part of the latest fad but was about making ourselves more efficient as a team and we took the plunge. As a leader of a tech team, you will always be in this situation, do not blindly start using something because it is new and shiny, adopt the new kid on the block only if it solves a real problem. Any sort of change is always disruptive irrespective of how small it is, do it only if it makes your team faster and meaner and adds value to your product. I keep reminding myself this all the time, your customers do not give a shit as to whether your product uses cobol or node.js behind the scene, all they care about is how it adds value to their life. Being nose deep in the tech community sometime makes us oblivious to this fact.

In search of that unique idea?

Why google when there was lycos?
Why myspace when there was friendster?
Why facebook when there was myspace?
Why wordpress when there was blogger?
Why tumblr when there was wordpress?
Why posterous when there was tumblr?
Why instagram when there was facebook?
Why twitter when there was facebook?
Why etsy when there was ebay?
Why pandodaily when there was techcrunch?
Why stripe when there was paypal?