Skip navigation

We live in an age of unparalleled opportunities. The cumulative disruptive influences of internet, mobility, open source software and cloud computing have brought down the cost of starting a tech startup to an all time low.

Its been about two years since we started Althea. Starting a company teaches many lessons. I started living what I had read about in many books. Entrepreneurship is no spectator sport.

Below, I try to quickly articulate some thoughts and lessons that came in handy. Primarily from a technology development perspective.

– Leverage & embrace open systems [include open source, open data, open apis & open platforms]. Push open source initiatives that lead to reduced costs of development and ownership. Always resist the developer urge to build everything from scratch.

– Focus all proprietary development efforts towards real innovations & adding value. Ensure that all significant development efforts are tied to a business case. While stop gap solutions can get you started, you need to carefully choose your role in the food chain and supply significant value there.

– Innovate continuously and drive the changes in your space. Build and maintain a sustainable advantage that keeps you ahead of the curve. Become the thought leader in your area of specialization. Remember, innovation today is commodity tomorrow. Your competition is going to copy your ideas and catch up with you shortly.

– Stay ‘truly agile’ and adapt constantly to the changing landscape. Accept the fact that disruption is inevitable, and make embracing it a part of your ongoing plans. New business models are getting conceptualized and tested everyday.

– Treat employees as unique individuals and not as replaceable resources. Capitalise on the unique abilities of each person and deploy them appropriately at different phases of a project. Also, startups win by putting a lot of responsibility on young people and letting wonderful things happen.

– Invest heavily on tools and infrastructures that lead to an increase in productivity. While startups dont operate with infinite resources, they succeed by building small but highly efficient and focussed teams. I remember Charlie Munger quoting “The company that needs a new machine tool, and hasn’t bought it, is already paying for it.”

Advertisements

@BenParr (Co-Editor of Mashable) asks – “POLL: Will iPhone, Android, or another platform be the dominant mobile OS five years from now?”

Smartphone OS wars

Smartphone OS wars

The question should probably be rephrased for the smartphone market. Android’s approach, in many ways is similar to that of Linux, infact its even been built on Linux. They even tried to sneak some code into the main linux kernel tree and got flamed for it. It may even be appropriate to include Linux (given Android + Maemo + others) in the list as a candidate.

While Android’s open approach undoubtedly helps, it also greatly benefits from Apple’s stringent approval process and anti-competitive protection for its own apps.

Despite the dust raised by the Android Developer Challenges, it has failed to capture consumer imagination the way iPhone has. In many ways android’s increasing market share reminds me of ITRON‘s claims to be the world’s most popular OS because it powered many mobile phones, digital cameras, CD players and countless other electronic devices.

Sun Tzu would have said Android spreads like the water. Being an open platform, it definitely finds it easier to morph into a wide range of products/devices. This also leads to a fragmented market. For the same reasons, it was always painful to develop mainstream apps for Linux targeting a larger audience. Plus the additional complexity due to diverse devices. Hopefully, the Google backing helps with some of this.

At Althea Systems, these platform wars keep us on our toes, while we choose target markets for our products (right now Shufflr) built on our social video discovery platform, ShuffleFeed. We closely follow developments in multiple device & market segments without taking sides.

Eugene Kleiner PhotoWe know Eugene Kleiner as one of the traitorous 8, the founder of Fairchild Semiconductor, investor in Intel and one of the main founders of top VC firm KPCB. All of which were instrumental in the genesis of silicon valley.

I often come across interesting quotes by him. I stumbled on this set when I was going through the KPCB site, recently. Seemed like a set any entrepreneur would benefit from.

Kleiner’s Laws

* Make sure the dog wants to eat the dog food. No matter how ground-breaking a new technology, how large a potential market, make certain customers actually want it.
* Build one business at a time. Most business plans are overly ambitious. Concentrate on being successful in one endeavor first.
* The time to take the tarts is when they’re being passed. If an environment is right for funding, go for it. Eugene, more than anyone, knew that venture capital goes in cycles.
* The problem with most companies is they don’t know what business they’re in.
* Even turkeys can fly in a high wind. In times of strong economies, even bad companies can look good.
* It’s easier to get a piece of an existing market than to create a new one.
* It’s difficult to see the picture when you’re inside the frame.
* After learning some of the tricks of the trade, some people think they know the trade. This reflected some of Eugene’s own humility; he recognized that many venture capitalists thought they were experts when they had just a bit of knowledge.
* Venture capitalists will stop at nothing to copy success.
* Invest in people, not just products. Eugene always respected founding entrepreneurs. He wanted to build companies with them not just with their ideas.

And, two others – frequently quoted:

* “There is a time when panic is the appropriate response.”
* “What tips me off that a business will be successful is that they have a narrow focus of what they want to do, and they plan a sufficient amount of effort and money to do it. Focus is essential.”

The second is a thread that always runs in the back of my mind, since the time I read it.

When most people are either confused or like being confused, it helps to put things plain and simple.

We were recently summing up the last iteration of our product, when one of my co-founders appreciated me for the tough questions I keep asking him and the others. While I was drafting a reply, I felt it may also be worthy of a post.

In any setup, there are times when things start slowing down and people start losing focus. Also, when most of the parties involved are guilty of sloth, it makes it that much more tougher to ask questions. Which inturn can make it tempting to do something like what Warren Buffet warned against in his latest annual letter:

“From the start, Charlie and I have believed in having a rational and unbending standard for measuring what we have – or have not – accomplished. That keeps us from the temptation of seeing where the arrow of performance lands and then painting the bull’s eye around it.”

When you decide that you will be the one asking tough questions, you run the risk of not being loved anymore. You need to make a choice – whether you want to be the loved one in a mediocre performing system or possibly the hated one in a high performing system. But, coming to think of it, if you are really asking the right kind of questions then people will either come around, or they never truely loved you in the first place.

Another significant advantage to asking tough questions, making it more worthy of the risk, is that it forces you to always be on your heels and pushes you to give our best. Like Mahatma Gandhi said – “You must be the change you want to see in the world.”

Ofcourse, it does help when you are already a part of an amazing team.



Service Oriented Architectures [SOA] play a pivotal role in today’s Enterprise Systems. Service orientation requires loose coupling of services with the underlying technologies. There is a lot Web Oriented Architectures gain by taking the SOA approach, especially with regard to aspects like scaling and being cloud ready.

I dont use SOA here to mean XML web services, but as a pattern for breaking down applications into distributed software components (which we call services). The components being independent units that deliver specific functionality. Data is encapsulated and made accessible only through well defined hardened interfaces. Consumers of the service are provided with a contract for the functionality provided through the interface. Hence, a clear isolation of functionality and data storage is achieved. The services manage all data internally and never provide direct database accesses. Whether access happens as XML/JSON or over REST/XML-RPC/SOAP is irrelevant for SOA. They form the various implementation options.

SOA also provides operational advantages in terms of the break down of the development work. First, small teams are created around problems. Next, the interfaces are decided and agreed upon. The teams then have full freedom in choosing tools, design methodologies, etc., as long as they provide the promised functionality through the interface. Developers in the team own end-to-end responsibilities for the service and are subjected to direct customer feedback. The heightened sense of responsibility also usually translates to better ownership of work. With hardened interfaces, localised issues and reduced integration efforts the net chaos in the system reduces significantly.

The parallel for SOA approach in the programming paradigm would be the Object Oriented Programming approach [OOPS]. Like OOPS, SOA is also vastly misunderstood. Most programmers fail to think Object Oriented-ly (esp the ones coming from the procedural world) and end up building poorly architected systems, while blaming OOPs for its clumsiness. Similar is the case with SOA.

