Lessons learned from a buried project

Original author: Brandon Keepers
  • Transfer
This text is based on my presentation on GRWebDev . This is the story of a project that was canceled and buried on GitHub, as well as the lessons learned from working on it.


In October 2012, we assembled a team to develop a product that would enable GitHub, Inc. to enter new markets. This product was supposed to arise as a result of the evolution of some of the internal tools that we developed to record presentations at our headquarters in San Francisco and to demonstrate them to our remote employees.

When our team of 6 people gathered in a team to start the project, we knew 2 things:
1) We had some internal ideas for recording negotiations; and
2) We had experience creating a website for sharing presentation slides ( speakerdeck.com )

Our mission was to combine these two things into a product that would allow any company or group of users to record and play back recordings of conversations (negotiations) and share them.

After 11 months, our team decided to stop working on this project.

Develop a shared vision



Our team members have never worked together before. We did not have a common experience, and there was no trust. In a typical GitHub style, we had neither a manager nor a roadmap. None of us knew exactly what, generally speaking, should be our product?

The best programs come from teams where everyone shares a common vision, really care about the result, and are motivated to achieve it. This level of involvement can only be achieved where everyone participates in the formation of a common vision and “owns” part of it.

Gradually, we won each other's trust and our ideas about the product began to unite, but by that time 6 months had passed.

Lesson 1: Build a Single Product Vision in a Team

Define Success and Failure



In a place like GitHub, where there are no managers or tight deadlines, there is a temptation to believe that “if I just work my best on a“ cool ”project that turns me on, then everything will magically become“ good and beautiful". It's a lie. Success is a LOT of work. Success comes when you deliberately avoid critical errors and still have a lot of luck.

There is no magic formula for how to achieve success, and I won’t tell you that. But I know that you cannot say whether you have achieved it or not, if you do not know how to evaluate it, by what criteria. We worked on the project for 6 months before we first sat at the table together and discussed what could be considered success and what was failure on the project.

Lesson 2: When you have developed a common vision, develop a definition of success, and, just as importantly, a definition of failure (failure). Set goals on the path to "success" and regularly check the status of the project with these goals

Create meaningful artificial restrictions



Our project suffered from a serious lack of restrictions. Money was not a problem, in time we were not limited by anything, and we ourselves determined the set of product functions. Not everyone in life has had such a misfortune. Without limits, you cannot define "importance." When “everything is important”, it is impossible to prioritize and make decisions.

It is well known that choosing from too many options “paralyzes” our brain. Our brains are very good when you need to quickly choose from several options. But when there are too many options, the brain switches to a slow enumeration of all of them with a comparison of all possible details.

The same thing happens in projects. Software development to meet all the requirements "immediately" - paralyzes. The software is created “by function at a time”. Choose limits to help you focus on what’s important right now.

Milestones are one form of such restrictions (some call them “deadlines,” but I prefer “milestones”). A milestone is a specific date by which you are going to achieve a certain goal. Fixed dates should NEVER include a scope (a set of specific requirements). If you work 60 hours a week to meet the milestones, then you do not understand what I'm talking about. The restriction should not force anyone to work MORE. It should help you work BETTER.

Choose a reasonable milestone, for example, “first beta user in 2 weeks from today,” or “first sale in 3 months.” Without a fixed scope, deadlines essentially become goals. As a rule, people have an inherent motivation for “achieving a goal”.

Do not change the deadlines to “finish” more features. When the deadline comes, lay out what is. This may sound horrific, but believe me, as soon as you do this, you will quickly learn to focus on things that are really important and always keep the project operational.

Lesson 3: Create Artificial Constraints That Help Avoid Failure and Help You Success

People mean more than a product.



In the first 9 months, I was more concerned about the outcome of the project than about the people on the team. I expressed my opinions about ideas, design and code, based on the assumption that the most important thing in our communication is the creation of a high-quality product. I was wrong.

Everyone in the team suffered from burnout. The constant millstones of mutual criticism grind each of us. We lost the motivation to work on things that previously fascinated us because everything you did could soon turn out to be “worthless” or “done wrong”.

Lesson 4: if you care about people, the project takes care of itself. Spare no effort to ensure that every person in the team likes what he does. Happy people create better products.

Failure is not failure



Terminating a project can be a devastating experience for people. Many colleagues came up to me then with the question "Well, how are you?" with the look as if I had lost a loved one. It took a lot of experience, but gradually I learned to correctly perceive the “failures”.

Success is a bad teacher. Since there is no formula for success, and it comes so inconsistently, the "bias of the survivor" makes it difficult to understand what exactly led to success. It is almost impossible to determine whether a team has come to success “thanks to” or “contrary to” what it was doing in the project.

Stopping (canceling) a project is a great and instructive lesson. The decision to cancel is the result of a thorough and balanced analysis of whether it is possible to use the resources spent on the project with greater benefit elsewhere. The most difficult thing here is to make this decision at the earliest moment, so as not to invest resources in something obviously useless.

Lesson 5: “Failure” is when you learn how to do better next time. I like failures.

Why did we cancel the project



We have received many useful lessons over the 11 months. The above is what seemed most important to me personally. But none of these errors caused the project to be scaled down.

Our slogan for github.com (the site) sounds like “Creating Better Programs Together.” As we grow and develop, we are constantly confronted with the question of whether this is an adequate description of the vision of GitHub, Inc (company). We often say that our vision of the company can be described as "making work together easier than one at a time." Considering that up to 75% of our employees work remotely, collaboration becomes especially nontrivial when you and colleagues in different time zones. We are faced with unique challenges that are not characteristic of most companies.

GitHub has always shared the desire of the open source community, in our desire to create programs that help us solve problems that hurt us. We feel the pain that occurs when working together (remotely), so we are always ready to "scratch this crust." But I think we understand much better the problems that arise when working together on software code . Creating a tool that facilitates collaboration in other areas requires a very good understanding of various unique issues.

In the end, we decided to curtail the project, because he didn’t fit into the vision of where GitHub was heading. I would like to think that in other circumstances we would take these lessons into account and still be able to release a workable product. Or maybe we would not have learned these lessons if we had not suffered “failure”.

Anyway, I am grateful to fate for these lessons and expect to apply this knowledge on my next project.

Also popular now: