Previous month:
October 2011
Next month:
December 2011

November 2011

What's Your Passion?

There seems to be a question that's in vogue on the interviewing trail these days: "What are you passionate about?"  It's a good question, especially for startup hires.  You're going to work your tail off, so having the proper motivation is critical... and "I'm in it for the money" isn't going to cut it.

The preferred answer seems to be "I'm passionate about..." and then fill in the particular application or service the hiring company is built around.  I think this is misguided.  A better answer would be "I'm passionate about building a great business."

Why? Because most startup's don't succeed at whatever they started out doing.  Sometimes, what you thought was a product is really more of a feature (see this post from Mark Cuban for example). Often times, you're iterating toward the product or service that's going to resonate with the market.  So what happens when the thing you've identified as "your passion" isn't accepted in the market? Some would argue in favor of staying the course, figuring that the market will eventually understand the value of what you have to offer.  Maybe.  But more often than not, these are the people who believe in the phrase, "we didn't lose, we were just behind when time ran out."

The successful entrepreneurs are the ones that set aside their own feelings and read the market acceptance information for what it is.  They adapt their product vision to address the opportunities as presented by the market.  Are they passionate? Absolutely.  Are they obstinate? Not so much.


Thank a Veteran

The poem Death of the Ball Turret Gunner by Randall Jarrell made an impact on me, as it has for many readers. In my case, it was a little more personal.

Here's a photo of my father (on the left) with one of his high school buddies, Nathan Sanderson (on the right).  My father, Nathan and another buddy, Daniel, all enlisted together when the US got involved in World War II.  Norman and Nathan joined the Army Air Force (before the Air Force was a separate branch of the military).  Daniel joined the Navy.

 

Norman Callahan and Nathan Sanderson2

My Dad's job was filming the B-17 bombing runs (I may have a reel of his footage).  It's not clear to me if he was in the plane (although his gear makes it look like he would have been) or just set up the cameras for some kind of automatic recording.

Nathan was a ball-turret gunner.  During the early part of the war, B-17's had to fly without fighter escort.  Since this made them sitting ducks for the Luftwaffe, the bombers were armed to to the teeth as a defensive measure.  (Formation flying also helped a great deal).  The ball-turret gunner sat in a bubble underneath the plane's fuselage, in a kind of baby-seat contraption, and handled two .50 caliber machine guns.

During one of the bombing missions, Nathan's B-17 was hit (either by flak or a German fighter plane).  The rest of the crew apparently was able to bail out, but Nathan was stuck in his turret and died when the plane hit the ground.

My Dad's other friend, Daniel, served on the USS Indianapolis.  He was one of the hundreds killed when the destroyer was torpedoed and sunk by a Japanese submarine.

Only some veterans fight, and only some of those are injured or killed.  But they all take on the job knowing that this could be their fate.  We owe them a lot, starting with "thanks".


What Do You Want From Life?

Department of Obscure References

I found this posting on Tech Crunch interesting, as it highlights one aspect of a decoupled mobile platform architecture:  managing OS updates.

The chart nicely illustrates the difference between the Android and iOS device platforms.  Apple regularly updates their iPhone devices with current versions of their iOS operating system.  Google?  Not so much.  In fact, the chart shows that some Android-based mobile devices ship with out-of-date versions of Android from the date of introduction.

You can imagine the company reactions.

Google: "Hey, what do you want? We just make the OS and ship it."

HTC/Samsung/Motorola et al:  "Hey, we just take the latest OS release, put it on the device, and ship it."

Verizon/Sprint/AT&T et al:  "We don't know how to keep devices current."

I'm not going to weigh in on whether Apple or Google's strategy is better (and for whom). But the situation does illustrate the choices you face as a device maker, OS provider, and mobile carrier.  If you're Apple, you've built a company that obsesses over every detail of a customer's experience with your product.  So naturally you're going to control both the hardware platform and the OS that drives it.  And you're going to spend more than a little time checking out the applications that other people are developing for your product, but that's another topic for another time.  If you're Google, your model is quite different.  You're trying to build share as quickly as possible, so you're going to give away the OS (subject to patent infringement limitations), kick-start the third-party applications community, and get your OS on as many smartphones as possible.  Since you're Google, you're going to bring out a new OS version every quarter (although the release schedule is anything but smooth, with six months between some releases and one month between other releases).  And since you're not in the hardware business, the need to test OS versions on a variety of current and recent devices is Someone Else's Problem.  If you're the mobile carrier, you may or may not care... but you're ill-equipped to manage this kind of hardware-software lineup.

When I worked at iPass, in order to aggregate and resell what we called "Mobile Data" services, we had to supply the 3G modem card along with the other bits that made up the service.  Suddenly, we were a hardware as well as a software company.  We had to manage inventories of modem cards... different cards for different mobile data networks, with different device and OS dependencies.  And this was our problem, because the mobile carriers were unable to manage it.  A mobile carrier might take six months or more to qualify a particular device, train its Sales and Support teams, and roll out the service.  In an Android type of world, this means the service would launch with an OS one or more releases behind the current version.  So we managed the lineup of OS releases and target devices, and in some cases provided the OS update function on behalf of the mobile carrier.

So what does this mean if you're Research in Motion, trying to maintain relevance in what people want to tag as a two-horse race between Apple and Google?  It means you can add value by 1) ensuring everyone knows what versions of OS work with what devices, and 2) making sure that you provide OS updates.  This doesn't put you ahead of Apple, but it does put you in a better position vs. Google.  Google would have a hard time keeping OS versions and devices straight, even if it wanted to do so (and it doesn't).  Apple will do this because they're Apple, so RIM has to find other ways to compete against them.

Some people would respond that keeping the OS on a device up to date doesn't matter, and they're right--until it does matter.  It's a bit like saying that insurance doesn't matter.  As a consumer, you want the device--including the applications you've downloaded onto the device--to just work.  You don't care how or why, just that everything works.  And if you're RIM, you're in the best position to make sure this happens.  And that's good for your customers, and good for you.