Thursday, December 27, 2012

Techniqued v. defined

About a decade ago, a colleague of mine used this word to describe an odd interaction we'd just had with someone else. It has stuck with me ever since, and I've been compelled to share it a few times over the past couple of months. As with many blog posts, my motive for this one is to document the concept for future reference.

techniqued | tek'nēkt |

verb (techniqued | tek'nēkt |, techniqing | tek'nēkiNG |)

  • the process of leveraging a technique to communicate an idea, point, or concept: he was techniqued into that conclusion. she is techniqing him in an attempt to achieve the outcome she wants. 
We've all likely techniqued someone else, and we've all certainly been techniqued; neither is good. You'll notice it's nearly synonymous with "manipulated." When you're on the receiving end of this, your skin starts to crawl; it's an icky feeling. Sometimes it's not clear when it's happening (when it's done perfectly, you're none the wiser. nothing to see here.), however, if it looks like a duck, quacks like a duck... it's a duck.

If you're consciously techniqing others, you're leaving a bad taste in the mouths of those around you. Reconsider your approach as you'll get a lot further, and deeper, in life.

Life and work are too short and variable to apply heavy prescriptions to the act of communication anymore. Everyone has so many tools and so much knowledge at their fingertips, that techniqing is just too inefficient an approach to be useful at today's pace.

If you're, consciously, or unconsciously, techniqing on a regular basis, try having a more real-time, bi-directional interaction with those around you. Whatever technique you're trying to apply can't keep up in today's knowledge rich environment. Embrace the humanness of the engagement. Life is not an HBR article. There are nuggets of communication/management information in those management journals, but they're not bibles; don't treat them that way.

If you're being techniqued, you don't have to be. While it might not seem this way, you're actually the one in control. Take it. Illustrate the perspective and variables to the other party that are pertinent to the situation, and drive the conversation the direction you think it should go; ask questions. You don't have to "technique" the other party at all, simply have an open discussion, get what you need out on the table, and let the other party do the same.

There are obviously effective communication "styles" and "approaches," and separating them from the notion of "techniqing" isn't easy. Approaching a conversation "gently" or "carefully" can obviously be highly appropriate and effective. Not everyone's interface is the same: some people respond to direct/harsh interaction, while others need a softer touch. Surprise surprise, the trick is in the balance of it all. Applying heartless, methodical, gate/switch-driven, technique to a human interaction is energy intensive, and ultimately ineffective. Pure touchy/feely exchanges without substance aren't useful either. The point is that one size does not fit all when it comes to communication and engagement. Make sure you have a good balance of gut, heart, and mind when you're communicating with others. Don't be "that guy" who's living their life out of a management consulting manual.

There's a difference between applying a philosophical higher-level approach (e.g. socratic method) to communication, and leaning on tactical/discrete frameworks born out of business schools. One has the potential of bringing out the best in everyone, while the other does not.

I'm finally getting around to attending a Wisdom 2.0 event this coming year. I'm hoping it's a refreshing and progressive view into a lot of this stuff. If you're going too, drop me a line.

Tuesday, December 18, 2012

Speak the Unspoken

Gnip (social media company) grew a lot in 2012. We did a lot a of things really well (we have an experienced, proven, management team), but I personally botched a least one thing.

I let certain aspects of process and reasons for doing certain things go unspoken, after initial conveyance, for too long. Some of this was conscious and intentional ("spread your wings and fly" kinda stuff), but some of it was not. Regardless, some key stuff drifted for too long, and when you have a room full of bright, passionate, driven people, they will find their own way no matter what's going on around them. That's, nine times out of ten, exactly what you want, but unconscious drifting from a tenant is not.

Beating others over the head with process or beliefs is obviously detrimental, but regardless of how much trust and confidence you have a team your scaling and building, it is still a set of people in a room that haven't worked in the new environment together before. Regularly checking in and sync'ing on the key stuff is imperative. Without doing so, key experiences and learnings might not be leveraged well during future challenges; right when they matter the most.

Monday, December 3, 2012

Product or Services? What Kind of Company are You?

At Gnip (a social media company; where I work) we are, of course, always working to "do the right thing," when it comes to how we build software.

There is a lot of great work and discussion going on these days regarding the assurance that the software you write is significantly influenced by your customers (target, or existing). I love the energy around this topic, but as with any trend, it can be taken too far.

What Defines The Software You Build?

If you are exclusively building what your customers are asking for, then you are acting like a consulting firm or a services company; don't fool yourself into thinking that you're a product company.

If you are exclusively building what you think your customers want (without much, if any, empathy for their wants and needs), then you are squarely a product company. You may or not have any customers, but you're indeed a product company.

The art at Gnip is in striking the balance between these two things. We certainly have customers with explicit demands around exactly what kind of functionality they want. However, we don't always build software to match those specific demands. Often we do, but often we do not. We regularly prioritize other features & functionality above what they're specifically asking for. We might do this for a few reasons: one, we know internally that there is simply more important stuff to do (e.g. operational stuff that without, the products we provide will cease to function at all). This is often referred to as "keeping the wheels on." Two, it's an idea that simply isn't in Gnip's sweet spot. Three, which is effectively a summary of the prior two, our vision for our product offering is simply different than what may be suggested by a customer or prospect.

Guess what; that's ok. Our customers love the fact that we have vision and direction around where our products need to go. In fact, that's often a significant reason as to why they pay for our products. They know that their own ideas don't necessarily encompass the broader ecosystem perspective. They know that if we catered to their every whim, they wouldn't be getting any deeper evolution of the offering. They know that we're not an outsourced software development team that they have exclusive control over. They know we have our own creativity and unique perspective to apply to the challenges at hand.

What Are You?

If you're making money on product that is purely a function of your creativity and vision, you are clearly a product company. If you're making money on product that is purely a function of what your customers are asking for, you are a services company. The former is very hard when it comes to software, and is likely going away entirely as a model. The latter is something you can stumble into without even knowing it, all the while thinking you're a product company; then you wake up one day and you're not.

