Thursday, May 31, 2012

CEO: Helping or Hurting?

A thought provoking exchange with someone on the Gnip team last night, wound up revealing a behavior I've developed, unconsciously, as CEO.

As CEO of a 25+ person company (Gnip's at around 40) you can't deep dive on as many challenges during the day as you used to; you simply don't have the time. As a result, you move your observation, critical thinking and problem solving skills up a level, and accelerate the overall decision making process. If you view what you have to get done as a queue, simple queueing theory breaks down in this role because the rate of incoming things to handle vastly outstrips your ability to handle them in a timely manner, if you maintain your original, average, rate of handling things that come up. In short, you have to come up with new models for evaluating an issue, and resolving it, faster.

The trick is in NOT building a model that yields sloppy decision making. You do that by ensuring you distribute the challenge load appropriately, to the right number, of the right (smart) people, and fan out overall decision making such that the right time is allotted to the business decisions that have to get made everyday, at large. Again, your job moves up a level in the process.

Back to that behavior I mentioned earlier. When I see what appears to be an inefficiency anywhere in the business or on the team or in a process, I go through the following process.

  • Does it matter? My brain identifies inefficiencies at the quark level which can often be completely irrelevant in certain context. I have to constantly apply this gate otherwise I'd drive everyone completely nuts (I'm sure I'm doing that already anyway though).
  • Is the person responsible for the thing that includes the inefficiency on top of it?
    • If yes, leave it alone; you'll only aggravate the situation by sticking your nose in, and wind up wasting time.
    • If no, appropriately get your proposed solution on the table. Some individuals welcome/desire external input and suggestions. Some do not. You have to tailor your approach accordingly if you're going to successfully eradicate the inefficiency. If you get this wrong, you'll wind up in the situation above where you're doing nothing but sticking your nose into someone else's business.
Rather than diving in and problem solving everything I see each day, my filter has evolved to account for the fact that we have an awesome team executing brilliantly. That said, when I do see something off kilter (now matter how great everything is, obviously stuff comes up), I'm developing a new way of quickly engaging the situation without having the full context of the situation at my fingertips. Getting that right takes practice.

To the guy who's business I stuck my nose into last night... sorry bro... thanks for the reminder.

Sunday, May 27, 2012

Unspeakable URLs: Y! Japan's Stronghold

While in Japan a couple of weeks ago I had a fascinating conversation with a local software/web person about URLs, Japan, and the mystery (to me) that has always been Y! Japan (Y! Japan is a joint venture between Y! US and Softbank). Now I get it.

Imagine a technology forward society latching onto the Internet simultaneously with the US in the mid-1990's, with great network connectivity and web browsers everywhere. That was Japan. Now realize that the Japanese language is not Latin based, so the characters used to represent words and sentences are vastly different from Latin based languages (like English). No surprises thus far, however, if you are an average English speaking US native, imagine trying to use the web with Japanse characters/words in the URL instead of familiar Latin based characters. Simply put, does http://例え.テスト/メインページ mean anything to you? If you don't understand Japanese, could you convey that over the phone? Could you remember that on a billboard? No, and no are the latter answers of course. The inverse has been the case for Japanese since the dawn of the network which resulted in a completely different initial navigation use case; early search engines.

Enter search engines/directories; Y! specifically, waaaay back in the day long before Google was even around. In Japan, interfacing with the network was done via interfacing with Y!; not the URL bar. As a result, the URL's relevance as a branding mechanism or significant navigation model never caught on. The result is what you'd expect, whichever search engine got to the market first, would be ingrained in the populous.

For those of us in the US, Y! has fallen on hard times. For those in Japan, Y! is synonymous with the Internet itself and they continue to dominate the country in terms of search traffic, property use, and oveall web traffic (most of their products are in 1st place with everyone else in a far off distant 2nd). Y! Japan was there first, and they closed a severe language/character-set gap between the URL bar and its audience. Japanese don't convey URLs in general, instead they convey a keyword or concept, and the receiver of the information will simply search for it on Y!. That results in your Y! search ranking in Japan being the king of everything. If you don't rank well in Y!, you don't exist.

It's worth noting that recently chunks of the network started roughly supporting IDN (internationalized domain names), though they have not caught on at all (oddly).

Back to my conversation with the Japanese local... he was pointing out how frequently US firms come into Japan and expect their marketing efforts to simply translate directly into the Japanese market (after localizing the marketing campaign and products), yet they rarely pan out. He was suggesting, which makes complete sense to me, that the URL component (often the crux of a US marketing campaign), even if translated to Kanji, falls completely flat for the reasons stated above, and it is precisely that which is used to measure success.

Saturday, May 26, 2012

Radioactive App Store Updates & User State

This whole post applies to desktop browsers and cookies too, but the use case is underscored on a mobile device because user input is relatively more difficult.
As a mobile app user (e.g. iOS apps) I want to tell an app as little about myself and my preferences/needs as possible in order to get to the functionality I need quickly, because authentication steps and preference settings are excruciatingly painful to use, no matter how efficient they are.
The authentication step, on iOS, is getting better thanks to Twitter being baked into iOS. However, I've found that many applications drop my auth/pref state after I do an App Store update of the app. That has resulted in me treating updates as radioactive, not because they're likely buggy, but instead because they'll likely blow away my auth and/or app-specific state (e.g. previously selected items or favorites within the app), and going through the auth steps (entering a username and password, or clicking through oAuth steps) is just too much of a PITA.

I'd ask that app stores require the developer to disclose whether or not the update will break user-specific state, so I can decide whether or not to apply the update. Without this, I'm finding that I just don't install updates anymore out of fear that they'll break my state.

I'd also ask that all of this state/db be backed up in the cloud somewhere so when device firmware resets are done, all that app-specific user state can be restored.

Wednesday, May 23, 2012

My First Pitch Deck

While working at a large company back in 2006, my frustration with lacking innovation reached threshold and I a) wanted to do something inspirational again, and b) wanted to finally plant my roots down in Boulder. I blogged about my ultimate leap into the abyss, and finally into my current gig, Gnip (a social media company), awhile ago in this post. Yesterday I stumbled across what I would now squarely call a pitch deck (not sure why, but I didn't call it that at the time) that I presented to that large company in 2006. I've been asked about Gnip's pitch deck many times, but it's rarely applicable to what the requestor is asking about (Gnip's initial pitch was relatively "easy"). However, this "Glider" deck feels more applicable; it was very hard to get buy-in. It's an example of someone with an idea, structuring the "why," "what," and "how" in a pitch deck that actually worked.


I'd severely criticize the pitch deck today, but at the time, in the context, it worked; the project got funded!

A fun thing about the deck is that it is rooted in my entire world today; data. I love long arcs. I've loved thinking about the larger network of data plays for the past six years.


Here's the deck. Names redacted to protect the innocent.

Tuesday, May 22, 2012

What's Your Exit Strategy?

Job candidates still ask this question a lot. I'm experiencing the current wave of it at Gnip where we're doing a lot of hiring. I'm always surprised by the question because it's vestige from the late 1990's bubble when the answer you were looking for was "IPO in 9-12 months. We've assembled Joe and Jane on the finance side who have taken a million companies public in this space. We have all the right connections and buddies in the right investment banks. We know all the right insiders who will give us great open market valuations." etc.

But, the IPO market isn't like it was back then, so why does the question even get asked? My hope is that the candidate is indeed looking for depth and realism, rather than anything remotely close to the above. In that case, I like my answer. If you're indeed looking for the "IPO" answer, you should spend some time looking at IPO market data/exits now, vs. the late 1990's, and reconsider what you're after.

I've found my answers have actually felt really good and have hopefully been really useful and informative for candidates. They go something like this.
As a management team, we actually don't think about exits much. We're intensely focused on building a strong business and believe doing so will lead to the right exit. If that means we're insanely profitable, and independent, then maybe we just profit share amongst ourselves down the line. If that means the right buy-out opportunity presents itself, then we'd do that. If IPOs make sense again, then maybe we consider that.
That answer focuses everyone on the right thing (money, and therefore product), and illustrates that we're leaving our options open. There is no "one way."

What I like about that answer, which naturally fell out once many moons ago, is that it illustrates how realistic we are. Mind you, Gnip is in the Enterprise software space which is measured on money (not the millions of consumers you're going to get to use a consumer app). Different industries obviously have different approaches and strategies.

Sunday, May 13, 2012

Life Spans: A Career in Connections


All of my programming life has been spent playing with sockets; client and server. The guy that introduced me to the networking stack was Lou Montulli, and he said something to me as an impressionable kid that has driven everything I've done ever since: "the URL is the only thing that matters. If you are writing code with that in mind, you will win." I took that statement to heart and doing so has yielded a priceless life experience so far. There's simplicity in that statement as well as, wisdom, truth, honor, religion, direction, revolution, evolution, complexity, and mantra.

It all started with the Lynx text-browser networking library; an originally serial thing. That library was sucked into Mosaic/Netscape and parallelized in order to accommodate fancy things like images and JavaScript. From there, we struck a performance balance between the desktop's ability to parallelize socket i/o schedules, with the rendering engine's ability to render. Connection speeds started to improve (dial-up to broadband), and TCP stacks standardized; relative network stack homogeneity set in; Cisco, Apache.

Scaling both sides of the socket (client and server) turned into a game of threads, multi-proc, asynchronous/event-driven programming and figuring out how to get as many balls in the air as possible, and how to get them back on the table in an organized manner. The entire system moved to this challenge, and tremendous innovation occurred at the hardware and software level. In the mid-2000s I spent my time trying to optimize AOL's publishing infrastructure to yield thousands of short-lived parallel connections per server in a real-world publishing environment.

Then something unpredictable happened. Social media thrust massive amounts of dynamic, user generated (UGC) content into my world at Gnip. Everything I'd been working for turned around 180 degrees. Instead of optimizing for lots (end consumer browsers) of short-lived, HTTP transactions in a web browser or on an HTTP server, we needed to focus on few (relatively speaking in the world of "enterprise") long-lived HTTP transactions. Dozens of customers per NIC, instead of thousands. State-full transactions instead of state-less. At Gnip we need connections to last weeks on end (and longer), instead of sub-second. Yet, we and our customers want everything to just look and feel like the URL we've all come to know and love.

The result has been a massive engineering exercise that continues today; Gnip. The public Internet has been plumbed out as a system that supports bursty, short-lived, HTTP transactions. Yet, Gnip users want a sustained HTTP transaction that can handle 10x volume spikes sans issue. From highly elastic public cloud hosting solutions, to dedicated hosting providers, we've spent a lot of energy to ensure network clarity to support these needs.

One "feature" that I miss about my old Internet is statelessness. State-full connections cannot break. If they do, bad things happen, and contingencies have to fill the gaps. Traditional queuing theory is the monkey on every Gnip engineer's back. Buffering, backfill, replay, index pointers, sustained throughput volumes, cascading, fanout, MTUs, packet-loss, and processing latency are our domain. I view our system as an aqueduct delivering uninterrupted streams of public consciousness to those who need it. The challenges inherent in building something like this are writing great chapters in the lives of everyone on the team.

I find it curious that while the URL is still the center of my universe, what's behind it has changed dramatically over the course of my career. Something so simple, yet so complex.