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.

"Critical Path" Roles

During an enlightening conversation with another Boulder entrepreneur yesterday we had a short side conversation that concisely exemplified a concept we're all familiar with, but often get wrong when hiring. In my mind, at the highest level of role characteristics abstraction there are two categories of positions, "critical path" and not. 

When evaluating candidates for a given role, you should squarely understand whether or not that role is "critical path," and subsequently whether or not a candidate matches that characteristic. You may be at a stage where all of your open positions are critical path, none are, or somewhere in-between. Bringing someone into a critical path position, who is great at, and wants to be in, critical path roles is a win-win. A mismatch in that headset however will break and neither you, nor the person you hired will be happy.

I'm sure you can call "critical path" many other things, and swap it out with other requirements like "leadership position" (or not), "management position" (or not), "individual contributor" (or not), etc. The point is that you've got to spend time clearly understanding the critical characteristics of a given position, and ensure there's alignment on them between you and a candidate.

Writing the job description for posting is a powerful exercise in vetting what it is you want/need, but I also ask myself "if this person showed up tomorrow, what exactly is it that I'd expect them to be doing?" That's always a great exercise to cut through the crap you may have conjured up, and get down to brass tacks.

Paying for Health: Give Forward

At Lindzonpalooza this past weekend in Coronado, CA, a handful of companies (varying in stage, though most very early) presented to friends, and potential investors. Give Forward stood out in an interesting way for me. Simply put, they're crowdsourced healthcare financing. They've been at it for awhile, and are doing great.

During the Q&A session Yoni Assia asked an intriguing, upsetting, magical, and innovative question (paraphrasing): "what if I could setup a monthly subscription to the service, and if/when I need the service myself, it covers my healthcare bills for me? kind of like insurance."

Great question, and on the surface it seems like it would work. What upset me about the question is that I was intrigued by it, even though I already shell out untold sums of money every year to "cover my health" yet I'm obviously displeased with the current model to the point that I'd gladly subscribe to the additional service Yoni was proposing. It was yet another moment of realization around how bad healthcare has gotten.

Intriguing to think that Give Forward may actually be solving the healthcare financial mess by simply circumventing the money part of it altogether.

It was also disturbing to hear that the healthcare companies themselves are considering getting into Give Forward's game. Chew on that circular reference for awhile and see how it tastes.

What GF's done is awesome. An incredible story of passionate caring in a for-profit model wherein everybody wins. Evidence that we, the entrepreneurs, will indeed find a way around the broken massive industries that have plagued and sucked the system dry in so many ways.

Discretionary Energy

"You're investing in a great challenge when you're applying discretionary energy to it."

I don't recall who first told me this, but it has guided me for well over a decade now. It motivates me to select things to work on that I deem "great." It motivates me to ensure the challenges at work are great enough to engage others' discretionary energy such that it's applied to the challenge as well. I'm fully engaged on a challenge when I allocate discretionary energy to it. If the challenge is something I can just "do," that's great and all, but not as fulfilling in the end.

You can gauge a lot about a company, and the people in it, by whether or not anyone there chooses to apply discretionary energy to it. That energy may be expended during business hours, or not. Niether the amount of discretionary energy, nor when/where it is applied are the point of this post. The point is whether any discretionary energy is being allocated.

If the ratio of discretionary energy to paid-for energy is 0:1, then all that is happening is that a crank is being turned. If the company is not profitable, that's a real capital problem because it's likely that nothing creative is going on to get the money printing press going.

If the ratio of discretionary energy to paid-for energy is 1:1, then things are in high-gear. As we all know, that can be good as well as bad (potential imbalance, burnout, call it what you want).

We should strive to ensure we are in work situations with a ratio of >0:1. For some that's 0.0001:1. For others that's 1:1. However, if it's 0:1, you're not pushing yourself; you're not engaged. You could potentially just be punching the clock.

