TJ's Kaleidoscope

Lessons from Swimming

This year has been a tough one for my feet. It all started with a stress fracture from a hike back in March, and subsequent false starts where in I'd think it'd healed, only to go back and wait it out on bleachers. Just when that seemed to be done with, my other foot ran into some major snags that required more attention, details which at this point are of little consequence. The end result is that it basically threw my entire physical routine in a tizzy. It got bad enough that I had to withdraw from the Long Beach Open, quit any kind of foot-based cardio including ellipticals and steppers.

My workout schedule, for the most part has remained unchanged for a couple of years. Working out three-four times during the week, combined with a weekend's worth of Tennis with the occasional hike and kayaking thrown in the middle. I'll admit that CallFire's had been making that three-four times down to two-to-three. Regardless, I still lead a pretty active schedule and almost everything I indulged in required the strenuous use of my feet. The lack of cardio wasn't doing my health any good, and foot-based options nil.

It was then I decided to retake swimming--the sport to which I never quite warmed up. My experience until then had been limited to neighborhood recreational pools and for reasons other than exercise. It was then no surprise that I was horribly out-of-shape and out-of-form when swimming in a regulation pool. Not only could I not finish one lap in one go, the wake left by my actions would have made a trawler proud. However, with no other sport to turn back to, I was forced keep chugging. I went to doubling my laps per hour in about two months. More importantly, I began to enjoy swimming and love the hour of complete disassociation.

I know what I faced is trivial compared to the things some of the people I know and read about. General Wesley Clark, for instance, loves swimming because he lost major chunks of his foot in the Vietnam war. Yet, the personal nature of these setbacks have taught me lessons that, quite honestly, could only be learned the hard way. If I hadn't the back-to-back foot problems, and used that opportunity to pick up another sport, I'd never have experienced the lesson that learning a new sport brings. When I'm running on the treadmill I use the TV and my ipod to create a chaotic environment that allows me to forget the burn in my lungs and the rote nature of my actions. When I'm playing tennis, my play is influenced significantly by the person on the other side of the net and the point gets close, I stick to plays I know, to what I know will help me win--whether it works or not. Swimming on the other hand, accords none of these distractions. First, I'm thoroughly incompetent in the pool, so unlike Tennis there's not comfort zone. Unlike running there's no induced ADD that allows me to forget that I'm running short on air, or silence that voice in my head that tries to distract me by replaying the events from the day. I just have to focus on completing the lap, one stroke at a time, and whenever I do lose concentration, it's self evident.

I hope to get back on my feet soon, and back to running and playing Tennis, but I don't think I'll ever give up Swimming, not because I've gotten better at it, but because I've come to enjoy it, the fear of coming across as a fool has been long been replaced by the exhilaration of learning. The implicit understanding that yes, I will suck at it but if I can keep at it I will do better today than I did yesterday, that's a good thing and that's life.


Quote of the Day

When you learn a sport, you go through the cycle of humility. You learn about yourself.

  --Wesley Clark

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

IE 6 is not supported. I wish.

If you haven’t noticed already, CallFire is going through a major site redesign. It’s a redesign that’s very much a work in progress for it’s not just the look & feel that’s changing but we’re also laying the foundation for what we hope to be the next stage of explosive growth. But I digress.

One of the biggest challenges from a UI perspective has been keeping the site universally accessible. This is of course a breeze in FireFox & Chrome, but as any web designer will know, Internet Explorer, in all it’s flavors is a bane of any website’s existence. So, we we’re having quite a few issues with IE 6—that archaic browser that should never have seen the light of day—and yours truly decreed that we shall no longer support IE 6.0. Wishful thinking.

I got inspiration for this brilliant idea from YouTube’s message (shown above) and figured, if Google can do it, why can’t we? Small problem. Unlike YouTube, almost all of CallFire’s visitors are paying customers using computers that have software installed by change-resistant IT departments that were flooding our support lines. So as much as it would be fun to lay down the law, I’ll have to grudgingly acquiesce to reality. Influencing Change , it turns out, is hard for it seldom happens on your timetable.  Back to the testing cycle folks!

Quote of the Day

They say that time changes things, but you actually have to change them yourself.     

                                                                              —Andy Warhol

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

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