Who Innovates?

Recently, I read an article labelled An Open Letter to the Prospective Indian Employer. This May 25th article was a scathing response to the India Ink OpEd called “An Open Letter to India’s Graduating Class” in the NYTimes by Mohit Chandra, a partner in KPMG, an advisory services firm. Both letters, apart from demeaning the value of employers to employees and vice versa, talked about a couple of traits that are missing in the Indian workforce. One of these traits is innovation, or thinking out of the box. While the KPMG partner claimed that the ability to think out of the box was hard to find in Indian students-convert-graduates, the responder claimed that companies do not do enough to encourage people to ask questions and think out of the box.

These questions brought me to thinking, who innovates? Is it independent programmers who do not have to worry about bosses and HRs and bosses of bosses breathing down their neck or big company programmers, with near-infinite training resources and a fixed income at their disposal? This brought me to another question – what are the myths related to great programming? One myth that binds both these topics together is that great programming requires endless nights of single minded effort and amazing insight.

I went, with these thoughts, to my own example. A few days ago, I decided that my GMail was not secure enough, specially if I open it on a public computer or on a friend’s device. I looked around for solutions but got very few. Most suggested installing a browser specific extension that log me out once a set trigger went off. But this meant that a) An extension in Chrome won’t work in Firefox and b) what works on my computer won’t work elsewhere, making the whole exercise of installing the extension useless. That meant that I had to look elsewhere. I started hunting and soon came across something called GMail Gadgets. Apparently, GMail allows you to install contextual widgets in the interface that allow users to gain additional functionality. Some popular examples are the Youtube gadget that allows you to view videos within your email. The GMail gadgets have an API and fairly good examples. That meant I could program my own gadget and have it up and running soon.

So I started coding and hacking. I built my gadget and had it up and running soon. I’ve been using it ever since and will be releasing it to the public soon. What are the lessons I learnt?

1. You don’t need to think too out of the box to innovate. I saw a problem, recognized it’s value and found the current solutions to be unsatisfactory.

2. You don’t need to work late night hours to code. Good coders don’t need to work at a specific time of day (or night) to write good code. They just need peace of mind and a cozy environment. All of the work I did was within a few hours in the afternoon after lunch. I was on a full stomach but since I was driven to find a solution, I didn’t feel sleepy.

3. You shouldn’t follow protocol if you want to innovate. Here’s a point that I want to make that Mohit Chandra does not seem to understand. The general process in any outsourcing firm based in India, from big to small, is that the programmer will be given a chore and a manual of how the work is done. His job is just to be a monkey with the typewriter. He gets paid for plugging code in where everything, including the thought process is already defined. I’m not saying that’s a bad thing. Sustainable software growth dictates the need for process. But do not expect rote-coders to suddenly feel the urge to innovate, simply because you told them to. People who are in those positions are not motivated to change the process, specially since the process includes the step that they must not deviate from the plan. An example of promoting innovation is the regular hackathon event that every company, from Google to Facebook feeds on. They ask people to come and go crazy with their code. To have the chance of making drastic changes to the status quo, without worrying about process is the essence of innovation.

When I set out to write the gadget, I did not have a process in mind. In fact, the gadget API is heavily limited in what it can do. I hacked and hacked till I found a way to bend the rules to my benefit. Gadgets have their own marketplace and mine will probably get rejected if I submit it. Doesn’t mean it won’t get used. It works and might be a hit amongst my friends and colleagues. But it doesn’t follow the rules. That’s partly why it’s innovative.

I’d like to conclude by saying that the setting doesn’t matter. You can be a multimillion dollar company with thousands of code-monkeys or you can be a two man team with one having no coding background at all, like NiKhCo. What you need to innovate are two things – the freedom to hack and the space to do it.

Also, I know I’ve promised it in another blog post earlier, but this time for sure, I’ll get the gadget out soon.