Technology is not a silver bullet

As someone who has led the technology function in multiple start-ups, sometimes as a founder, sometimes as a consultant (a consulting CTO), one of the key learnings that I have seen is that whenever technology is viewed as a silver bullet to all the problems of the business, then that start-up is bound to face a lot of scale up hiccups.

What is a silver bullet?

A silver bullet was considered the only way to kill a werewolf. The term therefore is used as a magical solution to a difficult problem. In India, we have another such term … रामबाण

So, a solution which takes care of your problems.

What does technology represent?

When I refer to technology, I am not using this as a generic term. This is specifically intended to mean information technology resources … including machines, people, code and systems.

Technology usually represents scale through automation. It does not neccessarily mean problem solving. The solution to the problem that technology has to solve, is usually a process, or a product.

This product or process usually has to be designed. This design is not necessarily the domain of someone who knows information technology. Usually, a person who knows the business pretty well is able to do better design, as opposed to a person who can code.

Design requires engagement

Engagement with the problem so that the solution can be found. Therein lies the problem.

Now if the technology team that is within the organization knows the business well enough and if they are willing to engage with the problem at hand, then a proper solution can be designed.

Technology + Business could possibly do this

More often that not, technology resources are not business centric. They are “requirements” centric. I am being a bit harsh, but this is so rampant in India that IT leaders need to start rethinking the way they engage with the business. Perhaps a small business centric subject be included in the engineering courses.

Some symptoms of this problem

However, until business and technology do not partner on an equal ground, this problem will always be seen. What problem you may ask … here are some symptoms of this, folllowed by what typically happens with such teams.

  • An entrenched technology team which is in a “victim” mode all the time. They do not have any control on what work they are doing, and have no say in the business.
  • A rigid technology team which raises a mountain of paperwork and bureaucracy for all incoming tasks. Forms need to be filled in triplicate, and multiple documents need to be created and this is then project managed by a committee. A line of code requires a months paperwork.
  • A technology team that’s viewed as nincompoops or defunct because of their lack of being effective and responsive to the business. Inspite of having inhouse resources, different team chose to outsource work to their vendors.
  • An overworked team that’s loaded with so much work that they just don’t care about meeting deadlines or creating something of value. Testing is haphazardly done, rarely things get documented, cowboy coding is rampant.
  • A risk averse team that lacks the confidence to do great things. Inspite having inhouse capabilities, no one is willing to risk their neck and therefore chooses to outsource to vendors.

When you notice such teams in a start-up, more often than not, that start-up is not going anywhere. Until and unless the team and the business undergoes a severe change in attitudes towards each other, the team is not going achieve shit.

Such a technology team is not a silver bullet, they are a white elephant.

 

Gartner Hype Cycle 2015

Gartner Hype Cycle 2015

I have been following the Hype Cycle reports that Gartner publishes for quite some time (since 2008, if I remember correctly). There are multiple applications of the Hype Cycle, and for these reasons I keep myself updated whenever a new report is published.

Continue reading “Gartner Hype Cycle 2015”

An interesting perspective to Technology

I have been working for the past decade or so, and almost always in the Technology department, in fact, I have headed this department in at least 3 different companies yet. In all these organizations, I hand picked and built the entire team from scratch, was involved in mentoring and training them as well. Yes, I am a technology geek and I am loving it!

Being a geek means having strong opinions about those things … when it comes to technology, yes I like to have a perspective about it from different view points. Notice the difference between opinion and perspective … the earlier has to do something with ego and may not be an open framework of mind to work with, the later is a bit more open and helps you broaden your views. This is one such post … my view about technology has been broadened … when I came to read Srinivas V.’s blog about Technology: A Citizenship Perspective. It’s an interesting perspective to technology, here’s an excerpt –

Technology enables us at three levels.

At the first, surface level, technology is a tool, a convenience, a method of doing things faster, with less effort, more accurately, etc. Using technology as a tool, we can achieve tremendous savings in terms of human effort and removal of drudgery.

At the second, deeper level, technology transforms into an enabler of scale and multiplied capacity to serve. Using technology as a scale enabler we can provide access to millions, provide anywhere-anytime support, etc.

At the third, deepest level, technology becomes an engine for human and social transformation. Technology then transforms man’s possibilities, man’s power to contribute, man’s ability to significantly change the equation between him and traditional systems of delivery and control.

Ahh … it can be a mindful to go through the entire bit, the original post is even lengthier (and I would advise that you read through it atleast a couple of times before you decide to comment!).

So, we all know that an ipod is essentially an mp3 player. It helps us to listen to music that we want to listen to. This would be technology as a tool. If we get stuck here, then we would end up harping about processes, methodologies and functionality.

