TJ's Kaleidoscope

The Cost of Innovation

Early in October, I walked into the office and passionately proclaimed "We're going to migrate to Jboss 5.1". I'd been toying with the idea and researching its new features for a while. The new features (better enterprise level messaging, monitoring framework etc) combined with some limitations of the current version (4.2.x) made migrating an increasingly attractive option, some would say even a necessity. From a risk perspective, 5.1 couldn't be any worse than 4.2, just like 4.2 couldn't have been any worse than Geronimo 1.x.

For those lost in this version jargon, let's assume your application is a Lexus LS 450, then the application server is it's engine. So now picture you're trying to either upgrade the engine to a newer one from Lexus, or completely change the engine and retrofit it with that of a Cadillac. Imagine the mess, the grease, and the tinkering involved with something that is supposedly just a matter of nuts and bolts. Now add to that the malleability of software, and you might get an idea of the complexity.

In any case, the first task was to make the code base deploy on the new server, i.e., get the engine to sit inside the car. This itself was a huge undertaking for 5.1--itself a completely redesigned server--suddenly become a strict enforcer of the J2EE spec (the framework on which most enterprise grade Java applications are built). However, we persevered through the mess, the lack of documentation, the incomplete instructions, the cryptic user groups and got it to deploy--a week later. So the engine was in the car, now on to the road test. Here's where things got really interesting.

Before we go further, it's necessary to know that we're talking about a very scalable, stable enterprise application which as you read this is creating hundreds of campaigns per hour, processing between a few hundred to a couple thousand calls per minute, and serving hundreds of thousands of API requests per day. In short, we're talking about a fine-tuned, race-track tested performance automobile. It's definitely not a see-ma-what-i-made application.

Anyway, we run the first of our performance tests and the application fails badly. Hiccups like these are to be expected in any migration. Everything we read about 5.1 seemed to suggest there would be work involved making the source code either compliant with the new server or better equipped to tap into its many features. This of course took time, which we gladly invested. To continue the auto analogy, to help the new engine perform better, we were making changes to the chassis.

Regardless of the code changes the new system failed our (admittedly very stringent) performance tests. Perhaps it was our zealous belief in 5.1 as being a kick-ass platform, but we assumed that the problem is hardware. So we ended up building a server stack that mirrored our production configuration and re-ran the tests. The app performed better, but yet not at the level desired. It was at this point, that we began the entertain the idea that maybe, just maybe, the problem was in Jboss 5.1. There was only one way to test this--run the same code (with all its modifications) on the current version and compare. To our surprise (and some relief) the older version blew every performance test out of the water. Not only did it run fast, but it also ran a lot more efficiently i.e., no hogging up 400% of the CPU etc.

Disappointment would be an understatement. Not only had the next generation of application server platform failed miserably, we had spent almost a month on an initiative that wasn't going to work. Jboss 5.1 was turning out to be Redhat's version of Windows Vista. It was over-engineered, under-documented, and in the end grossly under performing version of a famed line of products. This makes more sense when you realize that it took the Jboss team a full two years to come up with this new release. What's more, despite Jboss 5.1 being around for a while now, until a week ago, Redhat officially supported only version 4.3. In other words, you couldn't pay Redhat to support version 5.1.

This is neither here or there, for the call was still mine, and I had basically put the entire company's efforts on hold by placing a strategic bet on this new platform. Vijesh ended putting his project on hold and becoming my primary partner in this effort. Punit had to put his stealth project on hold because the platform was changing. Paul, Will, Bill, Jacob & Becky had to put their bug and feature requests on hold because the platform was changing. The entire company's growth was put on a holding pattern because of this experiment. The question then is, whether it was worth it.    

Experimentation is the necessary cost of innovation. Any firm, let alone a technology company, shouldn't shy away from experimenting (as Vijesh put it, "We're a technology company, this is something we do!"). Very often we see companies get so comfortable in the status quo, the If-it's-not-broken-don't-fix-it mentality. This is a very dangerous for it leads to entrenchment and a vested interest in the status quo. It's not to say that things always need to be changed, but they definitely need to be questioned regularly. Strategy unchallenged becomes dogma, suffocating diversity ultimately killing the organization it serves.

The answer then is yes, I still believe it was worth it, and so does the entire team. Who knows, six months down the road, I might waltz into the office and say, WebSphere will be our vehicle to the future.

Quote of the Day:

                          "Life is "trying things to see if they work" "
                                                                      --Ray Bradbury

Leadership & Storytelling

First off, I'll have to thank Keith Ferrazzi for this blog post. His tweet "powerful leaders MUST be powerful storytellers" got me thinking about the people I heard at last week's Twiistup event as well as an old HBR interview of famed screenwriting coach Robert McKee. The memorable showoffs (as they're called at Twiistup) and the talks had one thing in common: the ability to tell a story. Be it the product pitches from Bakespace CEO Babette Pepaj, the folks from Eqal or the talk from Zivity's Cyan Banister, all were very successful in personalizing the message for the audience by weaving a story around their product. Cyan took it a step further by making the audience a part of the story asking us to share the 'sin' our startup promoted (CallFire promotes greed in case you were wondering).

Each of these speakers, knowing or unknowingly, incorporated some of the core tenets of good storytelling. They united an idea with an emotion. Bakespace for example, unites the idea of seeing a great recipe on Desperate Housewives and sharing them with fellow food junkies. The speakers also used an inciting incident to serve as the starter for the story. For ExpenseBay it was the filing of corporate expenses run amok and how their product could help bring back that balance. Most importantly, the speakers tempered their product pitches with a health does of reality and skepticism and thereby preserving their authenticity. Some speakers did it better than others, nevertheless the effort was evident, and that's what made the story all the more compelling.

There's a lot to be said about storytelling and the art of persuasion. I'd love to put the article up for download, but I doubt HBR would like that, so here's the link. I'd also highly recommend Carmen Agra-Deedy's TED talk. In the mean time, I'll let Mr. McKee answer Keith's question.

Quote of the Day

Great storytellers-and, I suspect, great leaders-are skeptics who understand their own masks as well as the masks of life, and this understanding makes them humble.     

                                                                              --Robert McKee

Startup Lessons: Passion

I had the good fortune to work with hardworking and passionate people all my career, but I’ll say this, in a startup, passion is not an optional ingredient. It is in fact, essential to survival.

At IBM, I probably put in just as many late nights and weekends, but somewhere deep down I knew that if I didn’t work one weekend, or went home at 5:00 PM one day, the stock’s wasn’t going to tank. However a startup requires hard work at a level of consistency that is impossible to sustain without passion. Startups are run during the week, but built over weekends. Every weekend not spent building, shows up in lost opportunity the very following week. Such sustained efforts are impossible without passion.

Passion gives you hope, makes work it's own reward, and provides the needed focus. On the other hand, hard work without passion is an affront to intelligence, and will die a quick death. This is especially true when building a company for so many things will grind you down, beat you up, that hard work by itself wont have a chance. A startup will dispense with cold efficiency any effort that is abundant in hard work but lacking in passion. There will be so many pitfalls, setbacks, and missteps that you will lose the will to work hard. As I look back at the almost two years with CallFire, and all the ups and downs, I realize what’s kept me going (and still is) is passion--a passion for technology, for problem solving, and for challenges.

Passion, or loving-what-you-do, is hard to describe and probably the reason why this post might make little sense. Passion is emotional, and emotions are hard to put into words, especially so in the confines of a blog.

This post also concludes the first installment of my startup lessons: ignorance, arrogance, and passion. As I said when I first started on this series, these are just my lessons, and a description of my still on-going journey. They are by no means a prescription. Every journey is unique, I'm just sharing mine.

Quote of the Day

I know the price of success: dedication, hard work, and an unremitting devotion to the things you want to see happen. 

                                                                     --Frank Lloyd Wright

Do you Buy or Build?

My previous post got Dinesh--one of my business partners at CallFire and I talking about the core argument behind cloud computing.  Do you buy or build software? This is a decades old question in software and a complicated one at that, for the argument can be made either way. Think about it, if integrating your application with the telephone is critical to your business, then you can go one of two routes. You can either say "It's core to my business, so I'm going to build it from the ground up", or you could say, "Because it's core to my business, I'm going to let the experts take care of it, and hold them accountable". Of course, CallFire would encourage the latter. Telephony in all its glory and complexity has been the overriding focus of our lives for more than two years now and we could think of many reasons why letting us worry about managing calls makes a lot sense. There are many objective factors to take into account like cost & quality, however many decision makers overlook the human factor i.e., the teams that will implement these decisions.

 

 

Our own internal decisions have invariably leaned towards build. The way we looked at it, the only way we could perfect the trifecta of quality, growth, and scale was to build our stack from the ground up. I know there are some techies out there that are shaking my head as I'm saying this (and perhaps some competitors snickering), but it works! The overriding reason being the team at the core of this effort. We have a crack group of people that know every aspect of what goes on in our servers. Komnieve is our system architect and asterisk compiler. Punit is our Java code hacker, and resident asterisk coder. Vijesh spends his time at the application, ui, and db layer. What we share is a propensity for lateral thinking. Between these three and myself, we can recompile kernels, deploy on-demand backups, launch complex features, and trace any of the millions of calls that go out of our system. This team has the ability to look at a problem, and figure out how to approach the solution in non-linear ways. In other words, instead of spending time analyzing the problem, figure out the end-goal, and then try anything and everything to get there.  Working with the three of them (and of course, let's not rule out Dinesh, even if he's 'only' marketing), only reaffirms what I've known all my career: You can go to hell and back if you have a great team with you in the trenches.

If you have a similar group amigos, then by all means go ahead and build your telephony stack. We'd like to think we're special, but realize we're hardly unique. However, if you don't have the time or resources to build such a team yourself, then definitely consider this critical aspect of your decision. It's easy to fortify yourself behind elaborate spreadsheets filled with numbers, but in the end it's people that build value.

Quote of the Day

Individual commitment to a group effort — that is what makes a team work, a company work, a society work, a civilization work.

                                                                    --Vince Lombardi

The Secret of Cloud Telephony

Given that at CallFire it’s my job and my obsession, I feel it’s time I talk a bit about cloud telephony.  The term, combined with it’s elder cousin—cloud computing—have become buzz words, and as is usually the case, truth is the first casualty marketing.  Nevertheless, cloud telephony is real. You have only to look at our success as proof of this  idea. Our web presence makes it simple to dial thousands of  phones,  run national Get-Out-The-Vote operations, and create American Idol style call-in numbers all in the matter of minutes.

 

 

 

The secret is creating what Grady Booch calls the illusion of simplicity. It is an illusion because building quality software is essentially complex.  Yet abstracting this complexity from the user is the value we create. For example, any developer can use our API to make calls without ever having to know the first thing about VoIP. This is the true beauty of cloud telephony.  The idea that you can outsource  gargantuan tasks of setting up telecom trunk groups, allocating channels, managing carrier relationships and simply focus on your core bread & butter business. In the end, cloud telephony is about peace of mind, the guarantee that the light will always turn on when you flip that switch, and in the rare cases it doesn’t, you can simply pick up the phone and call (or yell) at someone.

Quote of the Day:

Simplicity is the ultimate sophistication.

                                                             --Leonardo Da Vinci 

Startup Lessons: Arrogance

Entrepreneurs have to have a high degree of arrogance and perhaps the reason why brash, loud, arrogant are some of the popular adjectives when describing them. One of the things I’ve learnt is that you have to possess a certain degree of arrogance to let people know you mean business. Now before you start shaking your head in disagreement and disbelief, let me try and define what I mean by entrepreneurial arrogance.

Arrogance is confidence on crack. There’s a fine line when confidence turns into arrogance and startups straddle that line a lot. Confidence is an function of training, a fundamental belief that you know what needs to get done because you have the right tools and training to do so. Arrogance on the other hand, is confidence in spite of training. It is the belief that you can meet the problem head-on and solve it regardless of sparse your intellectual and financial arsenal maybe. It is the conviction that you are no way less than the other guy who claims to have the solution to the problem you’re trying to solve but won’t show you how.

Arrogance is a also a good way to compensate for size. When at IBM, you had to be humble because you were compensating for being a 800 lb gorilla with an huge arsenal of resources so even the slightest stench of arrogance and you’d put off your customers. In other words you had to speak softly because of the big stick you were inadvertently carrying. However, as a startup you don’t have the same brand recognition, and hence the person on the other side of the table can easily mistake your humility for a lack of confidence. This is both contagious and deadly and must be avoided at all costs.

Keep in mind, that I’m not giving a blank check to arrogance. The willingness to learn from our mistakes and listen to our customers requires a high degree of humility. However, when you’re in a startup you deal with so much C.R.A.P (Crticism, Rejection, Assh*les, Pressure), that just being confident doesn’t cut it. You have to be arrogant enough to shrug it all off and continue to dance to your own music, no matter how off-beat it may sound.

Now, the problem is you can’t be selective with arrogance and perhaps the reason why entrepreneurs get the reputation they have. You cannot turn it on and off at will and more often than not end up overdoing it before you find the balance. I don’t think I have, so if you do find my head is up my butt, do let me know…..nicely.

Quote of the Day

And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye mighty, and despair!"
Nothing beside remains: round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.

                                       -- Ozymandias by Percy Bysshe Shelley

Startup Lessons: Ignorance

My blog is in danger of going stale due to my schedule-induced blogger’s block. Since life’s been getting in the way, I figured I’ll just blog about life itself. This new series I’m starting is a laundry lists lessons I’ve learnt in the past year and a half at CallFire. It’s not without hesitation that I share these lessons. Not only are they a reflection on my many personal shortcomings but also reflections on a journey that is very much in progress. So take it with a grain of salt, and of course, feel free to disagree.

My first lesson was revealed to me a couple of weeks ago when I was part of a panel discussion at the Bren School’s HiTEC competition kick-off. The panel consisted of Karim El Defrawy and myself and was moderated by Jeff Greenberg. It was a very open and honest discussion about our experiences, mine in running a successful startup, and Karim’s in winning last year’s competition and his subsequent efforts to launch his company.

The hITEC competition tries to foster innovation and entrepreneurship among Bren school students by providing a level of formalism to the creative process. I felt I dropped a minor bombshell when I mentioned that when we started out we didn’t have a clear product spec or a business plan. The focus was on delivering features that our customers would want in a market space that was (and still is) very nascent. All action came from that single focus. It was very short-term, very quick paced, and with little time for long-term vision and mission statements. I guess what surprised the audience the most was the consistency of the short-term focus, i.e., since I didn’t know what was going to happen tomorrow, let me focus on getting things done today.

Learning to accept the feeling of “not knowing” is a tough pill to swallow. All your adult you’re programmed to seek to be the expert. You get your first job, build your career by showcasing what you know not what you don’t know, yet entrepreneurship is the perennial discovery of your own ignorance. In fact, I would argue that a significant portion of the infamously long work weeks is spent discovering of all the ways that don’t work rather than finding ways that do. It is demanding, and can be very demoralizing. What keeps you going is a focus on problem solving, and of course passion for your product. So while we may not have had a business plan, we never lacked business focus. While we may have not known, we never lost our tenacity and at no point did we lose sight of the customer’s need. Instead of focusing on defining the problem, we defined the solution, and then work our ways back from there.

This was, and still is, a tough skill for me to practice. Conventional logic asks you to state the problem before you solve it, however more often than not, you have to state the solution (or desired result) and see how close you can get to it. You have to turn the problem on it’s head and use unconventional approaches to get to the solution. Sometimes those approaches will not be pretty, but as the rodeo credo goes, you have to “f**k the form and grab the horn”. So, to all those starting new ventures, I’d suggest that it’s OK to have a big goal and yet not have an effin’ clue of how to get there. Just take one step at a time, keep learning, keep trying and just maybe you’ll get close.

 

Quote of the Day

The only true wisdom is in knowing you know nothing.

                                                     --Socrates

PS: The HiTEC site mistakenly lists me as a co-founder. I am a partner in the firm and employee number five, however the title of cofounders rests with others.

FriendCast Taking Off!

Friendcast (CallFire’s iPhone app) has been downloaded more than 3,500 times! It’s become popular enough for TMCnet to feature a video demo on the application. Cool stuff!

So if you have an iPhone and haven’t downloaded it already, do so. I’m sure there are people in your contact list who would love to hear from you.

Quote of the Day

Each contact with a human being is so rare, so precious, one should preserve it.

                                                               --Anais Nin

Friendcast Mentioned in MacWorld

Friendcast—CallFire’s app for iPhone users got mentioned in MacWorld roundup today.  As the article states, it’s an excellent way to send out a broadcast message to multiple iPhone contacts with simple taps on the screen. All the people to whom I’ve given demos seem to love the app. They see uses for it like last minute changes of venues, sending out mass greetings (the holiday season is already here folks). Those without iPhones found one more reason to get one! So I’d encourage all those with iPhones to download this app. It’s fast, friendly, and did I mention free?

Go on! Socially network using—voice—the  natural communication form.

Quote of the Day:

If I am to speak ten minutes, I need a week for preparation; if fifteen minutes, three days; if half an hour, two days; if an hour, I am ready now.

                                                                     --Woodrow Wilson

Chasing the Light

Every evening, at 4 PM, Lucky the VOIP dog comes to my desk to chase the rays of light reflecting off the surrounding buildings. It can get annoying especially when he starts attacking your feet, but then how can you get mad at something that looks as you like that?

Of Principles and Technology

I am a contributor to the ICS alumni blog, my latest post is about computing principles and their timelessness.

On a side note, the vista problems I was having (the random locking up) was it seems, a hardware problem, or should I say a user problem. Turns out, it was locking up because of heat from the processor. The heat of the processor was because the vents were blocked by dust from all the Southern California commuting. I blew air through them to clean it out, and so far the laptop hasn't gotten any hotter than warm, and my OS hasn't crashed yet. So that's my story so far, and I hope I can stick to it. As for all that angst against Vista, most of it is still justified ;-)