To be clear, I am not making a statement about work/life boundaries. Some of the most amazing people I've had the pleasure to work with cordon off their "work" life from their "personal/home" life, and apply relatively little discretionary energy to challenges at the office.

Be conscious of your discretionary energy ratio, you'll live a more deliberate and aware life.

Scaling Me 2

This timely post, that I stole the title from, by Matt Blumberg took the words, in a timely manner no less, right out of my mouth. I'm seeking inspiration from Matt (unbeknownst to him) to get some of my "first time CEO" challenges out on paper for therapeutic purposes.

Gnip has grown a lot/fast over the past year or so. I've, idealistically, and at times detrimentally, carried beliefs and values near and dear to me through that growth, thinking they can scale without modification. Some of them scale just fine (e.g. honesty). Some of them don't scale as well.

Transparency

In a smaller team (say ~12 or less) you're all relatively close in proximity, and in thought/conversation, on a day-to-day basis. As a result, there's a general sense of understanding of most topics across the organization. Joe can see Jane's frustration level when she's moving through a challenge. Mark has an ambient sense of how Jenny can power through technical challenges of certain shapes and sizes.

When you move past ~12 people on the team, individuals simply have to compartmentalize more of their thinking, and must drop certain levels/depths of awareness in order to stay productive. The result is less overall context and understanding of everyone else's headspace. To drive the point home, here's an extreme example (something I love to provide, which I'm also learning isn't as effective as the team scales). If your good friend says to you "let's go have some fun," you probably have a decent sense of what that means. If someone less familiar to you says the same thing, you have no idea what that statement means to them. In both cases, the other party was being fully transparent about what they want to do, but without the right context, the latter can leave you dangling. As the team grows, that ambient contextual awareness changes.

As we've grown, it's become clear to me (through direct feedback, and my own observation) that the off-the-cuff transparency I've always enjoyed with my thinking and thought process, can actually be damaging. What I would consider a transparent comment about a certain direction I think we should be going in can be interpreted many was, with many unintended consequences. Matt nails it with the "the CEO said" or the "CEO thinks" points he makes. That stuff can be disruptive, confusing, and derailing.

The result is that more preprocessing (natural for some, unnatural for others; somewhere in-between for me I think) and better awareness of one's surroundings is required. That, to me, can feel less transparent, and my initial reaction to that has been that it is bad. It's required to function however, and therefore I wind up in a place where I view it simply as adaptation to environmental changes.

Staying Connected: Company Update Emails

About a year ago one of Gnip's employees pulled me aside to ask some pointed questions. This person had noticed a few things happen in the office, and let his imagination run wild to the point of believing Gnip was being acquired. In reality, that was no-where on radar.

We talked for awhile about how he'd gotten so far down that mental path. Why he didn't simply ask about it earlier if it was bothering him. What had changed in us organizationally, as a result of our team growth, such that there was such a disconnect between his concern and reality. So on and so on.

What fell out of the conversation is something that I've completely embraced; a bi-monthly (every two weeks) update email to the entire company. I literally start mine with "what's on my mind..." and then a bulleted list of stuff that is on my mind. When I remember to, I also forward it directly onto the board of directors.

My calendar reminds me every couple of weeks to send it. I never spend more than 5 or 10 minutes composing it (usually 2-3). The feedback I receive after each one is incredibly useful, and clearly indicates it's being digested.

The update emails give everyone on the team a view into what's on my mind; with frequency and regularity. They're light, so I don't have to prep for them. They're honest. They're transparent.

Of course face to face 1on1s or all-hands are better, but they're not always possible with people traveling and people out sick. They also lack regular rhythm and frequency.

When I used to manage smaller teams I sometimes did these, but they weren't as useful as they are as the team grows. In smaller teams everyone's simply closer and more connected to what's going on so you don't necessarily need them.

