Telepocalypse

OPINION://WAM, bam - thank you, Ma'am!

This essay is rather unlike anything I’ve written before on this site. Don’t worry, it’s very much about the separation of service from connectivity, and its effect on the telco industry.

But this time, it’s personal.

This is the story of Sprint’s pioneering, and failed, effort to become the first telco to turn itself into an open application and business platform.

The story starts in 1999 in Dublin, Ireland during a warm and pleasant summer.

At the time I was still a consultant at Oracle Corp., based then — as now — in Edinburgh, Scotland. I was working on a project for a somewhat fly-by-night supplier to Eircell. We were creating a custom Web-based bill-any-pay solution. Oracle was building the back-end, and as a database expert I was overseeing the custom code that imported all the millions of call detail records every night. The supplier was building the front-end, but somewhat lacking in in-house management skills had brought in a contractor, David Anderson. David hails from the area southwest of Glasgow in Scotland, and his towering presence and Scottish brogue are unmistakeable. David managed the team building the Web UI.

I have an enduring memory of watching the solar eclipse standing outside the office that summer, and still have the burn-marks on my retina to prove it.

We got to be good friends on the project, having a common interest in software development process. (I was churning out working Pro*C at several times the same rate a team of 2 had previously been churning out nonworking PL/SQL, until they got kicked out…)

Soon I’d wrapped up my work and moved on. I unexpectedly got a note from David in the early autumn in 2000. How interested would I be in going to work in Kansas City to change the world?

This could only mean one thing.

Time to get the atlas down and find out where the hell Kansas City is.

Since leaving Dublin, David had moved off to Dallas, TX to work (indirectly) for Nokia, soon to move on in the Internet frenzy to Sprint. Sprint was at that time divided fiscally and culturally into Sprint PCS — the wireless business — as well as Sprint Local and Sprint Long Distance. David had gone to work for a maverick VP, John Yuzdepski, running a classic dotcom era outfit, SprintPCS.com. This was constituted as its own independent business unit, set up in an overcrowded and uninspiring low-rise in the middle of a so-so neighbourhood just over the state line on the Missouri side of Kansas City. The BU had sole responsibility for construction, marketing, finance and operation of all wired and wireless Web offerings — and the boss was one of only four people empowered in the company to bring products to market.

That December I took a Friday off work to fly out and meet David and John for the weekend. Travel wise, it was a disaster: the flight from Glasgow to Toronto got diverted to Ottawa because of heavy snow. Our subsequent attempt to land in Toronto took two attempts. My direct connection to KC was long-gone, so I was re-routed via Chicago, only to stand on the taxi-way for 45 minutes to get de-iced. Missed my connection in Chicago, and ended up arriving the next morning.

Perhaps I should have taken the signals from the gods more seriously, but after a few good meals in an equally freezing KC, I’d been talked into it. By the end of April 2001, H1B visa in hand, we were resident in deepest suburban Overland Park, KS.

The release of an upgraded data network was prompting some hard questions from John’s boss, the SVP of Marketing, Scott Relf. Sprint’s main “data” revenue was from 40¢/minute overage from casual use of the 2G wireless web product. Scott’s challenge was this: as minute buckets got bigger, and as data pricing went from minutes to bytes (or flat-rate), where does the money come from?

Probably a question you want answered before you commit to a billion-dollar network upgrade, not after. But never mind.

The result was an effort to create a crack skunkworks inside SprintPCS.com to map out a vision for data services at Sprint. This is where the fun and fireworks start, because you’ve already got network, IT and marketing teams who believe this is their dominion.

The core staff team comprised four people: David as leader, myself, Dan Vacanti — a rare MBA who can write EJBs, and Wenqi Shen — a usability PhD. We had the support of a few developers to help build demos.

Somewhat bizarrely, David was not fully relieved of his day job of running a team of 20-odd developers building critical software to support the “3G” (i.e. CDMA 1xRTT, i.e. not really 3G) launch. (This service was later to be called “PCS Vision” — itself a brilliant marketing conflation of connectivity and service.) The only way this ever functioned was (i) David putting in an inhuman amount of work, (ii) having some kick-ass developers on the team, and (iii) establishing a development process that allowed him to leave most of the management of the group on auto-pilot.

This left him with a semi-formal reporting structure to the Senior Director in charge of software development, and a semi-dotted (or is that dashed?) line to John, the VP&GM. Being the same pay grade, I couldn’t report to David, so had a non-functioning report to the same director; we barely spoke in the time I was there. Even more bizarrely, the wife of the Senior Director was employed as a Director of Architecture. This, to say the very least, was against HR rules.

