Lessons learned from a cancelled project
This is the manuscript for a talk I gave to the GRWebDev. It is the story of a project we canceled at GitHub and the lessons I learned from it.
In October 2012, we gathered a team together to work on a product that would be a new market for GitHub, Inc (the company). The product was an evolution of some internal tools that we had built for recording and sharing presentations at our HQ in San Francisco for our remote employees.
When our team of 6 people was gathered into a room to kick off the project, we knew two facts:
- We had some tools hacked together internally for recording talks, and
- We had experience building a website for sharing slide decks (speakerdeck.com).
Our mission was to combine those two things into a product that would allow any company like us, a conference or a user group to easily record, stream and share talks.
11 months later, our team decided to cancel the project.
Curate a collective vision
This team had never worked together before. We had no shared experience, and no trust. In typical GitHub style, we also did not have managers or a roadmap. None of us knew exactly what the product would look like.
The best software comes from a team where everyone shares a vision, cares deeply about the result, and are motivated to make it happen. That level of caring and motivation can only come from people that had a role in crafting the vision and own a piece of it.
We eventually gained each others trust, and our visions started to coalesce, but only after spinning our wheels for 6 months.
Lesson 1: Curate a collective vision for the product.
Define success and failure
At a place like GitHub with no managers and no schedules, it is tempting to think that if I just work my hardest on a cool project that excites me, that it will magically be successful. This is a lie. Success is a lot of work. Success comes from intentionally avoiding critical mistakes and a lot of luck.
There is not a magical formula for achieving success, so I can’t tell you how to achieve it. But I know that it is impossible to evaluate if what you are doing is working without criteria to evaluate against. We worked on our project for 6 months before we even sat down to articulate what success and failure looked like.
Lesson 2: When you figure out what your vision is, define what it means to be successful, and just as importantly, define what failure looks like. Set goals for achieving success, and check in on those goals at regular intervals.
Create meaningful artificial constraints
Our project suffered from a severe lack of constraints. Money was not a factor, we had as much time as we needed, and we defined the feature set. Not everyone has the misfortune of this experience. Without constraints, there is no way to determining importance. When nothing is important, everything is important. When everything is important, prioritization and decision making is impossible.
It is well known that too many options overwhelm our brains. This phenomenon is chronicled in books like “The Paradox of Choice” or “How We Decide”. Our brains are quite good at comparing a few options. But when presented with too many options, our brains switch from their fast pattern-matching mode to a slow sequential scan to compare all the details.
The same thing happens on projects. Designing software to meet all of the requirements at once is paralyzing. Software is built one feature at a time. Choose constraints to help you focus on the details that mater.
Milestones are one form of constraint (Some people call them “deadlines”, but I prefer to call them milestones). A milestone is an arbitrary date by which you want to meet a goal. Fixed dates should never include scope. If you work 60 hours per week trying to meet a deadline, then you have missed the point. A constraint should never be used to get someone to work harder. It is a tool to enable you to work smarter.
Pick an arbitrary milestone, such as “first beta user 2 weeks from today”, or “first sale in 3 months”. Without fixed scope, deadlines essentially become goals. Everyone has intrinsic motivation to meet the goals.
Don’t change your deadlines in order to cram more features into them. When the deadline comes, ship what you have in its current state. That might sound horrifying, but trust me. Once you do that, you will quickly train yourself to focus on the things that matter and always keep the product in working order.
Lesson 3: Create meaningful constraints that make it easier to avoid failure and be successful.
People matter more than product
For the first 9 months, I cared more about the outcome of the product than the people on the team. I gave feedback on ideas, designs and code with the assumption that the most important thing about that interaction was creating a superior product. I was wrong.
Everyone on the team suffered from burnout. The constant grind of critical feedback was wearing us all down. Everyone lost motivation to work on the things that excited them because they did not think it would be good enough or the right thing to work on.
Lesson 4: If you care about people, the product will take care of itself. Pour all your energy into making sure your teammates are enjoying what they are doing. Happier people create better products.
“Failure” is not failure
Canceling a project can be devastating for some people. I had many coworkers that would come ask me “how are you doing?” as if I just lost a loved one. It has taken a lot of practice from past failures, but I have gotten good at dealing with “failure”.
Success is a poor teacher. Since there is not formula for success, and success comes so infrequently, the “survivorship bias” makes is difficult to identify what factors lead to success. It is nearly impossible to decipher if the project was successful because of or in spite of what the team did.
Canceling a project is a great learning experience. Deciding to cancel it is a conscious analysis that the resources being put into the project could be better used elsewhere. The biggest challenge is to be aware of that fact at the earliest possible moment so you avoid putting resources into something that is not worthy.
Lesson 5: “Failure” is when you learn how to do something better the next time. I like failure.
Why we cancelled it
We learned many more lessons in the 11 months that we worked on the product. These are the ones that seemed most significant to me. But none of these failures were the primary reason we cancelled the project.
Our slogan for GitHub.com (the website) is “Build software better, together.” As we have continued to grow and evolve, we have wrestled with whether or not this adequately describes the vision for GitHub, Inc, (the company). We often talk about our vision as a company is to “make it easier to work together than alone”. With up to 75% of our employees being remote, working together becomes particularly challenging when you are in different timezones. It is easy for people to become isolated. We run into unique challenges that other companies don’t face.
GitHub has always resonated with the open source culture in our desire to write software for problems that cause us pain. We feel the pain of working together in general, so we are tempted to scratch that itch. But I think we are finding that we have a much better understanding of how people work together on software. Building a tool to make it easier to work together in any other realm requires an intimate understanding of the unique challenges.
Ultimately we decided to cancel the project because it did not fit in with the vision of where GitHub is going. I would like to think that under different circumstances we would taken these lessons and still been able to ship a successful product. Or maybe we would not have learned these lessons without looking through the lens of “failure”.
Either way, I am thankful for the lessons it taught me, I look forward to applying these lessons on my next project.
I am Brandon Keepers, and I work at