If you're responsible for larger teams and groups of people, I'm now convinced these are imperative (assuming you can't get the frequent/regular face-time which is preferred). If you're the CEO of a growing company... they're required!

And one more thing; they have to be real. They can't be overwhelmed by corporate communications crap.

Gnip is one (leap) year old!

Yesterday (leap day!) was Gnip's four year anniversary. It's been a wild ride to be sure. It took awhile to find the groove (Bijan Sabet coincidentally just posted on this topic), but patience and persistence paid off.

Here's a small flickr set of various shots over the past four years; I wish it was more comprehensive, but it's all I could scrape together with limited time.

Here's a memorable, roughy chronological, timeline. I should do a product timeline at some point, but this one's more nostalgically motivated. Tissue please!

• Meeting Eric Marcoullier while offic'ing out of Foundry Group's joint.
• Two weeks later shaking hands at Amante Coffee across the street from Foundry's office. "Let's do this!"
• Wandering the streets of San Francisco for a few months pitching prospective employees, customers, partners, and investors.
• Sitting in a "desk for hire" office with Eric, mowing through architecture on a whiteboard.
• Waking up at 2am at the Moser Hotel to a party that took over the entire floor of the hotel. We had an investor call/pitch at around 8am the next day. That was the last $100/night hotel I stayed at in the City.
• Incorporating Gnip, Inc in the offices of Ropes and Grey in SF with Eric.
• Our first meeting with Pivotal Labs (who built Gnip 1.0)
• Our first hire, who we parted ways with only a few months after he started. I learned a valuable early-hire lesson there; make damn sure your early hires are generalists and that they carry the same energy/passion for the challenge you're solving as you do.
• Offic'ing out of Pivotal Labs SF. Designing/building software w/ pivots.
• Realization that the cloud was the future.
• Me to a traditional hosting provider: "I need 10 instances please."
• them: "when"
• me: "now"
• them: "how about a few weeks?"
• me: "please close my account." (we fired up our first Amazon Ec2 instances that evening and had a dozen running within hours).
• My introduction to pair programming and TDD. One of the most beautiful moments of my career.
• Our second hire.
• Our third hire.
• Our first "office" (still my favorite office of all time) in an old brick house behind a pharmacy.
• Our plucking of a pivot out of Pivotal to be a Gnip employee.
• Eric's and my first fight. We were wandering around the adjacent neighborhood yelling at the top of our lungs about him pulling a feature from the next day's release because it wasn't "ready." We lowered our voices as one of our employees was approaching us on his way to his car to leave for the night.
• Sitting on the office porch working.
• Sitting on the office porch watching people walk by.
• Sitting on the office porch drinking.
• Our first paying customer.
• The morning a woman from the adjacent office stormed into our office screaming at us about how her car was blocked and she had to go pick her kids up.
• The proximity of the bathroom to _everything_ else going on in that first office.
• Accidentally cutting the trunk-line ethernet cable to the office switch and killing dev for 30 minutes.
• Internal battles around who was going to wash the dishes each day (I won an award for being best dish washer).
• Watching the team write disk i/o drivers/protocols for Berkley DB. Moments of "we're going too far here" flashing before my eyes.
• Realizing the technical challenge in front of Gnip was going to be much bigger than I originally thought. When you're bursting very fat pipes left and right, you know you're doing something challenging. More. More. More.
• Realizing the fragility of the Social Publisher ecosystem.
• The realization of how immature the overall commercial data marketplace is.
• Watching Publishers accept the pain they were suffering, and that they didn't want our medicine.
• Aiming our guns/product at the consumers of social data.
• Crystalizing the fact that our "white-hat" approach to the market/business was required for success.
• Realizing that Publishers need direct, transparent, relationships with the consumers of their data (regardless of how poorly utilized that relationship actually is/was).
• Returning from a family vacation to my partner, Eric, having to convey some heartbreaking news to me (which he did like man; truly exemplary moment I learned a lot from). One of the most amazing engineers I've ever worked with, without warning, approached Eric while I was away and explained how it was going to have to be "him or me." One of us would have to go. Very sad, eye opening, strengthening moment.
• Realizing that "only hire the best, most senior, industry leading engineers" actually doesn't work. Too many cooks in the kitchen becomes a real problem. Jr/Sr balance across a team is critical for various reasons. Team dynamics & appropriate team growth to name two.
• Moving to our 2nd (current) office.
• Putting computers on wheelie chairs and rolling them down the alley to ur new office.
• Setting up a real dedicated VoIP telephone system.
• Getting dedicated bonded T1s for connectivity.
• Realizing we needed to "reset" the company because the market wasn't turning out to be where we were expecting, the software we built wasn't going to work in the new world, and we needed to adjust the culture significantly.
• "resetting" - letting go nearly half of the company in a product/people shift.
• Moving back to RoR and raw Ruby to start the new architecture.
• Having the first person in my career hand me a resignation letter.
• Getting my hands all the way back on the keyboard full-time. Joyous.
• Knowing we were finding the groove (1.5 years later). Refining the mission.
• Rebuilding the team.
• Rebuilding the software. Gnip 2.0 was born.
• Seeing first glimpse of a potential, tangible, competitor.
• Eric leaving the company.
• Me taking on full responsibility as CEO.
• Looking my new partners in the eye (Chris Hogue and Rob Johnson) that night...
• me: "we'll get back together tomorrow morning after we've slept on this, and if any one of us thumbs down the situation, we dissolve the company. I can't do this without you guys."
• chris/rob: "ok"
• 12 hours later back on the porch
• me: "so?"
• chris/rob: "let's do this!"
• Rob making sure I got on the phone w/ every single customer we had at the time to re-up our commitment in the wake of Eric's leaving.
• Being approached by a firm re: acquisition.
• Killing a major deal that was underway because it would've taken us down the wrong product path (even though there was plenty of money coming along for the ride). "Hi, I'm the new guy, and we're going to back out of this deal." Fun.
• Landing the "Twitter deal."
• Gnip 2.5 was born. Long live Java.
• Dealing with unbelievable inbound demand from customers.
• Hiring our first non-engineer/engineering-manager; a sales guy.
• Hiring a finance person. 
• Approached a company about buying them.
• Acknowledging we have a competitor.
• Scaling the team in ways I'd never done before.
• Headcount 10.
• First time losing a customer.
• Approached another company about buying them.
• We no longer have a "splat date."
• Now able to see what true demand looks like, the way it looks, the way it feels, realizing that the dreamed potential is actually starting to take shape and become real.
• Realizing we needed more experience in the room.
• Hiring a COO.
• Headcount 20.
• Having large numbers of customers is a massive undertaking, and having them means your business runs very differently in ensure they have everything they need to be happy.
• Realizing we completely destroyed our 2011 revenue goals.
• Keeping the product direction focused on what our current, and prospective, customers are demanding from us, while keeping an eye on what we believe they're going to want/need next.
• Ensuring we don't chase every bright shiny object that catches our eye.
• First line of C goes into production. What's old is new again.
• Realizing we need to address bandwidth challenges by changing our hosting environment.
• Landing our 2nd major premium publisher.
• Landing our 3rd major premium pub.
• Landing more premium publishers.
• Realizing that after 3.5 years, the commercial social data ecosystem was actually gaining some steam. Real money was exchanging hands and a marketplace and industry were manifesting right before our eyes. All the players in the system (from Publishers, to middle-men, to Consumers) were participating and starting to understand their roles and value-adds. Dollar amounts were coming into view. Behavior patters were becoming clear (and expectant). Real market dynamics were kicking in.
• Realizing Gnip is growing out of its 2nd office.
• Headcount 35.
• Realizing our growth trajectory means we are going to need a bigger office.
• Realizing our bandwidth requirements put us in rarified air.

We've built an amazing product that our customers love. We've built amazing software that blows my mind everyday. We've assembled a team of humans that do uniquely amazing things as a group. Every single day. I've built friendships that will be with me forever.

I am happy, and I everyday I can't wait to get into the office to build more value for our current, and prospective customers.