If we go to the next level, then this same functionality which was being done for 1-2 people now needs to be done for a 1000. It should scale. If we are at this problem … then you are handling scalability. We would end up talking about uptime, users, requests per unit time and so forth. This is a numbers game, how many more can I handle – that’s the question that you would end up asking your system.

The third level that’s being discussed changes the way we normally do things. Apple changed the way we listen to music, Google changed the way we use email, Facebook is pretty much dictating what we do online in our idle time. Technology that changes you.

To be honest, my initial response was to disagree with this, however think about it. When people work on a technology … the approach they are taking decides which level the technology will go to. If they build it to work, it will be a tool. If they build it to scale, it will be a scalable tool. If they build it to change lives, it will be a transformative tool. Most of the awesome products that we know, were created with the change in mind. Not functionality, not scalability … but change. And change they did.

Series on CRM

Today, I sat down and started writing a post on Customer Relationship Management (CRM) implementations and it’s failures in most organizations.

The idea came to me as I was reading one of Andrew McAfee’s posts on his blog, the business Impact of IT. In case if you do not know about Andrew McAfee, you can read up on his blog at HBR.

There have been many theories and reasons on how to start implementing a CRM and what are the typical pitfalls. If you search for this on Google there will be pages on pages of do’s and don’ts. Of these I have read a good number, however theory as always is so vastly different from practice that when you are on the ground, it becomes difficult to relate (and subsequently apply) theory to real life problems.

I consider the CRM implementation at Pristine a failure. It’s not fully implemented yet, and its not fully being used as well … but those are precise points why I consider it a failure. I was intending to write a piece on this on my blog.

As I kept on writing relating my experiences with the implementation, adoption and failures of CRM systems, I realized that one post won’t do justice to this (I had touched around 1000+ words and there was room left for more!) and decided to split this into a series of posts.

In the next few weeks, I will keep writing regular posts on the CRM system at Pristine and how it has failed … and how it can be revitalized.

Updating this post after 5 years, the CRM system we installed has been a resounding success and a continuous source of business insights for the organization.

RBI and the poppycock it calls vision

Got to see a peek at the IT Vision document of Reserve Bank of India, thanks to a tweet by a friend. Go ahead, read it, I am not going anywhere. I will save you the effort though, I can summarize it in one word.

Hogwash.

In more colloquial terms, Bullshit.

There cannot be a more generic document which meanders around superfluously. It touches upon literally all the peripheral topics which one can bring up when the words Information Technology are mentioned, but it fails to take a stand on any topic.

I gave them the benefit of doubt and went to the Contact Us section of their website. After I keyed in a longish feedback to their vision document, when I submitted the request, I got a very nice error message (shown below)

Capture

Great execution of the vision RBI! Not only have you declared that your vision for technology is a blurred mixture of all corporate jargons, but also one of the most basic functionalities on your website is not working.

Further reading on the report informed me that a committee had been setup to create the vision document. Committees are the perfect excuses for being faceless, blameless and gutless. You do not have to take any stand and you do not have to do any work.

Good job o ye Banker of Banks!

The Parity Bit

Here’s an interesting mind bender for you (do note that this question is used in a lot of job interviews) –

A warlord has captured 1000 villagers, and has decided to put their wits to test. He has put 4 different coloured hats (say Red, Blue, Black and White) on these thousand villagers and arranged them randomly in a long queue. The arrangement of this queue is such that each villager can see all the villager’s hats in front of him, but he cannot see the villagers behind him.

Each of them now have to guess what colour their hat is. If it is the right colour then the villager is allowed to live and is freed, if not … then let’s just say he won’t be having any more headaches.

The villagers are allowed to discuss as a group to decide on a protocol (an algorithm of sorts) to decide how to call the colours so that the maximum no. of villagers survive. What is this algorithm and how many villagers will survive?

Hint: The title of the post

Taken from Wikipedia,

A parity bit is a bit that is added to ensure that the number of bits with the value one in a set of bits is even or odd. Parity bits are used as the simplest form of error detecting code.

The villagers have to use the concept of parity in their answers. Instead of taking a guess at what colour his hat is, the last villager is the parity bit. His answer gives an indication to everyone else in the queue as to what could be their colours. How? Here is so –

Each colour is denoted a no. (Red=1, Blue=2, Black=3, White=4). Since the last man can see all the hats in front of him, he takes a total of all the number before him and does an operation (total mod 4). This is the parity (or the error-correction answer). Now the man in front of him can see all the hats (except his of course) and also knows this value error-correction value. What he has to do is do the same operation for all the hats in front of him, and subtract that value from the previous mod. That’s the colour of his hat.

The cool thing about this is that even if there is one fool of a villager who miscalculates, the villager next to him can detect this error and can correct it immediately.

Now, where would we be using this? (In other words, why did I bother with this problem?)

Networks! Computer networks use the concept of parity bit to detect transmission errors for quite some time now (have you ever faced that pesky CRC error? That’s your parity bit right there).