« swipe left for tags/categories
swipe right to go back »
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.
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.
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.”
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.
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.