Creating a product after rapidly expanding a team
Chief Technology Officer at Accellion
"When I was an engineering manager, I was tasked with creating a new product for our company. My team was very small, with just three people, and we were also managing a legacy product. As we were moving forward with the new beta-product, a decision was made to replace the legacy product with the new product that we were building. To do this, we decided to have everyone from the team work on the new product, and to hire a large number of remote workers to accelerate the development of the new product."
"My team went from just three people to almost 100 in about four months, with teams in Palo Alto, Ukraine, and Singapore. This meant that my team's structure had changed from having three people meeting in Palo Alto every day to having teams divided into small chunks, with scrums happening at midnight, and at six in the morning, as the team couldn't all meet at the same time. I needed to find a way to get control over this."
"This project required a lot of overhead from me to ensure that everybody was inspired to work on the project and to do a good job. I architected a lot of the initial piping to ensure it was something worth building, but after that I went about evangelizing the idea and ensuring that everyone had the same vision about where the project was going to go."
"Growing my team meant that we had to come up with a process for doing code reviews, automate our repository, come up with code standards, and build scrum teams. Having so many team members meant that our code was a little all over the place, so I wanted to take control of it, and to ultimately have automation to do builds on a daily basis, and to have continuous integration."
"By doing this, we were able to bring the initial portion of the product four to five months after creating the large team. It wasn't my choice to ship at this rate, but it was the directive given to me by senior management. Developers don't want to ship bugs, so you have to convince them that they need to in order to make management happy. If I had been too hard-nosed, expecting perfection before launching the product, the project would never have happened. While there were bugs in the product that upset customers, shipping it got the product off the ground."
"In the subsequent years, I was also faced with managing team members' expectations in terms of where the product would go next, how it would grow, and how we would continue to be successful while also fixing bugs. For the next couple of years, we spent time increasing the product's stability, and keeping the team mentally stimulated, so they would come to work with their best foot forward, and provide their best ideas, not only for the product, but also for testing and team improvements. To do this, I actively went about motivating just a few people in the team, so that their motivation would trickle down to their team members."
"Finally, I also ensured that if customers called in with a problem that there was always somebody available who could help them solve the issue. Our product was a standalone product that customers install in their own data centers, so they control it. There are a lot of interesting issues that come with this, as engineers needed to come to understand that if they shipped a problem, they couldn't just ship a fix straight away, as the product is running in the customer's environment."
"Part equality is extremely important, even at the beginning of a project. Inspiring people to do a good job is probably the most important factor to consider when building a quality product."
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.