We use SOA extensively in the systems we build at Althea. In my future posts I plan to provide more practical insights into SOA.

cloudsFor a Cloud Infrastructure, the ability to scale dynamically is a double edged sword.

Lets take the example of a more reactive approach to scaling on the cloud. Here, the utilization of all resources(CPU, RAM) in the infrastructure is monitored continuously and when it goes above a pre-defined threshold level, more resources are added. Let’s consider some failure scenarios that can happen with this approach.

* We know that a bot crawling the site will eat up whatever resources are thrown at it. The bot’s activity triggers the addition of more instances hence further empowering it. This leads to a sort avalanche effect and a mightily pissed off CFO.

* Adding application servers to support increasing demand while there are significant bottlenecks in the database infrastructure, further worsens the overall performance of the system.

* Spikes in traffic result in triggering off multiple instances without significantly improving the end user-experience. Hence giving rise to a bloated cloud infrastructure without sufficient business benefits.

There are many approaches you can take to plan your cloud deployment to get around these scenarios. They will be the subject of some future posts.

Procrastination

One of the most touted features of cloud infrastructures is its ability to automatically scale vertically and horizontally with almost zero impact on the running application/service. It changes the way CFOs look at IT infrastructure funding. Though the feature is paradigm shifting, it needs to be exercised with care.

In the traditional approach of hosting private infrastructures, the peak capacity is estimated and all the necessary infrastructure investments are made upfront. Inspite of this you continue to run the risk of underestimating the peak capacity. In contrast, with the cloud approach you pay only for the resources you actually use and the cloud also scales up to accommodate any overshoots.

The cloud however can make architects lazy and not design systems efficiently. Hence using up more resources than required. It may also lead to the development of systems that can respond to very high demands by adding instances, when meeting such demands may have no business benefits.

Procrastination

Yesterday, I accidentally wondered into John Perry‘s [American Philosopher] essay collection through some stray links and then got lost in them. I always felt something was wrong with my ways or with the world. His posts on procrastination and horizontal organisation give me a better perspective on things and make me feel less of an outsider.

Essays relevant to procrastination:
1. Structured Procrastination
2. Procrastination and Perfectionism
3. A Plea for the Horizontally Organized

If you are going to be reading just one of Perry’s essays, then I would suggest you read the first one. Structured procrastination is the art of making the bad trait work for you. It involves shaping the structure of the tasks one has to do in a way that exploits the trait. Towards the end of the essay Perry makes a point that structured procrastination involves certain amount of self-deception but should be easy for a procrastinator.

Confession: I am using structured procrastination to revive this blog ;^).

The Zen Attitude

I was reading Srikrishna‘s latest article on Hindu Business Line – Zen and the entrepreneur.

We seem to encounter the first two koans mentioned in his article (Persevere, grow) on a daily basis, the third one (listening to customers) is yet to happen to us. It would be a happy moment if we were to get that far.

The Zen koans are meant to tire the logic, giving a student of Zen the opportunity to look beyond from where the intellect ends. But the Koans of entrepreneurship require you to work within the bounds of logic.

One of my favorite koans is the Epimenides Paradox (which I happened to read in Douglas Hofstadter‘s epic book GEB). Epimenides was a Cretan who made one immortal statement: “All Cretans are liars.”

Its been a primal human trait to try making meaning out of the chaos. The fascinating fields of astronomy, philosophy, evolution, number theory, quantum physics, .. have all sprung out of this basic urge; the urge to define the (currently) indefinable. But once meaning has been made things become less interesting, losing their charm. True-blood entrepreneurs look forward to the challenge of not being able to see or define success clearly. They prefer chances of failure over the comfort of a well set path to mediocre success.

All said there is much an entrepreneur can learn from spirituality.

Let the sufi in you follow your heart,
let the zen in you step aside letting life take its course,
let the yogi in you enjoy the path that leads to your destiny.

Sri, thanks for adding to the chaos! 🙂