And since David’s team were outperforming other teams under our Director, and outgunning the over-confident and under-experienced architects, this created an atmosphere of intense rivalry and tension. We had no support base inside our own business unit as we were all too often making our formal boss look incapable, and his wife look incompetent.

It all added up to a serious HR mess.

Nonetheless, we approached our challenge with gusto. I’ve never worked so hard in my life, and Oracle and previous employers haven’t exactly gone lightly with the whip. But it was fun. Our remit was only to design a unique wireless web experience. We were moderately familiar with iMode — remember, this was before iMode really hit its stride. The lesson we had already taken on board was that it was better to take a small slice of a big pie than a big slice of a small pie.

Yet our approach differed dramatically from DoCoMo in several ways.

Firstly, we had put the whole user experience front and centre. Not only a portal and a payment mechanism, but also addressing the usability barriers. Smart systems for automatically selecting the portal content most likely to be of interest; personal data and profile sharing, to eliminate triple-tapping; a central address book, with an API into it; APIs into our messaging functionality; and so on to calendars, preferences, events, etc. In other words, a broad-based set services application platform that opened up both network elements and business processes.

We had also put a lot of effort into privacy and anonymity. We planned to insert a unique token into the HTTP request header of every page. The application could interact with our platform to request data on the user, or send a message. The token could be used as an identifier for the API call. This means users compromise as little of their privacy as possible. They couldn’t easily be tracked or identified without their consent.

Technically, our approach was very different to iMode, too. Some of you will no doubt wince reading me describe my earlier advocacy of “smart network” approaches. Boy, do I cringe too. But there was a logic to it all. We had to face the “tyranny of the installed base” — on day 1, 100% of the users were legacy 2G phones. Java in the handset was unproven, and any other software burdens on the handset unimplementable. So the only way out was to make the smarts sit in the network edge.

This means that if you tried to access a premium content site, and hadn’t paid, or your subscription or access rights had expired, then you would instead be presented by a network-generated payment authorisation page instead. All the content provider had to do was create an ordinary web site, and tell us what URL patterns to intercept, and what payment to associate them with. They then restricted access to only requests coming from our proxy. No need to install any special code or comply with complex protocols.

This wasn’t a unique approach, as we later learned — Firstgate were doing the same thing in Europe, unbeknownst to us. None of the suppliers we issued an RFP to knew of any ready-made solution.

Our vision was broader than this, though. Need some profile data on the user? Tell us what you want, using a URL pattern. We’ll pop up the authorisation screen if the data is already in the user profile; or a data entry screen if not. The result is then posted into the HTTP header of the request to the web site provider. In this way, we would have cracked the silos between different application providers.

The large amounts of stateful profile and preference data accumulated by Sprint don’t exactly do you any harm either when it comes to retaining customers. Indeed, by making the portal experience an adaptive, learning one we intended making this idea of leaving Sprint about as painful as getting a divorce. You’d have to train a new partner in all your quirks and dislikes.

(If there are any evil telcos out there to whom this sounds like sweet music, consultancy rates available on request…)

The barrier to entry to the two-guys-in-a-garage type developer would have been very, very low. Rather than just gun for big-name content, we’d have opened up the field. iMode was partly propelled by simply putting the most popular sites to the top, and letting the system auto-discover what was compelling. We wanted to go one step further and use cutting-edge collaborative filtering to suggest the most relevant content to you personally. If this came from Gus and Dawn in Lincoln, NE rather than Disney Corp, so be it.

A long-term hope had been to engineer every Sprint handset to have an illuminated Sprint logo, not just a printed one. Then any interstitial screens shown by Sprint would be re-inforcing Sprint as a trust-mark. Sprint is what protects your privacy, security and anonymity. (Stop giggling down the back, please.)

This effort was not synchronised in any way with the parallel — and better supported — effort to deploy Java in the handsets in Sprint. The conflicting and uncoordinated efforts of the Network, handset and .com groups showed that Sprint had no effective CTO leader, even if one (inside the network group) formally bore that title. Not helping matters was our VP’s tendency to make big promises of innovation while the basics of running the web site and developing the PCS Vision support infrastructure needed urgent management attention.

By October of 2001 we were ready to announce our platform plans to the world. Sprint laid on a developer conference at Caesar’s Palace in Las Vegas. In anticipation, we got the marketing communications people to pick a name for our baby. Dumbstruck by inspiration, they chose “WAM” — “Wireless Application Manager”.

We got a good turnout, despite the telecom meltdown being well underway. David did the heavy lifting announcement work; I just blathered about some of the background and speculated about where this might run to. It was exhilarating — up until 2am preparing, back up at 5am for rehearsals. But it all came together.

