Tag: management

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.

Build Versus Buy

Consciously or unconsciously, as software engineers, we perennially take build versus buy decisions. It might be as trivial as copy-pasting code from somewhere versus racking up our brains to write our own; using an already available library or creating one from scratch; using a time tested framework against designing one; building a piece of software internally as compared to buying one.


The way we account for the build versus buy decision varies. Some of the frivolous reasons for building in-house are NIH syndrome, hubris, and planning fallacy. We generally tend to overemphasize our expertise, knowledge, and capability which naturally lead to building internally. Also, we underestimate the amount of work involved in creating software, only once we get our feet wet does the reality set in. A very valid reason for building internally is the cost, but when accounting for cost, we usually overlook the hidden cost of developing software. Buying a software has an upfront monetary cost whereas by building internally we pay in the form of opportunity cost, talent cost, feature cost, etc.

Build versus buy arguments are reminiscent of qualitative speak – “This is not our core expertise, we should be concentrating on solving our business problems”; “This is going to cost us a bomb, let us build in-house”; “We should have had this yesterday, building in-house will cost us another 6 months”; “Will that external product be able to handle our scale”; “Can we trust them with our data”; etc. In most cases, build versus buy decisions are qualitative, it is not an easy exercise to quantify them.

When evaluating a product that is already out in the market versus building something similar, a cardinal mistake people commit is mapping features one to one. Even though having 100 different features looks rosy and attractive, usually we end up using only a select few. Instead of trying to match an external product feature to feature, scope out the features that you need or would probably use and then estimate the effort. Another is refinement. An external product will be refined and polished, but you may not need the same level of sophistication. For example, you might not need a web interface for the product; a terminal would work fine for your use case.

When faced with the build versus buy decision, asking the following help:

  • Is this my core expertise or is it something I can let others do for me?
  • What is the cost of getting this done externally versus hiring people to build this?
  • How much control do I need over this, i.e. can I live with some error, downtime or opaqueness?
  • Will I do a better job building this internally?
  • Do I have the expertise needed to build this?
  • Once I build this, will I be able to maintain and enhance?
  • What is the opportunity cost of having this sometime in the future versus having it now?

Use the answers to the above as a beacon for the build versus buy decision.


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.

We are a startup

Being part of a startup is not an excuse to shoot first and ask questions later. “We are a startup” is the most common phrase people spout when you ask them about their sloppy processes and development practices. Being a startup cannot justify having zero process or letting developers be trigger happy. Being a startup cannot be a reason for condoning sloppy employee behaviour like taking leave without adequate notice or working from home on a short notice.

I am privy to startup lores where everyone writes components in a language of their own choosing. If today’s fad is Node, then the developer uses Node and if tomorrow hacker news has a post touting the next greatest language, the developer switches to that. We are a startup, we do not have a QA and pre production environment for testing, we test code directly in production. We are only a couple of people, hence we do not need version control. Since I am a single guy who manages servers, configuration files are not in version control, my brain is my GIT repository.

Being part of a start up is an opportunity to move fast without being burdened by the bureaucracies/politics of big organizations. Say for example, you find an employee kicking ass, as a manager/lead in a start up you can give that person a raise by having a quick chat with the CEO. In a big organization, you have to make a case for that, present it to a committee, justify why someone should be given an out of turn raise etc, in short, there is a lengthy process and guidelines for these sort of things. It is also an opportunity for you to trust people and call them out when you see something odd without introducing a process around it. If you see someone working from home on a very regular basis and it is hampering work, instead of floating a blanket rule saying work from home is prohibited, there by inconveniencing other employees who use it judiciously, you talk to the person and see what is the problem that person is facing and try to solve it. This is difficult to pull off in a big organization that has thousands of employees but highly doable in a startup.

A startup lets you create an atmosphere based on trust rather than draconian processes. Let us take technology choice for example. Big organizations have lots of rules and regulations on what technology can be used, what cannot be used, how to buy licenses etc. This is made with the central assertion that individuals are not responsible enough, so let us decide by committee. In a startup, you do not need to introduce a process for this, you can trust your employees to make the right technology choices as long as they do not go bonkers with it. If something goes wrong with a technology choice, you can talk to that person and figure out where he went wrong instead of mandating a policy for all employees from then on. Individual responsibility trumps rules any day, it is difficult to implement and follow in a large company but can be easily pulled off in a small organization.

Next time when you use the phrase “We are a startup”, think hard whether you are trying to mask inefficiencies in the guise of being a start up.


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.

Work from home

Recently, there has been a brouhaha in the tech community over Mairssa Mayer’s views on work from home. As an individual tech worker, it is very appealing to side with work from home and going by the reactions in the community, I would say that I am not in the least surprised. But, when you look at it from a company’s perspective, things change, it is no longer as black and white as the tech community makes it look like. There are a lot of nuances to work from home which predictably makes it difficult for large organizations to effectively adopt it.

As someone who has worked from home for a good one and half years and also now being responsible for FreeCharge, I can objectively look at this from both sides. Let me first talk about my personal experience while working from home. I used to love it, the biggest factor that used to work for me was the time saved on commute, the gained one hour in a day used to do wonders for me. Whenever I used to tell my friends that I work from home, I used to get the usual question, how do you manage to do it? I am not someone who needs motivation to work, I would be writing code even if no one paid me for it, pay is the icing on the cake. I love building stuff, accruing knowledge and bringing things to life and my profession as a software engineer lets me do all these. Without digressing, what I am trying to convey here is that, to work from home, you need to be highly self motivated. If you are in your job only for the pay check, then work from home will result in anarchy at your company. The usual reaction in big organizations when someone sends the WFH(work from home) mail is a snigger.

Even though everyone in your organization might be supremely dedicated, there are two more prerequisites that are essential to making work from home successful in your organization. The first question that you have to ask is, are all my employees roughly on the same productivity and experience plane? Junior developers need a lot of mentoring and collaboration to create quality software irrespective of how motivated they might be. It is a herculean task to bring this sort of collaboration and guidance when the guru and acolyte are not physically present in the same location.

The seconds question is, is the entire team remote or is it only a small minority? If you are in a situation where only a sparse population of the team works from home, then again it is going be difficult to pull this off. What usually happens in such a situation is fences are created, on one side, you have the remote workers and on the other, you have the office goers. Whey you have this asymmetry, information flow is one of the biggest concerns, as people who work in office find it easy to proliferate information through word of mouth and this does not reach the employees who work from home. In such a situation you have to engineer a cultural shift in the way people communicate and document in your organisation. It is difficult to engender this as those who are physically present in the office do not see a point in many of the processes that you will have to accommodate to benefit the remote workers and as you know, when people do not believe in something, it is next to impossible to get them to do it.

The above are difficult to pull off in an organization of the size of yahoo!, so, no wonder, while it works for 37Signals, it does not work for yahoo!,  Mayer took the most sensible way out. When do you make special provisions in your organization to let people work from home? I would say that it would be only on super critical projects where a person/team is working in a silo, detached from the rest of the organization and you are one hundred percent sure that this team/individual would not abuse the freedom that comes with work from home.