A hybrid is what we strive for at Gnip. I think of Gnip as a product company, yet we invest an amazing amount of time and energy into ensuring we understand our customers specific needs, and build solutions for them. We take those learnings, meld them with our product vision, and out comes software that moves the ecosystem toward a bigger picture, while meeting the immediate needs of our customers.

Combine the empathy for your customer's needs, with where you know the product needs to go, and great product will result.

recent Tweet by @sether motivated this post.

Friday, October 5, 2012

Zero Chance

"We have zero chance."

I overheard someone say this the other day. Basked in innovative and dynamic communities (Boulder & San Francisco), I hadn't heard those words uttered in a long time. In fact, I can't remember when I last heard them.

It caused me pause. It made me think about the number of "zero chances" we had at Gnip; countless. We weren't supposed to be able to raise money when we did. We weren't supposed to get the software to work the way we wanted. We weren't going to be able to find anyone to pay us for our services. We weren't going to be able to get any Publishers to participate in our ecosystem. Endless zero chances were given to us. That didn't stop us. Not a single time.

You have to be aware of odds of course. You need to know whether or not you're walking into a hostile room or a friendly room. You need to have a feel about whether or not something is likely to go your way or not. But there is never zero chance. You can play risk against any odd. How much energy you put behind a poor odds scenario vs. a high odds, is another story.

All of my life I've walked into zero chance scenarios. I've lost most of them I'm sure, but I've never hesitated. The odds of making the leap into startup land were heavily stacked against me, but it worked.

Tuesday, October 2, 2012

Too Many Software Chefs?

When we started Gnip (a social media company) nearly five years ago, it was a blank slate. I vowed to only hire the best, most experienced, software builders & artists. Sure "best" is subjective, but we'd define it ourselves and nail it. "Most experienced" proved to be a vector that added an odd twist that ultimately caused unexpected trouble. With intense focus I set out to find these people, hire them, and change the world of broken public API data access models! We had some early missteps, but we sorted things quickly and iterated on the team fast. We held true to the mission however.

After about a year, the core was in place; about a half dozen on the engineering team. You'd walk in the room and you could feel it vibrate with brilliance, intelligence, creativity, strength, and power. You were walking into the nexus of Agile development, TDD brainpower, lean execution, pragmatism, powerful iteration rates, and some of the sexiest code you'd ever see.

We couldn't be stopped. If a piece of software off the shelf started melting, the team would aim the guns at it, and write our own. Didn't like the order/pattern that bits were being written to disk given our particular access pattern... re-write the i/o driver that was interfacing w/ Berkeley DB. Concerned about the Endianess of bits over the wire; consider flipping it around. We would write our way out of any jam!

On one hand it was totally awesome. On the other, we fell apart as a team. By the book, we were doing everything right, however, even though it was relatively subdued, we had too much ego in the room. It came out in subtle ways, but everyone always wanted to drive... everything. No-one wanted to sit in the back seat and help navigate, or look out the side window and see what the weather was like outside to potentially adjust course. Implicitly everyone wanted to one-up the next person with solutions to awesome challenges. "No" was never part of our implementation vocabulary, and it should've been.

If your team is one or two people I suspect you're fine if you're both chefs. More than that however and you need balance. You need execution support. The tip of the spear is crucial, but there's a whole lot behind it that makes propel effectively. It's tempting to only hire the best and most experienced, proven, developers, but it takes a village of folks with a variety of experience levels in order to succeed. You need different, quite often _in-experienced_, perspectives in order to get the right code laid down. You also need folks that aren't 110% set in their ways. Generally people earlier in their careers are more maleable and flexible in their ways.

About two years in Gnip went through a big staffing change/pivot and changed our development team composition perspective going forward. We are now basking in the glory of variety on the team, and have a wide range of skill sets, experience levels, ego levels, to help write software that matters.

Friday, August 24, 2012

Hosting A Conference: Big Boulder 2012

If you've considered putting on a conference at your company, you might glean something from our experience. My company, Gnip (a social media company), held its first conference this summer (Big Boulder). You can also read about it on the Gnip blog. It worked. Here's why.

tag cloud of the event (#bigboulder) produced by one of our customers; Netbase

We Waited

For years we wanted to pull some sort of industry conference together. Early on we'd held technically natured meetups with some regularity. We sponsor, and speak at, a bunch of stuff. But, we'd never actually hosted something that tried to define the overall marketplace (something we tirelessly work on internally day-to-day). Until this summer, the timing just wasn't right. Our ideas weren't solidified enough. The threads that connected the various contributors in the ecosystem weren't strung through strongly enough. We waited, not until everything was perfect by any means, but until enough of the macro picture was clear that we could hang a consistent and clear message on the wall. We needed that message to be concise, and we needed the relevant players to understand it (and organically believe in it); the only way for the broader public social data ecosystem to reach its potential, is to ensure the social Publisher's motives are aligned with the commercial consumers of the activities they disseminate.

We also needed the right people to craft the message, and the event itself. Over the past year or so we'd added folks to the team who inherently understood how to do this. While I knew they'd nail it on paper (the plan, the message, the aesthetic), execution was a huge question mark (at least in my mind); no-one had taken something like this all the way across the finish line before. We were brining in (invite only) hundreds of participants; from speakers to attendees. Logistics weren't going to be easy. We didn't vend anything out (except venue, food, and a/v). We pulled it all together ourselves. I'm still in awe at how smoothly everything went. A testament to everyone's passion, skill, and commitment to what we're doing here at Gnip!

We planned

The conference was done "panel style." Moderators engaged in Q & A conversations with the panelists/speakers. Getting the list of speakers right was a challenge. A few people we wanted to talk couldn't/wouldn't (you'll never know which it was in some cases) talk. That sucked, but we managed it by having a broad set of folks we wanted the audience to hear from, and accepted that churn was just part of it.

The sessions themselves were planned weeks, and in some cases months, in advance by vetting topics with the speakers and getting the right conversation sketched before we sat down live in front of everyone. I didn't get the value of this at the time, but it is clear to me now that it was a huge contributor to the conference working. We had two full days of material to cover. If it wasn't coordinated effectively, we'd have a disjoint mess on our hands.

We Kept It Simple

No presentations! There were one or two exceptions, but as a rule, we didn't put slides up. This helped ensure the audience didn't suffer slide fatigue and just drift off into the conference oblivion we all know and hate. It kept everyone engaged; everyone.

We Mixed It Up

We brought in an MC that wasn't directly related to our space. Some of the topics can be intricate and heavily policy related. Lindsay Campbell brought a fun, light, comedic, yet professional, educated, and authoritative air to the room. She's awesome and can crush an enterprise event as well as she can a more consumer oriented production.

We sprinkled in various activities. Yoga, hiking, and biking to keep things active. I thought these would be too corny, but participation levels were high and people really enjoyed everyone one of the activities we planned.

We did the event in Boulder, CO. This geographically challenged location from a travel logistics standpoint actually helped, instead of hurt us. Boulder has a great locale reputation, and many of the audience members hadn't been here before. The event was geographically unique as opposed to the same old venues many folks are accustomed to visiting.

We're in the throws of deciding whether or not to do the event again.

Tuesday, August 7, 2012

"Startup Communities" by Brad Feld

A "publisher's draft" of Brad's latest book (release date in coming weeks) called "Startup Communities" appeared on my desk the other day. I just finished reading it.

What an awesome book! Brad put to words what I've been grasping to codify in my mind for a decade or so now. Specifically, what makes Boulder (and as the name implies, other communities outside Boulder) what it is from a startup/tech standpoint!?! Part of the challenge was time; time needed to pass in order to come up with much of the framework (scenarios needed to play out, relationships needed to evolve, etc). The bigger challenge, however, in putting structure around something unwieldy is being able to see all the angles, define them, construct a vocabulary, establish thesis, and connect the dots. He did it.

I've been blogging about Boulder and software for years, but have never been able to get my headspace into a cohesive network of thought around what we've done as a community here. Starting with a clear illustration of "leaders" and "feeders" (words I'd first heard him use at my company's (Gnip - a social media company) recent Big Boulder conference) he outlines constructs necessary to have a successful, flourishing, Startup Community. Turns out you need both in order to succeed, and being a "feeder" isn't a bad thing.

The broader conversation around what makes for a great startup community has been going on for a long time now. We've all been trying to put our fingers on the key components, and "Startup Communities" does an awesome job outlining them. When you cross check the frameworks and concepts against the realities of Boulder, Boston, the Bay Area (and others), they stick. I'm a believer in that entrepreneurship is indeed what's going to get the world through the disaster it's currently in from a political/economic standpoint. If you subscribe to even a fraction of that notion, the book's a good read to understand what components a community needs in order to move us all forward.

Stuff I loved in/about the book:
  • "Give before you get."
  • Tribute (though slight) to Naropa University, which has been a significant part of Boulder's identity and fabric for a very long time. It also embodies many of the openness related qualities Brad sets up in the book. I don't think this particular thread is considered enough when we try to tease apart what makes Boulder, Boulder.
  • A startup community has got nothing sans entrepreneurs. This is the broadest arc outlined in the book; it all starts and ends here.
  • Patriarchy won't work. The picture's bigger than that.
  • Trouble ensues when "feeders" try to lead. In my experience this is what trips up communities trying to "start up" most often. Someone in a "feeder" role declares "we're going to be an awesome startup community dammit!" That just doesn't work. You need the entrepreneurs.
  • Deep exploration of the role Universities play in a startup community. This is hard to get your head around considering the blend of "government" (funding) and entrepreneurial spirit that embody Universities. They're confusing actors.
  • "Bottom up, not top-down."
  • "Network over hierarchy."
  • Authenticity. The guy practices what he preaches.
  • "It's my belief that Boulder is unique because the entrepreneurs and other participants in Boulder's startup ecosystem have a greater sense of community than anywhere else in the country." - Mark Salon
  • "Go for a walk." Walking/bike riding meetings are just better. I'll never forget a walking meeting we had a few months ago when we found ourselves way the hell out in East Boulder before realizing we needed to get back to our offices. Just fun.
  • "Do or do not. There is no try." - Yoda's proverbial perspective.

Tuesday, July 24, 2012

Daily Camera Building Re-development

If you are responsible for leasing/buying commercial office space for your Boulder-based company, read on. My company, Gnip (a social media company), recently signed a new lease downtown, so the process is still fresh in my mind.

This coming Thursday, July 26th, evening, the Boulder Planning Board is going to hold a public hearing around the latest proposal submitted by the firm hoping to redevelop the "Daily Camera Building."

If you've ever signed a ~7,500+ sqft lease in downtown Boulder, you know how many options you have, and how much leverage you have in the process; near zero. There are a handful of issues with being a "buyer" in Boulder's commercial real-estate market today. One of the major challenges is supply. There is simply very little contiguous, expansive, "class A," office space physically in existence downtown (not to mention it's all basically occupied). The current proposal for the redevelopment of the Daily Camera building would yield ~156k sqft of _new_ class A commercial office space inventory. That is a non-trivial amount that would come online in the coming years. Right when you're needing more office space (if you're not already desperate for it)!

I'd encourage you to go express your commercial needs (current or projected) and experiences leasing large swaths downtown, to the Planning Board so they thoroughly understand the demand-side of this equation.

Boulder has significant building growth restrictions, and this opportunity will not come around again to affect the downtown commercial space landscape to this degree.

Sunday, July 1, 2012

My 3 Steps To Software

I had three distinct moments that committed me to a life of being up close and personal with software. April and I were just lying in bed talking about when we first met, and how she "had no idea what I was going to be when I grew up." I thought, "neither did I," then walked down here to write this post.

Apple IIc Plus: ~1988

My first program was written in BASIC on an Apple IIe in Jr. High School, but it was the Apple IIc Plus that my dad brought home sometime around 1988 that resonated with me. There was some gaming/animation software I'd load up and create 8-bit blocked objects that would dance around the screen. I didn't go nuts with it, but I did rack my brain with it for awhile.

Civilization: 1991

For the first time in my life I stayed up for more than 24 hours straight doing something; playing this game! Addiction at its finest. Still the best game of all time. I watched the computer take in countless variables and play against me in a way nothing ever had before. It felt like true Artificial Intelligence. It was around this time that I started a PC wholesale business. I'd source all the parts (body, motherboards, CPUs, memory, video cards, hard-drives, floppy drives, modems eventually), and build PCs-to-order for people around town. Of course, this gave me steeply discounted access to the fastest processors around which made playing games like Civ that much more fun.

Art Center College of Design, Vevey, Switzerland: ~1992

I somehow engaged with art and design. I started drawing/designing automobiles. My parents liked this track and sent me off to Switzerland to try and get in to one of the world's more prestigious design schools. It was a flyer to be sure. I had zero formal training, and a sliver of talent at best. Upon returning home, April and I were lying in bed one evening in our apartment, talking about what we wanted to do with our lives. It was then and there that I was hit by one of few tons-of-bricks in my life. I vividly remember saying "when I'm drawing, all I can do is think about the computer. I just want to put the pens down and go work on the computer." And that was it. Before even hearing back from the Art Center, I enrolled elsewhere and started coding like I meant it.

There was actually one final moment that completely sealed the deal. It was probably around 1994. One of my CS professors had given us an assignment to write a simulation (CPP) of the Denver International Airport baggage control/delivery system, coincident with travelers de-planing. DEN had received national attention for how poor the baggage handling system worked. My professor wanted to see if we could do better. I spent days writing the simulation; lots of dead ends. The final deadline was looming. Midnight rolled around, then 1am, then 2am... I vividly remember *knowing* this last pass at a few routines was going to make it work. I hit "run," to fire off the final test of the simulation. I walked out my apartment door and started walking West down Alpine St in Boulder. The sun was rising as I walked, and the mountains picked up that beautiful pink/purple hue from the sunrise. I was exhausted. I'd been up for at least 36 hours. I was loving every minute of it. A huge smile appeared on my face. I was in heaven.

I gave the simulation the 60 minutes or so that it needed to run. Walked back into the apartment (best apt. I ever had by-the-way), straight over to the screen, and there was the successful output I'd been waiting for. I printed out the code and went to bed. A week later I received the code back; "C-." C-minus!?!?!?!? Bullshit; it worked didn't it!

I was hooked.

Friday, June 29, 2012

On Hiring A COO

By external measures, Gnip ("the social media API") is a 4.5 yr old raging success. I'm a technical co-founder in the company. I'm a first-time CEO, and have been for two years now. A year ago I hired a COO (Chris Moody).


This is a tough post to write because there is so much ego involved. For months I've been trying to create it in my mind, but have failed until now. My breakthrough came from going back to my roots and putting my ego in check; something I'm traditionally good at, but struggled with in this context. I got close enough that I was able to get the words out!

Among my top five reasons for loving Boulder, CO lies in the deep spiritual community here, generally connecting back to Buddhism. It's something I've tapped my entire life, and whenever I'm challenged, it supports me and gets me through ego stuff. Don't confuse that statement with having anything to do with Religion (separate in my book).

Ego's a funny thing of course, and it's the dichotomy between its strong presence in business (something I strive to "succeed" at), and the Id (something I strive to lead with in life) in humanity that is the most fascinating challenge to me. Hiring someone because you need to scale time is one thing. Hiring someone because you need to scale capability is another. The latter requires that you acknowledge the potential, or real, lack of something in you.

Why Hire a COO?

In short, to go faster!

In Q4 2010 we realized Gnip was going to hit it. Through careful team building and execution (and luck of course) we had a team and tech stack that would scale through the upcoming demand wave we had just caught. A few months into that scaling, one of our board members (Brad Feld) pulled me aside and said "good job, but you have to think bigger. you have to take what you've done, and go further."

That was an interesting moment. I got to a crystal clear realization that building a product and company is truly a never ending process.


This notion has distilled into an on-going joke Brad and I now share.

wrapping up a phone call awhile ago…
Jud: "blah blah blah. good to sync. catch you later."
Brad: "good to sync. go sell more."
Jud: "as a VC, you must love being able to end every call with 'go sell more'.
Brad: "Hah. Yes. go sell more"

Now he ends every call we have with "go sell more."

I started thinking about what the organization would need to look like in order to take Gnip to the "next level." What would the team qualities/skills need to be in order to do that? If we were going to "hit the gas," what roles did we need in order to ensure we'd come out intact on the other side of the next phase, and not splattered against a highway wall?

We were going to need more specialization. We'd kept the wheels on using a generalist approach. We were going to need more refined expertise that had proven experience in specific functional areas of the business. We needed specialists who could own those functional areas of the business: engineering, sales, marketing, finance.

Product & Engineering were squarely in my wheelhouse. While it took a good six months to find someone to run development, I knew what qualities we needed/wanted. We ultimately landed someone that had it all; thankfully.

Business functions were more challenging. I invested another six months talking to folks from all over the map. From folks I'd personally worked with over my career, to recommendations from friends and investors. Big company candidates. Small company candidates. Every background you could imagine.

We needed someone who could help us "lean in" to the next phase of scaling the business. We needed someone who would be a solid cultural fit. Someone who had scaled sales teams up, and who had experience in marketing enterprise SaaS business.

I needed someone who wasn't afraid to travel (a lot). I needed someone who could represent Gnip's interests externally, as well as someone that could effectively negotiate sales compensation plans with our team members. I needed someone who could go deep on operational nuts and bolts. I realized that if you're going to have a crew bigger than 25'ish people, more specialized experience in the room is necessary to scale up. Simple laws of distributing creativity, load, and stress kick in eventually. Can one person run a 100 person company? Sure. Can one person run a 100 person company that needs to forever attack new market segments and business lines that result in new products being built? I don't think so. You need leaders with specialized expertise in order to distribute the load.

I needed someone that was stronger than me in my relative areas of weakness. A chain is only as strong as its weakest link. Gnip would still be an awesome success if we hadn't started scaling up the team, but it would have moved into its adolescence with nutritional deficiencies that likely would have impeded further growth. When you're trying to build a product your customers want, if you ever hear the term "impediment" all of your guns should start blazing in an attack to eliminate it; wherever it is. In this instance, that meant ensuring there was more breadth in experience and leadership on the team.

I grew up doing everything myself; everything. The notion that the company I was building might do better with an additional brain the mix, took some getting used to. I preach the "always hire people who are smarter than you" gospel all the time. It's important to internalize what you preach and practice it yourself. That understanding calmed my ego to the point of being able to hire the role with clarity and commitment to making sure it worked.


Chris Moody fit the bill. He is able to quickly go deep in areas I cannot. Sure there's some generalism still in the mix with a COO. I could have hired a CRO and a CMO and a C-blah-O to go even more narrow, but that would have been too narrow, too fast. There was an in-between step for Gnip; COO.

Chris was "the right guy" because...
  • he fit the team culturally. there was no oil-and-water effect
  • we spent months together talking about every aspect of the company and direction, and we saw eye to eye on almost everything
  • he had tangible success/experience in his background that we could talk about and connect directly to things we wanted Gnip to have
  • he was consistent in his thinking
  • I believed he could help us scale the team and business
  • we negotiated through some tough points during the dating process, and that illustrated our ability to work through disagreement in a productive manner

Process and Support

I leveraged my network heavily during the process and had candidates talk to Gnip team members, board members and investors. During this process I met a lot of talented, experienced, who generally would have been powerful contributors for Gnip. The consummate professionals that they are, fully understood the process around hiring a position like this, and the fragility of getting the fit right. If you were one of them, thanks again for your time.

Once I'd narrowed it down to Chris, I had him sit down with another team leader. The conversation didn't go well. Both guys came back to me with concerns. After a few days of talking each of them through the concerns, both took my word that the concerns wouldn't be realized in the end. Chris was concerned that there was resistance in this person, and some head-strong characteristics that could get in the way of winning. Gnipper was concerned about the jarring impact bringing someone into the firm in this capacity would have. While both were right, I was able to illustrate to each how we would all win in the end. Onboarding wouldn't come for free of course, but we'd be better off down the road. And sure, Gnipper can be headstrong, but once you get to know him...

I feel awful for friends running other companies who had additional leadership "installed" by investors. The stories they tell are excruciating to hear. Those stories point to a lot of the issues with venture capital at large, and conversely highlights just how good Gnip has it. It has also scarred my view of some VCs I once held in high regard; I no longer would be willing to take them on as investors.

One of the most important people in the process was Brad. He made it clear the entire decision was mine. From whether or not we should hire more leadership in, to who it actually was. He didn't have a horse in the race, and that was critical for me. Pressure on those fronts would have yielded disjoint motivation, and this wouldn't have worked.

One Year Later

It's been twelve months since we brought Chris on board. One of the reasons I haven't posted this earlier is that I wanted some time to pass. Talking about how great a decision was a few months after you made it is kind of pointless; there's still plenty of time for things to go sideways if you judge too early.

Chris Moody has been pouring his heart into Gnip for a year now. Every day he wakes up and fights for Gnip. He is part of the team. Bringing on a COO was a huge Gnip milestone that has resulted in very meaningful business execution! When I use the true measure of a hire, whether or not you learn something everyday from an individual, Chris has been a huge win.

There are entire vectors in Gnip that Chris takes on. I'm always reminded of this when I see him deep in conversation with others on the team. I think to myself a) that's a conversation I would otherwise be having (if I were able to find the time) and b) I'm sure he's doing a better job at it than I would. It's not that I don't want to be having said conversation, it's that I need to be spending my energy elsewhere in those moments.

Gnip has made incredible strides in partnerships over the past six months. Chris has been flying all over the place and investing heavy amounts of time and energy in getting these relationships in place. While he's investing the time which is a huge win, he's also getting the job done which is what really matters.

While I'm still in the process of freeing up my headspace and fully understanding what it means to have a high-caliber COO on the team, one thing I know is that I now have the ability to focus more strategically on our direction at large. It's possible now to rise above the fog of war and view the hiring and money from a strategic vantage point. That's very hard to do when every mechanical component around running a business is your sole responsibility.

Saturday, June 23, 2012

Overwhelmed With Joy

WARNING, this post runs into high corny factor in a hurry. I'm also going pretty stream-of-consciousness-style because I'm too tired to polish and think clearly.

some of the exalted Gnip team
24 hours ago Gnip's (the social media API) Big Boulder conference wrapped up in Boulder, CO. It was one of the most amazing experiences of my life. A culmination of happiness, joy, pain, love, passion, sweat, tears, stress, belief, sacrifice, and faith.

At the end of the day before the event began, I got home around midnight. Flopped onto the bed and talked with my wife about what was about to happen. About six years ago I flung myself into the Boulder tech community, and now it was the eve of Big Boulder. Of course I understood the significance of the event itself, but it had turned into something else for me. I still can't crisply describe it, and I'm sure I'm still delirious from exhaustion, lack of sleep, and adrenalin, but I wanted to get some of this out of me. We told ourselves we wouldn't draw any conclusions (positive or negative) about the event for two weeks following, because we didn't want our exhausted state of mind to contort truths, but I realized I wanted to document some of these feelings now for memory's sake.

I'm in awe with what team Gnip has become, and accomplished. For those wondering "how we did it" (both the conference itself, and the transition from "startup" to a real business), the answer is simply, amazing people. I can unequivocally say that the team is it. It all starts there. Without the right set of people aligning with common beliefs, you have nothing. I'm eternally grateful for what everyone poured into this event, and into the company. Money, equity, and "thank yous" can't express the gratitude I want to express enough. All I can do is hope that each one of us understands these importance and value of these moments in time. Not only the personification of them in events like Big Boulder, but also in "company" form. We effectively live with eachother week-in and week-out.

Continuing on that people theme, the quality of everyone at the event struck my core. Hundreds of fun, smart, great, passionate people (friends, customers, prospects, partners, family). I was quickly overwhelmed by the greatness of humanity. We're all struggling to build amazing things, and solve amazing challenges, and we all have awesome lives and experiences. The sharing that went on (business and personal) was just incredible.

The ecosystem Gnip saw 4.5 years ago is thriving. I still can't believe we're here. Hundreds of millions of dollars exchanging hands (excluding "ad revenue") under the umbrella of social data. The flagpole Eric Marcoullier and I planted several years ago is paying off. I sometimes just can't believe it.

Publishers and public social data consumers in the same room exchanging ideas. Four years ago this notion was nothing more than a pipe-dream. 24 hours ago, it was reality! I'll never forget Eric paying $6k (against every fiber in his body) for some Forrester Report that described some area/space/vertical/category (I don't even recall what it was) ad-nauseam. He then bought a printer to print it out. He studied it for days... trying to piece together components in the ecosystem we had growing in our heads. How could we translate this into a business? Who would pay? What would they pay? The report gave us some scope/scale insight. We shelved it pretty quickly, but it was enough for us to look at each other and say "yup, there's money in that hole somewhere... let's figure out how to pull it out." Big Boulder was the progression of this ecosystem, and the progression of the Gnip team has carried the torch to where the ecosystem is today. We're still so early, but not only is there life on this planet... it's intelligent and expanding at an incredible rate. The continued scaling of Gnip charts the overall ecosystem course going forward. Being a part of this is overwhelmingly wonderful to me.

People flew to this event from all over the world. Can you believe that!?!

At the end of the event about 30 people joined a bike-pub-crawl. I rode next to Stu with Textifer. If you don't know him, he is one of those people that sees the bright-side in everything. He is happy. He understands life. The several blocks we rode together put everything in perspective for me. When we got to the second bike-stop, he ran over to the pop-water-jets on Pearl St. and splashed water all over his head. I _love_ that stuff. I _love_ it when life permeates us like this. I love people who break out of the molds. It's simple stuff like this that makes it all worthwhile. Thanks Stu!

Passion around software always blows my mind. Michael Wilde with Splunk personifies this. I _love_ how he _lives_ software. Parts off of so many shelves comprise his world. If you know him, he also _lives_ life. He was late to the start of day two, and I saw him first that day when he blew into the "speaker's room" dripping with sweat; "we did it!" He yelled. Sleepy and focused on going on stage in just a few minutes, I couldn't figure out what he was talking about. "We made it all the way to the top!" He was talking about the hike we'd organized that morning. He and @zhu had summited the 1st Flatiron! So cool!

The homefront was like a support station during a bike race. Briefly visited during the past week, but required for sustenance (family love, food, sleep). My wife... my life... thank you.

This past week has been affirmation that I've spent the past six years of my life wisely; I can't wait for the next! All we've done up until this point is establish a foundation. Now comes the real work!

Thursday, June 14, 2012

My Life In Scrabble Letters

Something hit me hard yesterday when I was playing Words With Friends with my son. I'm always grappling with how to approach life/business. When am I pessimistic? When do I approach something with passion and vigor? When do I shy away from something? When do I lock onto something and go nuts with it? etc.

It was my turn to build a word. There were a few words on the board already. A new letter lineup was in front of me. I glanced at the letters and subconsciously distilled vowel and consonant ratios between my new jumbled letters and the board. I got a shot of adrenalin. I was psyched because the ratio felt right and I was excited to dive in and built a word. I didn't have word yet at this point. I just felt like the raw material was there to do something great (as opposed to a rack of all consonants which can illicit fear).

As I peeled the onion, I was coming up short. The raw material was good, but I couldn't turn it into a powerful word. What the heck was I so excited about at first blush? This was sucking! Time passed. Discouragement came over me. A few more shuffles of the original letters, and I found a great word and played it. It turned out great in the end, after some twists and turns.

The parallel of that little experience to how I approach challenges in life was fascinating and vivid.

When you've got solid raw material to work with, you'll get solid results. When the raw material is too easy/obvious, you won't get much out because not much had to be put in. When you get a set of "impossible" letters, work hard, and construct some gnarly high-point word, it feels great.

Anyway, random post, but the level of excitement I felt after a glance at a new rack of letters was intriguing. Opportunity was in front of me, and I had another shot at taking raw material and turning it into goodness. Fun.

Saturday, June 2, 2012

Parenting & Technology: An Update

I haven't been posting about raising kids in this technically dense world as much as I'd like. Here are some quick thoughts...

Stuff in the house

  • We're a heavy Apple house.
  • A few mac laptops.
  • A central/common-area big screen iMac in the "computer room."
  • Mom/Dad iPhones
  • Kid's iTouches
  • Sonos
  • AppleTV
  • Tivo
  • Wii (barely used anymore)
  • XBox
  • BlueRay player (almost never used unless true 58Mbit throughput uncompressed 1080p resolution is desired (e.g. remastered Star Wars))
  • One "big TV" in the family room (no other TVs in the house).
  • Comcast HD Cable
  • Comcast Cable network connectivity (as fast as they offer for residential; 50'ish Mbs/sec up/down IIRC)
  • A few Amazon Kindle's (the kids have their own, and I have one)
  • A few iPads
  • Some cameras
  • a bunch of other stuff I'm missing

Tearing Apart Technology

When I was a kid my dad would let me tear apart old music players and telephones. It was a total blast. That's a lot harder to do today because everything's soldered to circuit boards and there are no moving parts anymore. It's less interesting for the kids, because the physicality of the process is vastly different. Electronics are just smaller now, and everything's solid-state. Yes, you can get into a conversation about silicon, circuits, resistors, and capacitors, it's just not as fun.

Network Availability

I have mixed feelings on this one. By now I'd expected the network to be persistent, and everywhere. Neither are true (not in the slightest), and my 9 yr. old son is keenly aware that connectivity must be sought and established if he's away from home-base. A positive outcome from this is that he understands "connectivity." I was worried it would be so ubiquitous that the kids would never actually understand that there even was a network.


The big one. I'm very strict with unique accounts for family members; everyone has their own accounts/logins, and I don't like it when I see them shared. We're pretty good on this front. There are so many things tied into "your account" today it's simply too much to manage. My diligence takes an inordinate amount of energy.

  • Installed Apps are bound to accounts. If you mix accounts, then your iPhone (for example) becomes littered with kid's game apps, or kid's education apps. Conversely, your kid's iTouch becomes littered with your apps, and before you know it, they're, unknowingly, racking up your iTunes bill by messing with your apps.
  • Music is bound to account. Similarly with Apps, if you mix/share accounts, your music (explicit lyrics in my case, not to mention songs my kids don't want to listen to) winds up in their player, and vise versa. You don't want Justin Beiber showing up on your iPhone do you!?!
  • Movies are bound to account.
  • TV shows are bound to account.
  • Parental Controls are bound to account.


This is a big one. If you just share iTunes/Amazon accounts, your child has no concept of money. Their only understanding is that when they want something, they run over to you so you can type in your password to "get it." If you share accounts, it hits your bank account, and they learn nothing. We setup bank accounts for our kids awhile ago, replete with debit cards (which they don't use yet, but we use the account numbers from), which we wire into their cloud/operating system accounts. This way, they can see their own account balances, and associate credits/debits with earning and spending. They are exposed to the boundaries of spending.


This one I did a 180 on. Pre-heavy technology use I told myself "I'd educate my kids about stuff as they came across it, and everything will be fine." Today, we have Parental Controls enabled on the kids' stuff/accounts, and passwords on communal devices (like AppleTV, Tivo, XBox) to prevent willy nilly content acquisition. The reality is that within a few clicks, young minds can be exposed to things that, even with your explanation, cannot be understood at a young age (it's not the relatively innocent stumble upon of a Playboy magazine like it was for me 30 years ago, anymore). So, you either allow a developmentally incapable mind to be exposed to some stuff at the wrong time (and suffer whatever consequences come out of that), or you lock down.

I've been impressed at the options in "locking down." They're better than I expected; not great, but pretty good. Of course, soon enough, the kids will be able to get past everything (or just go over to a friend's house where things are wide open), but at that point they'll be more prepared and able to understand some of the content they're exposed to (with explanation and discussion) anyway, so, life will go on.

We block network access to the mac addresses of our kid's devices between the hours of 8pm and 8am everyday; just in case :).

My daughter just woke up. Gotta go!

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.

Thursday, April 26, 2012

"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.

Tuesday, April 17, 2012

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.

Monday, April 9, 2012

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.

Thursday, April 5, 2012

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.


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.

Saturday, March 3, 2012

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.

Thursday, March 1, 2012

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.

Saturday, February 18, 2012

The Commercial Data Ecosystem's Publisher Phases

For the purposes of this post "Social Networks" translates to "Publishers." My company, Gnip, brings the public, real-time, activities created by users on Social Networks to our customers. From a vocabulary standpoint, we simplify things and refer to these Social Networks as Publishers.

Over the past four years Gnip has seen a lot of Publishers come and go. Not surprisingly, a pattern has emerged around how they evolve, and the degree to which our customers need their data. There are generally three distinct phases a Publisher goes through, and how they do in each phase impacts how they ultimately participate in the broader social data ecosystem.

Participation in the social data ecosystem can yield a full commercial cycle for the Publisher. This cycle being one combining consumer use (expressing buying intent, or ranting about a product) with commercial engagement (ad buying or addressing a problem with your product).

Phase 1: Consumer Engagement
A Publisher must engage consumers. Whether via a homegrown social graph, or leveraging someone elses (e.g. Facebook Connect), in order for a Social Network to become useful, it needs users. From there, those users need to participate in self-expression (from posting a comment, to re-tweeting a tweet) and generate activity (aka "Publish") on the service. There are a variety of ways to compel users to engage in a social service, but the Publisher itself is responsible for the first experience. The vision of the services' founders yields a web-app or mobile interface that allows us to take action, leveraging the expressions laid out by the app itself (e.g. sharing a photo). If users like the expressions, discovery methods, and sense of "connectedness," you've got a relevant Publisher on your hands.

Phase 2: APIs; Outsourcing Engagement
At some point a successful Publisher realizes the potential for outsourcing the expression metaphors that make the service successful & useful, and they construct an API that allows others to RESTfully engage with the service. In some instances the API is read-only. In some instances the API is write-only; sometimes it's both. What is key is that nine times out of ten, the API is meant to drive core service engagement via other user-facing applications. A classic example of this would the zillions of non-Twitter Inc clients that "tweet" on our behalves everyday. One look at the endless number of tweet "sources" that flow through the Firehose and you'll realize this engagement potential; there are tens of thousands of client apps.

The exceptional API is one that has broader social data engagement ecosystem consumption in its DNA. Typical Publishers consider themselves the center of the universe, and that not only will they capture all consumer engagement, they will be the root of all broader ecosystem engagement as well. However, success with consumer engagement does not guarantee commercial engagement; not by a long-shot. This center-of-the-Universe perspective is highly limiting for everyone involved. A great example of this is simply how you see Facebook and Twitter logos in cafes. The retail outlet couldn't care less about which Publisher du jour is hip. All they care about is reach, and they'll promote any social service they think yields reach; they have zero affinity to your social service.

Some services execute phase 1 and 2 simultaneously these days.

Phase 3: Activity Transparency; Commercial Engagement
Allowing other applications & developers to inject activities into the core service is obviously valuable, however it is only part of the picture. Publishers with broad social and commercial impact have achieved this success by addressing commercial needs for complete, raw, activity availability. For example, in order for someone to effectively deploy resources in a disaster relief scenario, they need to make their own determination as to what victims need, where they are located, and general conditions surrounding the event. The Publisher limiting access to the public activities taking place on the service, by definition, yields an incomplete picture to downstream commercial consumers of the content. The result is a fragmented & hobbled experience for commerce engagement.

The most impactful, useful, and valuable Publishers that Gnip customers leverage for their needs (ad buying, campaign running, stock trading, dissaster releif), are those that acknowledge that they are not an island in the ecosystem. They complete the cycle by providing unfettered access to one of their most significant assets; the public real-time firehose of all the activity taking place on their service. In trade, the relevance of the Publisher itself is maximized because commerce can engage with it. Whether the ecosystem has to pay for that access is a separate topic. The availability of it at all is the finer point.

A good example of how impactful this transparency can be is Twitter. Consider how Twitter is used across new, as well as traditional, media. They've completed the commercial data ecosystem cycle with a strong offering in Phase 3.

All three phases are not required for success, but all three are indeed required for success in the broader social data ecosystem.

Monday, February 13, 2012

David & Goliath; Internet Tech Sector & U.S. Government

By way of the Silicon Flatirons "The Digital Broadband Migration: The Challenges of Internet Law and Governance" conference last night, I somehow found myself at a reception with a few dozen brains much bigger than mine; thank you Dean Phil Weiser and Brad Bernthal. 1/3 were politicians by trade (even if their primary source of income was commercial/private), and 2/3s were software or broadband infrastructure industry CEOs/leaders. For a more specific sample of who was in the room: Colorado Senator Mark Udall, Edward Felton (CTO, FTC)Daniel Weitzner (deputy CTO for Internet policy), Dave Wright (CEO, SolidFire), Founder CableLabs, an executive from Dish Network, an executive from Comcast, Robert Reich (CEO, OpenSpace)Jim Franklin (CEO, SendGrid), Jason Mendelson (Partner at Foundry Group), Brad Feld (Partner at Foundry Group).

In listening to the conversation during the reception, and prior at the conference, a consistent theme emerged; "voice." Senator Udall (paraphrasing): "make sure your internet tech sector's voice is heard. there are important policies in play. your voice was only heard late in the game on SOPA/PIPA." Phil Weiser (paraphrasing): "traditional industry is used to having frameworks such as trade associations to help them voice their perspective to Congress."

The room was filled with incredibly smart people, yet we were not being heard on incredibly important topics. I'm grateful for Senator Udall having invested several hours into the event; he was fully engaged. I'm speaking more generally about Congress at large. SOPA/PIPA were an eye opener for me. How could such potentially impactful, and broken, legislation have made it down the pike in the first place? That's the question I'm stuck pondering. Unfortunately, I don't like my answer.

At least one of the reasons our voice is indeed not being heard is because we're not speaking the same language that the system has grown up speaking. Phil Weiser was on-point eluding to trade associations' communicative impact on Government. The "internet tech sector" (for lack of a better name) does not lobby the same way more traditional industries do. The result is that our voice does not get heard. Sure some of our peers lobby for their specific interests, but a) they look less and less like the entrepreneurial startup ecosystem everyday (Google, Microsoft, Oracle) and don't represent our interests but 50% of the time anymore, and b) they still spend a pittance relative to the amounts other lobby categories are paid in order to craft/pass legislation. It's a horribly cynical outlook I know, but even Senator Udall implied the success of its Congressional impact during the reception.

SOPA/PIPA illustrated that our collective Internet tech sector approach thus far is going to get us in serious trouble. The Government is going to start passing legislation that has dramatic impact on how we conduct business. They've stayed out of our hair on the direct bill passage front thus far, but that's changing. If we don't get our "voice heard," we'll fall to the giant stalwarts that have dominated Congressional influence to-date.

Because we're a distributed bunch by nature (lots of entrepreneurs, lots of software startups), collective communication is hard. It's even harder when we shove our heads in the sand saying "I'm busy. I've got work to do, and it's hard, and it takes my creative energy. I don't have time to voice my concerns to those perpetuating an archaic system that doesn't apply to me." Well, while true at the moment, the system's applicability to all of us in this space is about to get very personal and direct. If something's not done now, we'll fall later.

What Can Be Done?
We can lobby. We've resisted this thus far, but perhaps it is time for small to mid-sized software "internet tech industry" firms to collectively pony up dues to a more centralized lobby effort and/or trade association that represents our interests. Money talks folks. Always has, always will, and thus far we haven't spent a relative dime trying to have our voice heard.

We can act. PIPA/SOPA was exemplary on this front. However, it was exhausting, inefficient, and it doesn't scale. We can't protest after-the-fact every time bad legislation makes its way through the system.

We can change. While I believe lobbying is the practical/tactical solution, it is broken and wrong in and of itself. The United States is a very different place today. The founding frameworks that have steered elections, law, and legislation to-date simply do not work for such a technologically advanced society. The disconnect between Congress and the people creating jobs and industries today is vast. We can, and need to, change that. Brad Feld made a resonating statement last night at the table, "the compromise approach is inherently flawed. stakeholders need to be problem solving, not compromising." That's a foundational statement that I'd like to see a new system built around. At the same time, it feels revolutionary and that feels hard. It's time for change; execution's always the catch.