In the background, things were unravelling. The network division hated us with a passion. They had a group devoted to SIP and IP technology that would have been happy to see the earth open and swallow us up. They were also over budget in the 3G rollout, starving us of potential funds. The mainstream marketing folks only cared about getting content deals for ring tones and Java games. The IT groups were having a meltdown under a failing zillion-dollar program to in-source billing. Big plans for application platforms didn’t count for much — even if the SVP of Marketing was in theory the sponsor.

The SVP of strategy got some external consultants in to review our activities. Their recommendation was an “Innovator’s Dilemma” type approach, and that our platform should be spun out as a technology start-up. However, divorced from a guaranteed network to distribute its services, it had no chance of survival. Another round lost.

Personal relationships between the team and management were under a lot of pressure. We’d been working out guts out, our wives were tired of the politics and stress. The urgency of getting a working PCS Vision launch completed was erasing all other activity in the division. We found ourselves sucked into it, David chairing task forces, me writing the 3G download requirements spec, our developers reabsorbed into delivery tasks. In the end, even basic stuff like an instant messaging app failed to make the launch; the new wireless web — outside our control — was slow and bloated. The back-end was broken in a dozen ways, creating huge customer service issues and dissatisfaction. WAM never had a chance of making it as part of the 3G PCS Vision launch.

The company’s appetite for “doing an iMode” was wilting.

By the spring, it was all over. Our VP left the company in, um, rather a hurry. (The Telepocalypse legal department says: “say no more”.) So did his secretary. (Martin, be quiet.) So did his boss. David quit the company to become a director of development at 4thpass (now a Motorola subsidiary) making content download solutions. (He has subsequently written a groundbreaking book on applying lean manufacturing principles to software development, and is working at Microsoft guiding the development of the future of Visual Studio and MS development processes. You can check ou his blog here.) The business unit was handed over to an interim VP who carefully guided it through to the launch of PCS Vision. The business unit was then dissolved, the team dispersed. It was all over.

There were some executives who really saw how important our platform could be, and saw the option value of it — the negotiating power it gave them with suppliers like Sun, IBM and Microsoft. Some were curious, and at least gave encouragement even if overt political support wasn’t forthcoming. But the overall feeling was one of battle weariness and short-termism in the fallout from the failed Worldcom merger, ION network decommissioning and difficult PCS Vision birth.

That August in 2002 I shamefully had to pretend at the second — and final — Sprint developer conference that the plans for an application platform were still in place. Formally, the RFPs were still alive. I didn’t enjoy telling 600 people WAM was still alive when in my heart I knew this not to be true. Sprint is lucky the vendors bidding all still wanted a functioning relationship; otherwise they’d be looking to sue Sprint to recover their bid costs.

I hung around for another 2 years through the slump in a succession of non-jobs until it was time to strike out on my own. The grim job reaper failed to call as tens of thousands of Sprint staff went through separation therapy. It was a great time to travel cheaply in the USA, and I and my wife made the most of it at weekends and vacations. Although dispiriting not having anything real to do from 9.30 to 4.30, we found other ways of making up for it.

In retrospect, we were naive in many ways. From a purely technical viewpoint, I was only dimly aware of the “stupid network” principles. We failed to start with a business case, and get some real facts on how much a 1% reduction of churn might be worth, and to demonstrate how we might really deliver that. The Japanese culture could accept a strategic initiative on the basis of hunch and logic; an American business culture was too conservative for that.

Critically, we failed to make the right internal alliances and get the broad political support we needed. CEO sponsorship would have been a big plus. I’d now choose a few small things most people could agree on, and just get those done to establish credibility. Build on small successes, no big vision; companies like Sprint can’t execute on projects with high technical and market risk, as the culture isn’t there to support it. I’d now also put voice calling at the front. Can we up-sell people from a wireless web page to a voice call? How much is that worth? Can we revenue share with the content partner? What’s the effect of automatically building address books, and making sync really easy?

Hindsight is a wonderful thing.

But it was a great ride, I don’t regret it for a minute despite the personal stress, and learnt a lot. For a boring old centenarian phone company from Kansas, Sprint is quite a storybook, and WAM is a fascinating page in it.

[Footnote: David helped review this for historical accuracy, but mistakes and libel are all my own responsibility.]

UPDATE: Dan Vacanti adds:

“One other stumbling block that I thought of: Remember that [Sprint was] trying to replace the billing system at the same time that they were launching 3G. That meant that even if we finished the RFP process and actually picked a vendor, we would have never gotten into production as all of the IT release cycles were filled up by the biller.

The story was good, though (even if you didn’t mention me enough).”

Cheers, Dan — glad to give you the exposure ;)

So folks, Sprint happily stumbled along with a failing billing project, writing off $300m at the end; but it couldn’t find a few million to become a viable platform player.