Lessons learned from a buried project
This text is based on my speech on GRWebDev . This is the story of the project that was canceled and buried on GitHub, as well as a story about the lessons learned during the work on it.
In October of 2012, we put together a team to develop a product that would allow GitHub, Inc. to enter new markets. This product was supposed to arise as a result of the evolution of some internal tools that we developed to record presentations at our headquarters in San Francisco and 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 practices for recording negotiations; and
2) We had the experience of 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 conversations (talks) and share them.
After 11 months, our team decided to stop working on this project.
Members of our team have never worked together before. We had no common experience, and no confidence. 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 shared vision, truly cares about the result, and is motivated to achieve it. This level of involvement can only be achieved where everyone participates in the formation of a shared vision and “owns” its part.
Gradually, we won the trust of each other and our ideas about the product began to unite, but by that time 6 months had passed.
Lesson 1: Form a single vision of the product in the team.
In a place like GitHub, where there are neither managers nor tight deadlines, there is a temptation to believe that “if I just work hard on the“ cool ”project that turns me on,” everything will magically become “good and beautiful". It's a lie. Success is a lot of work. Success comes when you deliberately avoid critical mistakes and still have a lot of “luck”.
There is no magic formula for how to succeed, and I will not tell you that. But I know that you cannot say whether you have reached 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 sat down at the table for the first time and discussed what can be considered a success, and what a failure on a project.
Lesson 2: When you have developed a common vision, develop a definition of success, and, equally important, a definition of failure (failure). Set goals on the road to “success” and regularly check project status against these goals.
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 defined the set of product features. Not everyone in his life had such a misfortune. Without restrictions, you cannot define “importance.” When “everything is important”, it is impossible to set priorities 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 select from several options. But when the options become too much, the brain moves to a slow bust of them all with a comparison of various details.
The same thing happens in projects. Software development to meet all requirements "immediately" - paralyzes. Software is created “by function at a time”. Choose constraints to help you focus on what’s important at the moment.
Milestones (milestones) are one of the forms of such restrictions (some call them “deadlines”, but I prefer “milestones”). A milestone is a specific date by which you are going to reach a certain goal. Fixed dates should NEVER include a skoup (set of specific requirements). If you work 60 hours a week to meet the milestones, then you did not understand what I was talking about. Restriction should not force anyone to work MORE. It should help you work BETTER.
Choose a reasonable milestone, for example, “first beta user after 2 weeks, counting from today”, or “first sale after 3 months”. Without a fixed scop, deadlines essentially become targets. People tend to be motivated to “achieve the goal”.
Do not change the deadlines to "finish" more features. When the deadline comes, lay out what is. It may sound terrifying, but believe me, as soon as you do, you will quickly learn to focus on the things that are really important, and always keep the project in working order.
Lesson 3: Create artificial constraints that will avoid failure and help you achieve success.
In the first 9 months, I cared more 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-class product. I was wrong.
Everyone in the team suffered burnout. Permanent millstones of mutual criticism grind each of us. We lost the motivation to work on things that we were so fascinated with before, because everything you did could soon turn out to be “useless” or “done wrong.”
Lesson 4: If you care about people, the project will take care of itself. Do not make any effort to ensure that everyone in the team likes what he does. Happy people create better products.
Cessation of the project can be a devastating experience for people. Many colleagues approached me then with the question “how are you?” With such a look as if I had lost a loved one. It took a lot of experience, but gradually I learned to perceive the “failures” correctly.
Success is a bad teacher. Since there is no formula for success, and it comes in so impermanently, the “survival bias” 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 did in the project.
Stopping (canceling) a project is a great and instructive lesson. The decision to cancel is the result of a careful 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.
We have received many useful lessons in these 11 months. The above is what seemed most important to me personally. But none of these errors caused the project to be minimized.
Our slogan for github.com (site) sounds like "We create better programs together." As we grow and develop, we are constantly faced with the question of whether this is an adequate description of the vision of GitHub, Inc. (companies). We often say that our vision of a company can be described as “making work together easier than one at a time”. Considering that up to 75% of our employees work remotely, teamwork becomes especially nontrivial when you are with colleagues in different time zones. We are faced with unique, not typical for most companies, challenges.
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 during joint (remote) work, so we are always ready to “scratch this crust”. But I think we understand better the problems that arise when working together on a program code . Creating a tool that would facilitate collaboration in other areas requires a very good understanding of various unique problems.
In the end, we decided to roll up the project, because it did not fit into the vision of where GitHub is heading. I would like to think that in other circumstances we would take these lessons into consideration and still be able to produce a workable product. Or maybe we would not have learned these lessons if we had not suffered a “failure”.
Anyway, I am grateful for these lessons and I hope to apply this knowledge on my next project.
In October of 2012, we put together a team to develop a product that would allow GitHub, Inc. to enter new markets. This product was supposed to arise as a result of the evolution of some internal tools that we developed to record presentations at our headquarters in San Francisco and 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 practices for recording negotiations; and
2) We had the experience of 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 conversations (talks) and share them.
After 11 months, our team decided to stop working on this project.
Develop a common vision
Members of our team have never worked together before. We had no common experience, and no confidence. 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 shared vision, truly cares about the result, and is motivated to achieve it. This level of involvement can only be achieved where everyone participates in the formation of a shared vision and “owns” its part.
Gradually, we won the trust of each other and our ideas about the product began to unite, but by that time 6 months had passed.
Lesson 1: Form a single vision of the product in the team.
Define "success" and "defeat"
In a place like GitHub, where there are neither managers nor tight deadlines, there is a temptation to believe that “if I just work hard on the“ cool ”project that turns me on,” everything will magically become “good and beautiful". It's a lie. Success is a lot of work. Success comes when you deliberately avoid critical mistakes and still have a lot of “luck”.
There is no magic formula for how to succeed, and I will not tell you that. But I know that you cannot say whether you have reached 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 sat down at the table for the first time and discussed what can be considered a success, and what a failure on a project.
Lesson 2: When you have developed a common vision, develop a definition of success, and, equally important, a definition of failure (failure). Set goals on the road to “success” and regularly check project status against these goals.
Create meaningful artificial limitations.
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 defined the set of product features. Not everyone in his life had such a misfortune. Without restrictions, you cannot define “importance.” When “everything is important”, it is impossible to set priorities 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 select from several options. But when the options become too much, the brain moves to a slow bust of them all with a comparison of various details.
The same thing happens in projects. Software development to meet all requirements "immediately" - paralyzes. Software is created “by function at a time”. Choose constraints to help you focus on what’s important at the moment.
Milestones (milestones) are one of the forms of such restrictions (some call them “deadlines”, but I prefer “milestones”). A milestone is a specific date by which you are going to reach a certain goal. Fixed dates should NEVER include a skoup (set of specific requirements). If you work 60 hours a week to meet the milestones, then you did not understand what I was talking about. Restriction should not force anyone to work MORE. It should help you work BETTER.
Choose a reasonable milestone, for example, “first beta user after 2 weeks, counting from today”, or “first sale after 3 months”. Without a fixed scop, deadlines essentially become targets. People tend to be motivated to “achieve the goal”.
Do not change the deadlines to "finish" more features. When the deadline comes, lay out what is. It may sound terrifying, but believe me, as soon as you do, you will quickly learn to focus on the things that are really important, and always keep the project in working order.
Lesson 3: Create artificial constraints that will avoid failure and help you achieve success.
People mean more than a product.
In the first 9 months, I cared more 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-class product. I was wrong.
Everyone in the team suffered burnout. Permanent millstones of mutual criticism grind each of us. We lost the motivation to work on things that we were so fascinated with before, because everything you did could soon turn out to be “useless” or “done wrong.”
Lesson 4: If you care about people, the project will take care of itself. Do not make any effort to ensure that everyone in the team likes what he does. Happy people create better products.
“Failure” - not failure
Cessation of the project can be a devastating experience for people. Many colleagues approached me then with the question “how are you?” With such a look as if I had lost a loved one. It took a lot of experience, but gradually I learned to perceive the “failures” correctly.
Success is a bad teacher. Since there is no formula for success, and it comes in so impermanently, the “survival bias” 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 did in the project.
Stopping (canceling) a project is a great and instructive lesson. The decision to cancel is the result of a careful 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 we canceled the project
We have received many useful lessons in these 11 months. The above is what seemed most important to me personally. But none of these errors caused the project to be minimized.
Our slogan for github.com (site) sounds like "We create better programs together." As we grow and develop, we are constantly faced with the question of whether this is an adequate description of the vision of GitHub, Inc. (companies). We often say that our vision of a company can be described as “making work together easier than one at a time”. Considering that up to 75% of our employees work remotely, teamwork becomes especially nontrivial when you are with colleagues in different time zones. We are faced with unique, not typical for most companies, challenges.
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 during joint (remote) work, so we are always ready to “scratch this crust”. But I think we understand better the problems that arise when working together on a program code . Creating a tool that would facilitate collaboration in other areas requires a very good understanding of various unique problems.
In the end, we decided to roll up the project, because it did not fit into the vision of where GitHub is heading. I would like to think that in other circumstances we would take these lessons into consideration and still be able to produce a workable product. Or maybe we would not have learned these lessons if we had not suffered a “failure”.
Anyway, I am grateful for these lessons and I hope to apply this knowledge on my next project.
Source: https://habr.com/ru/post/221391/
All Articles