Category: Entrepreneurship
Last week, in the midst of Denver Startup Week, we had a full day Foundry Group Exec conference. Ben Deda from FullContact convened about 100 execs from our 60 or so portfolio companies for the day. We had seven topics of one hour each, led by a different set of execs. The result was an incredible range of discussions across an amazing group of people.
One of the attendees was Jeff Malek, the CTO of BigDoor. Jeff is super passionate about what he does and mixes humor with intensity with math. Following is something from Jeff to kick you in the ass this morning and get you charged up.
Last year I put together a slide deck for what the FAAAC was all about. Amongst other things, it describes a start-upper’s most valuable core attributes: fire, ability, agility, adaptability, and clear, concise communication skills.
A couple of months later FAKEGRIMLOCK published his incendiary work BE ON FIRE. As I read this wonderful post, I got very positively charged up. I thought : what the FAAAC is up there, with FAKEGRIMLOCK? Yes, it seemed to me: it is totally up there with FAKEGRIMLOCK!
AWESOME.
Was I somehow channeling the King of Awesome? Could I be some sort of supernatural vessel, carrying the same caliber of limbic wisdom as the great, giant robot dinosaur? After asking around, the consensus was “probably not”. Someone even mentioned that I might be confusing “vessel” with “vassal”.
Still, I felt compelled to reach out to Brad and pointed out this cosmic parallel. Brad asked if I’d like to write a guest post. I thought, “hmmm…lucky FAAAC opportunity…” and began a mental draft immediately, in tandem with other P0 efforts I had in the works at the time (e.g. sharding our database systems).
One year and fourteen pounds of irony later, I’ve completed my assertion of reasonable ridiculosity for the FAAAC.
Behold, the Fire in the FAAAC Proportionality Theorem:
Which can be read per line thusly:
- There’s a unit of awesomeness comprising fire, ability, agility, adaptability, and good communication
- A good start-upper exhibits unusually high, varying degrees of each trait.
- An impressive academic pedigree doesn’t predict startup awesomeness (although it’s always impressive)
- Fire is the most important aspect of them all, composing up to 80% of all the awesome. Fire can drive learning (ability), help you duck punches (agility), and get you off the ground when you’re hit (adaptability). This is all just paraphrasing what Edison said about perspiration, and what FAKEGRIMLOCK drew about bears, bombs and arrows.
- If fire is compensating for lower levels of the other traits, then to be a great start-upper you’ll need a proportionally large sense of humor to get you through acerbic code reviews, failed biz-dev deals, and communication breakdowns.
- That’s what the FAAAC fire has to do with anything and everything.
It may seem like I’m just pointing at the clear connecting lines between myself, Brad , Edison, and FAKEGRIMLOCK. Fishing lines, maybe even.
But seriously, we have a rigorous process at our startup that tests new job candidates for these traits, making it easy to determine whether they should be leveled-up to the next interview stage. It involves running through our sprint process on a compressed timeline, working with a hypothetical customer, in a typical solution space. After 30 minutes a ruleset is produced in English, and supporting code is produced within an hour. The whole point is to determine whether the candidate is someone we could work with, and whether they have fire, agility, adaptability, ability, and good communication. I don’t care if someone can figure out why manhole covers are round. I want to know how well they’re going to perform in the context of our team, and our business. The best candidates rock these qualities out, just like the most successful entrepreneurs I’ve met do the same.
I’ve written before about hiring for cultural fit, and about the importance of prioritizing cultural fit over competence when hiring at startups. I started thinking about it again when I saw this Dilbert comic, because it pokes fun at the culture of startups and their propensity only to hire people who fit into them. But what are we talking about when we talk about cultural fit, anyway?
You’re probably familiar with some of the stereotypes around startup culture (free massages and dry cleaning, craft beer, cool art on the walls and dogs at the office, pulling all-nighters to ship on time) and the kinds of people who work at startups (according to Dilbert, “self-conscious hipster” types with “an earring and headphones.”) Stereotypes like these give you a picture of what startup culture might look like to an outsider, but they don’t reflect the intrinsic values that define startup cultures.
Gnip CEO Chris Moody explains this distinction really well when he talks about values vs. vibe. He defines values as “the guiding principles or code-of-conduct” that inform a company’s daily operations, whereas vibe is “the emotional side of the company … highly influenced by outside factors.” To figure out whether an aspect of your startup culture is a value, he says, try asking yourself these questions:
– Is this aspect of the company important to our long-term success?
– Does this aspect need to be maintained forever and is it sustainable?
– Does this aspect apply to all areas of the company and to all employees?
– Will establishing this aspect help us make important decisions in the future?
So, for example: riding your fixi to the office or playing foosball between coding sessions are vibes. Treating people with respect or being passionate about your work? Those are values.
Your company values should be clear, accessible, and pervasive – take, for example, Zappos’ 10 core values. Having clearly defined values is important because they drive your company culture, not the other way around. It’s also important when you’re hiring for cultural fit, because without clear company values you run the risk of making poor hiring decisions: hiring people because they look or act or talk like you, and not hiring people because they don’t.
Here’s an example: Businessweek says hiring managers are now asking candidates questions like, What’s your favorite movie? Or, What’s the last book you read for fun? If you’re asking interview questions like these at your startup, you need to make sure you’re screening for values and not for vibe. Just sharing your love of The Big Lebowski doesn’t make someone a good cultural fit for your company: in fact, it’s often the people who give unexpected answers who end up being your company’s most creative problem-solvers.
I chair the board of directors for the National Center for Women & IT (NCWIT), whose Entrepreneurial Alliance works with startups to help them recruit and retain more women in tech roles. There’s strong ROI for including more women on technical teams: women improve collective intelligence, make startups more capital-efficient, and bring the perspectives of half the population. But if you’re a “dude brew” startup, you may not even know why you don’t hire more technical women, and you might need help from NCWIT removing gender bias from its portfolio companies’ job ads.
Gnip recently told NCWIT that they added three women to its engineering team. They credited this in part because the VP of Engineering, Greg Greenstreet, attended every local women-in-tech networking event, recruited on campus, and talked to as many female candidates as possible. But fundamentally they succeeded in hiring more women because, like Etsy, they made diversity a value. Gnip assigned strategy, money, and resources to their recruiting efforts, and factored diversity into evaluations of cultural fit.
Every startup is going to have a company culture, by design or by default, so you might as well design yours with values that attract and keep the best possible talent. Once you’ve distinguished between your values and your vibe, hiring for cultural fit won’t just be easier; it will give you better – and likely more diverse – employees.
If you’re interested in more information about joining NCWIT’s group of startups, let me know.
Chris Dixon had an important post over the weekend title The Idea Maze. He starts off with a very strong juxtaposition of thoughts around the importance of “the idea” to a startup.
Ideas_Matter: The pop culture view of startups is that they’re all about coming up with a great product idea.
~Ideas_Matter: In response to this pop culture misconception, it has become popular in the startup community to say things like “execution is everything” and “ideas don’t matter”.
Ideas_Matter’: But the reality is that ideas do matter, just not in the narrow sense in which startup ideas are popularly defined.
He explains this clearly in the rest of the post using the construct of the Idea Maze which is explained in the Coursera Startup Engineering course which I’ve been taking.
The argument around whether or not the idea matters in a startup is getting tedious and I think Chris does a nice job of dropping a bomb in the middle of it. But I don’t think the puzzle pieces get put together quite right.
I don’t agree with Chris’ assertion in Ideas_Matter’. My view is that a startup is a continuum of ideas. The initial idea may bear some resemblance to the idea at any future time, but the actual instantiation of the idea can vary dramatically over time based on the learning that happens along the way. The notion of the Idea Maze captures this construct, as does the work of Steve Blank and Eric Ries.
But that doesn’t mean that “the idea matters.” I believe that it means a different construct is needed other than “idea.” I accept that the answer isn’t just the “execution of the idea” since that misses the point also. As a result, I think we need to blow up the construct of “ideas vs. execution” since it’s both and neither.
Chris does a nice job of laying out how to navigate the Idea Maze using history, analogies, theory, and direct experience. That’s how I approach investing, and how Foundry Group uses our themes to guide what we invest in. If you think hard about what Chris is suggesting, it’s the path through the idea maze for most entrepreneurs that is the important thing.
Here’s a specific example from my own experience. I’ve always loved books. About ten years ago I started thinking harder about being a writer as part of what I do. I’ve used history, analogies, theory, and direct experience to help me figure out how I think about the publishing and content industry. I self published some content (my blog) and contributed to traditional print and online media. But rather than self publishing a book to start, I decided I needed to understand how the publishing industry has worked for the last 100 years by participating in it. I had a theory that over the next decade there would be a radical change in how the publishing industry worked, but in the absence of being a content provider (known as an “author”), I wouldn’t really understand the process. So I wrote several (now four) books with a publisher (Wiley). Hence – direct experience. I’ve also studied the history of the publishing industry and talked to many other authors about their experiences. And I’ve got many analogies about how other information based industries have been massively disrupted by technology. And now I have a very clear set of ideas about how the publishing – and content – industry is going to change and how I’m going to participate in that change as a writer.
My important idea wasn’t “disrupt the publishing industry.” Nor does that particular idea matter. But the continuum of ideas I’ve had over the last decade that emerged from this thought is incredibly powerful. And the emergence of that continuum in a startup has the potential to be very powerful. Or fail. Which is, of course, the nature of a startup.
Following is a guest post by Zack Rosen, co-founder and CEO of Pantheon. Pantheon is building “A big badass platform that will run 30% of the Internet.” They are making it easy for professionals to build, launch, and run websites. Pantheon is one of the Silent Killers in our portfolio – and I’m immensely proud of the progress they are making and excited about their future.
This post was an internal email to the Pantheon team following a major feature release (Multidev). When I saw it, I asked Zack if I could post it on my blog as an ode to all startups. Many of you are out on the frontier, and I thought Zack captured the essence of it in his message to his team.
From: Zachary Rosen
To: Pantheon Staff
Date: Thursday, July 18, 2013 2:19:42 AM
Subject: Welcome to The Frontier
The Frontier Thesis was a theory advanced by historian Frederick Jackson Turner in 1893 that American democracy was formed by the American Frontier.
“American democracy was born of no theorist’s dream; it was not carried in the Sarah Constant to Virginia, nor in the Mayflower to Plymouth. It came out of the American forest, and it gained new strength each time it touched a new frontier.”
You may have noticed me acting slightly more neurotic or animated lately. There is a reason for that. Apologies if I am bugging you out—it’s going to get worse.
I am very, very excited to be back here, on The Frontier.
I’ve been here before.
When I was was in college, I found some books written on the future social impact of the Internet on the World. I was a poor student, so I added them to my Amazon wish list as auctions.
Then one day I messed up, clicked the wrong button, and ordered hundreds of dollars worth of non-refundable, esoteric, nerdy used books…and over-drew my bank account. I remember thinking when they arrived, “Well, I guess I may as well read all of these stupid books that bankrupted me.”
I’m very glad I did.
That summer, this bumpkin/badass former governor from Vermont running for president (Howard Dean) had found this guy Joe Trippi to run his presidential campaign. It became clear to me that Joe had read the same books I had, and that he intended to see if the shit in the books actually worked.
I had to be there. The summer of 2003, I started an open-source (Drupal-based) project for the campaign (Deanspace), got a job in the campaign HQ in Burlington, VT, dropped out of school, and had about the most profound professional experience one could at age 19 in 2003.
I spent a year on the Dean campaign Web Team during the presidential campaign of 2004. We lost the campaign badly, but we won a major battle on The Frontier of Global Politics in the age of the Internet.
The Dean campaign Web Team proved a very simple but important idea to the world that year. We proved that you could challenge the political establishment and beat them at their own game (fundraising) by appealing directly to supporters via the Internet. That idea—which our team made work—has changed the world.
Barack Obama would not be president today without the path the Dean web team blazed. Knowing this has permanently altered the way I view my work.
Friends from the campaign went on to run Obama’s Internet operation. You’d have a hard time making the case that Obama could have won without their help.
That experience set the bar for me in my career. Ever since then, if my work is not on that scale, then I feel like I am wasting my time on this planet.
I’m at home back here on The Frontier.
What it’s like on The Frontier
For me, launching Multidev put Pantheon clearly on The Frontier. We’re doing new shit the world has never seen before.
Here are a few of my thoughts about our time here:
1. You know that quote from Margaret Mead? “Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.” The Dean campaign Web Team was 20 people, about the same size as Pantheon is today. Small teams can do huge things.
Accomplishing huge things is not easy. On The Frontier, there’s no rule of law and there are no guarantees. There are consequences if we get it wrong. We won’t be destitute, but we’ll always wonder if we could have done better.
On The Frontier, we know this, and we still go after the big problems, six-shooters blazing.
2. There are not very many people out here on The Frontier. It can be strangely quiet and peaceful. Everyone has so many opinions when you make your journey out! “Well, what will you do when X happens?” “That won’t work.” “I don’t get it.” Or, my favorite, “I’d do it this way.”
But when you get out here, you get to see what will really work and what won’t. You survive by your wits. You learn to listen to and trust your gut.
How many other people are out here working as hard as we are to fundamentally fix website tech? …. *crickets*
3. What we are doing will look obvious in retrospect. “Duh, you can raise a ton of money for a presidential campaign online” is now common knowledge, but in 2003, we were looney. “Duh, websites are developed, launched, and run in the cloud” will be common knowledge soon enough.
The biggest ideas are usually the simple ones. They seem so confusing and hopeless before, somehow, all of a sudden, they are taken for granted.
Before any big city, there was once The Frontier.
4. We are blazing the path for everyone else. We are the leaders in our market, and they will follow, after we’ve found and laid the path. The entire world will follow us after we’ve found out how to make building, launching, and running websites easy.
Notice the other paths laid by other teams out here on The Frontier. This work is holy. When you pass another team blazing their path, tip your hat. This shit isn’t easy. Be gracious on The Frontier.
5. This is a special experience. We’re not saving the world directly. We aren’t surgeons in the O.R., or soldiers in harm’s way. We’re engineers laying down foundational tech that others will build on top of. Most will never see our work. But, through our work, we have the opportunity to shape what’s possible in the world around us.
With Multidev we set a bar for the software industry on what is possible when custom software is built, launched, and run in the cloud. The other leaders in our space are behind us. We are the ones who have built a cloud platform with such deep (full website stack) and broad (dev -> deploy -> scale lifecycle) capabilities, so we get to be the ones who discover what is possible.
You will remember this work, your time on The Frontier, for the rest of your life.
An increasing number of companies we are investors in are focused on DevOps. A year or so ago I read an early draft of a new book titled The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. I really enjoyed it and asked Gene Kim, one of the authors to write a guest post on DevOps. He wrote it a while ago and it has sat in my draft queue waiting for the perfect moment to emerge. That moment is now. Following is a guest post on DevOps by Gene Kim, Multiple Award-Winning CTO, Researcher, Visible Ops Co-Author, Entrepreneur & Founder of Tripwire.
Since 1999, my passion has been studying high performing IT organizations. On this journey, we benchmarked 1,500 IT organization to understand what differentiated the highest performing organizations and allowed them to do what the others only dreamed of. Our findings went into a book that we published in 2004 called The Visible Ops Handbook, which described how these organizations made their “good to great” transformation.
Since then, this journey has taken me straight into the heart of the DevOps movement. Although I initially dismissed DevOps as just another marketing fad, my friend John Willis corrected me, in the way that only true friends can do, saying, “Don’t be dense. DevOps finally proves how IT can be a strategic advantage that allows a business to beat the pants off the competition. This is the moment we’ve all been waiting for.”
In that moment, I saw the light. Over the years, I’ve come to believe with moral certainty that everyone needs DevOps now, especially software startups where the successful execution of Development and IT Operations preordain success or failure.
Today, we can see how DevOps patterns enable organizations like Etsy, Netflix, Facebook, Amazon, Twitter and Google to achieve levels of performance that were unthinkable even five years ago. They are doing tens, hundreds or even thousands of code deploys per day, while delivering world-class stability, reliability and security.
DevOps refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates), while simultaneously increasing the reliability, stability, resilience of the production environment.
The culture and practices that enable DevOps to happen cannot be delegated away. In a growing startup where teams start to specialize and multiply, the chaos of daily work often starts to slow down the smooth flow of work between Development and IT Operations, sometimes even resulting in outright tribal warfare.
In this blog post, I’ll describe what this downward spiral looks like, and what everyone in the company must do to break this destructive pattern and ensure that Development and IT Operations work together in a way that creates such a competitive advantage that it may almost seem unfair.
Why Everyone Needs DevOps
There is currently a core, chronic conflict that exists in almost every IT organization. It is so powerful that it practically pre-ordains horrible outcomes, if not abject failure. It happens in both large and small organizations, for-profit and non-profit, and across every type of industry.
In fact, this destructive pattern is the root cause of one of the biggest problems we face as an industry. But, if we can beat it, we’ll have the potential to generate more economic value than anything we’ve seen in the previous 30 years.
I’m going to share with you what this destructive pattern is in Three Acts, that will surely be familiar to you. (You can get the whole story in my book, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win).
Act I begins with IT Operations, where we’re supporting a large, complex revenue generating application. The problem is that everyone knows that the application and supporting infrastructure is… fragile.
How do we know? Because every time anyone touches it, it breaks horrifically, causing an epic amount of unplanned work for everyone.
The shameful part is how we find out about the outage: Instead of through an internal monitoring tool, it’s a salesperson calling, saying, “Hey, Gene, something strange is happening. Our revenue pipeline stopped for two hours.” Or, “the banner ads in my market are being served upside down and in Spanish.”
There are so many moving parts that it takes way too long to figure out what caused the problem du jour, which means we’re spending more and more time on unplanned work and increasingly unable to get our planned work done.
Eventually, our ability to support the most important applications and business initiatives goes down. When this happens, the organization suddenly finds itself unable to achieve the promises and commitments made to the outside world, whether it’s investors, customers, analysts or Wall Street.
Promised features aren’t delivered on time, market share isn’t going up, average order sizes are going down, specific revenue goals are being missed…And that’s when something really terrible happens.
In Act 2, everyone’s lives gets worse when the business starts making even bigger promises to the people we let down, to compensate for the promises we previously broke. Often, the entire organization starts dreaming up bigger, bolder features that are sure to dazzle the marketplace, but without the best grasp on what technology can and can’t do, or fully realizing what caused us to miss our commitments in the first place.
Enter the Developers. They start seeing more and more urgent date-driven projects put in the queue, often requiring things that the organization has never done before. Because the date can’t be moved (because of all those external promises made), everyone has to start cutting corners.
Development must focus on getting the features done, so the corners that get cut are all the non-functional requirements (e.g., manageability, scalability, reliability, security, and so forth). This means that technical debt starts to increase. And that means increasingly fragile infrastructure in production.
It is called “technical debt” for a reason—because technical debt, like financial debt, compounds.
When technical debt begins to accumulate, something very insidious starts happening. Our deployments start taking longer. What used to take an hour now takes three hours, then a day, then two days—which is okay, because it can still get it done in a weekend. But then it takes three days, and then a week, then two weeks!
Our deployments become so expensive and so difficult that the business says that we have to lengthen the deployment intervals, which goes against all our instincts and training. We know that we need to shrink the batch sizes, not make them bigger, because large changes make for larger failures.
The flow of features slows to a trickle, the deployments take even longer, more things go wrong, and because of all the moving pieces, issues take even longer to diagnose. Our best Dev and Ops people are spending all their time firefighting, and blaming each other when things go wrong.
I’m guessing that most of you can relate to at least some portions of this story? As I said, this happens both in large enterprises and growing startups alike. In my fifteen years of research in this area, I’ve found almost all IT professionals have experienced this cycle.
Act 3: How DevOps Breaks Us Out Of Our Downward Spiral
We know that there must be better way, right? DevOps is the proof that it’s possible to break the core, chronic conflict, so we can deliver a fast flow of features without causing chaos and disruption to the production environment.
When John Allspaw and Paul Hammond gave their seminal “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” presentation at the 2009 Velocity Conference, people were shocked and amazed, if not outright fainting in the aisles at the audaciousness of their achievement.
It wasn’t a fluke. Other organizations such as Facebook, Amazon, Netflix and the ever-growing DevOps community have replicated their performance, doing hundreds, and even thousands, of deployments per day. DevOps is not only for large, established companies. It’s for any company where the achievement of business goals rely upon both Development and IT Operations. These days, that means almost every company.
We all need to be putting DevOps-like practices into place. This is why Kevin Behr, George Spafford, and I wrote The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.
A novel, you might ask? How is a novel going to solve my problems?
As a friend once told me, “Before you can solve a complex problem, you must first have empathy for the other stakeholders. And story-telling is most effective means of creating a shared understanding of the problem.”
Dr. Eliyahu Goldratt demonstrated the power of a novel as a teaching tool through his book, The Goal: A Process of Ongoing Improvement. It’s a novel written in the 1980s about a plant manager who has 90 days to fix his cost and due date issues or his plant will be shut down. When I read this book nearly 15 years ago, I knew that this story was important, and that there was much I needed to learn, even though I never managed or worked in a manufacturing plant.
It isn’t an overstatement to say that The Goal and Dr. Goldratt’s Theory of Constraints changed my life—in fact, it probably was one of the biggest influences on my professional thinking. For eight years, my co-authors and I wanted to write The Phoenix Project, because we all believed that IT is not a department, but a strategic capability that every business must have.
As you can imagine, I was incredibly honored and thrilled when Jez Humble, author of the award-winning book Continuous Delivery recently told me, “This book is a gripping tale that captures brilliantly the dilemmas that face companies which depend on IT. The Phoenix Project will have a profound effect on IT, just as The Goal did for manufacturing.”
Prescriptive Steps
For those of you are looking for some places to start your DevOps journey, here are my three favorite DevOps patterns:
- Make sure we have environments available early in the Development process. Enforce a policy that the code and environment are tested together, even at the earliest stages of the project.In the ideal, IT Operations is able to create an environment (that is, everything except for the application code: databases, operating system, networking, virtualization layer, etc.) with one step. That can be as simple as copying a virtual machine, or as complex as an automated build system that generates the environment from scratch (e.g., puppet, chef, etc.)Furthermore, use the same build mechanism to build the Production, Test and Dev environments at the same time. If we modify the Agile sprint policy so that instead of merely having shippable code, we have shippable code and the environment that it runs within, we’ll have done code deployments many, many times when it’s time for the real-life production deployment.
- “Wake up developers up at 2 a.m. when they break things.” Yep, you heard me. This quote came from Patrick Lightbody, the CEO and founder of BrowserMob. He continued, “When we woke up developers, we found that defects got fixed faster than ever.”The goal is to shorten and amplify feedback loops, and to bring Development closer to the customer experience. In DevOps work streams, developers often deploy their own code, and fixes forward when things go wrong. By doing this, developers can see the consequences of their decisions and actions.(Note the symmetry here: the previous pattern #1 about making environments available early is all about embedding IT Operations into Development, while this pattern is about putting Development into IT Operations.)
- Create reusable deployment procedures: When every deployment is done differently, every production environment can become different, like snowflakes. When this occurs, no mastery is ever built in the organization in procedures or configurations. As Luke Kanies said, “If your infrastructure is special, you’re doing it wrong.”To make this reality, create reusable user story for IT Operations, such as “Deploy app into high availability environment,” which then goes on to define exactly the steps to build the environment, as well as how long it takes, what resources are required, etc.By doing this, we codify the deployment and engineering procedures requires to build reliable, resilient and properly configured environments, and can then factor that into our planning processes, such as in the PMO.
Conclusion
If you enjoyed this taste of DevOps and believe it can help achieve your goals, “The Phoenix Project” is available now, or you can download a free 170 page excerpt of the book. And of course, you can always find the latest writings on DevOps at the IT Revolution blog, where you can get our free whitepaper “The Top 11 Things You Need To Know About DevOps.”
Long live DevOps!
A classical relationship problem is the dichotomy between solving a problem and providing empathy. If you really want to understand this, spend two minutes and watch the awesome “It’s Not About The Nail” video below.
Amy and I have figured this out extremely well in our relationship. We talk about it in Startup Life: Surviving and Thriving in a Relationship with an Entrepreneur using the example of the scene from the movie White Men Can’t Jump to frame the situation.
There’s a delightful scene in the movie White Men Can’t Jump. In it, Billy Hoyle (played by Woody Harrelson) and Gloria Clemente (played by Rosie Perez) are in bed together. Gloria says to Billy, “Honey, I’m thirsty.” Billy gets up without saying word, goes to the kitchen, fills up a glass of water, brings it back to the bed, and gives it to Gloria. As Billy is crawling back into bed, Gloria tosses the water in his face. Startled, Billy says, “What?!” A long conversation ensues, which can be summarized as, “Honey, when I say I’m thirsty, I don’t want a glass of water. I want empathy. I want you to say, ‘I know what it’s like to be thirsty.’”
But this isn’t limited to personal relationships, or the difference between men and women (lots of men need empathy, even if they don’t know how to ask for it.) I see this all the time in my interaction with entrepreneurs and CEOs. I see it in the board room. And I see it in the way a CEO works with her leadership team.
The natural reaction in many of these cases is to immediately jump in and solve the problem. Granted, this is male-centric, as the ratio of men to women in these meetings at startups and entrepreneurial companies is very high. But it’s also CEO and entrepreneur-centric behavior; most CEOs and entrepreneurs are heat seeking problem solving missiles.
If you are an entrepreneur, CEO, or VC take a moment and think. Do you ever focus on “empathy” rather than “problem solving.” If you want to see an example of this in action, watch Jerry Colonna’s brilliant interview with Jason Calacanis. There’s a lot of incredible things on display in this interview, including plenty of empathy.
My partner Ryan send around the following awesome video about a bead-chain experience. It’s a fascinating phenomenon. Beautiful, actually.
Now, while the experiment, especially in slow motion, is beautiful, I especially enjoyed the discussion around trying to explain what was going on. I’m in conversations like this all the time – where someone is trying to explain how or why something happens based on observation.
This is in stark contrast to my experience at MIT. I call this experience “the engineer brain” where you immediately start going to the underlying mathematic model. The qualitative description is definitely useful, but what’s the underlying set of equations that describes what is going on.
I’m a huge believer in the five whys and use them all the time to try to understand something. I love both qualitative and quantitative explanations. And the underlying experimentation that helps surface the phenomenon.
And it’s a bonus when what you observe is fascinating and beautiful. For example, the following hits on both of those.
Startups fail. That’s part of the natural entrepreneurial cycle.
A great post is making the rounds from an entrepreneur who has 30 days left before he hits the wall. His blog – My Startup has 30 Days to Live – promises to be a powerful one, at least for 30 days. I’m only sad about two things: (1) It’s anonymous and (2) There are no comments so it’s one way.
I left a message on “Ask me anything” asking him/her to reach out if I can help. We’ll see if he/she responds – or it’s either (a) a one way rant or (b) a fake failure story.
Either way, entrepreneurs need to talk about failure. It’s fine – I’ve failed at a ton of things. On Monday, I gave my “How To Fail” talk at Techstars Boulder. Included were all the Startup Summer students as well as a bunch of members of the Entrepreneurs Foundation of Colorado. I told the story of my first failure (my first company – Martingale Software) and my biggest failure (Interliant). I made some broad points and then did an hour of Q&A.
I hope it was useful.
I see entrepreneurs, especially first time entrepreneurs, in denial all the time about the possibility of failure. “Failure is not an option”, or “I’m afraid to fail”, or “Everything is going great” (when it isn’t). Sometimes failure is your best option.
Denial of reality – and what you can do – is a big issue. Ignoring reality until it’s too late is another. Not reaching out for help when there is still time is yet another. Fear of failure – which is the mind killer – is yet another.
In one of my darkest moments of Interliant, I was sitting hunched over at the kitchen table of one of my co-founder’s (Len Fassler) – breakfast table. We had a brutal day in front of us and I was waiting for him to finish getting dressed so we could head to the office to deal with things. When he came into the kitchen, he saw me and said “C’mon Brad – suit up – let’s go.” He patted me on the back in the wonderful way he always does and said “Just remember – they can’t kill you and they can’t eat you.”
Follow My Startup has 30 Days to Live. Learn from it. And if the entrepreneur uncloaks, let’s try to help, even if it’s just providing emotional support.
One of my favorite acronyms of all time is IHTFP. Its originated at MIT in the 1950s and has achieved widespread adoption. And yes, it does actually stand for I Hate This Fucking Place, which as any MIT alumni will tell you, is part of the beauty of the MIT experience.
Today, I was in a meeting helping a CEO work on an upcoming investor pitch and told him that his problem was that he wasn’t getting to the fucking point. I scribbled down GTTFP. I just looked it up and lo and behold a new FLA (the cousin of the famed TLA) has now entered my vocabulary. It’s got nice onomatopoeia if you say it just right.
I’m on the receiving end of people who can’t seem to GTTFP multiple times a day. It’s especially true when someone is trying to create false intimacy at the beginning of a conversation, is using ancient sales techniques like the endless rhetorical question to try to build agreement from me, or is simply in a “tell rather than show” mode where they figure that if they beat me over the head with words I’ll read the conclusion they are trying to beat me over the head with.
Now, GTTFP is different than bloviating. While I don’t think I actually bloviate, I’ll often suggest that someone has just been on the end of a rant or a space jam of mine, which I often refer to as a good bloviate on my part. However, my bloviating almost always is storytelling – where I’m trying to give an example, or a lot of examples, by “showing rather than telling” to make a point.
But GTTFP is just an avoidance of actually getting to the point. Or its a ramble that doesn’t focus on what is trying to be communicated. Or it’s an effort to build connection in advance of making a point, which often comes across as saccarine.
Enough – GTTFP. Which is to say, simply, GTTFP.