Building the Right Team Early On

Problem

"I was brought on to lead a team of thirty remote employees already in place. We had interested customers and were just beginning to ramp up the remote team. They were ready to build (or so it seemed), but had not yet discussed what a working prototype would look like. After the initial kick off session with the team it became clear that they would only be able to build a clickable prototype in the time and budget allotted for the project. This would leave us pretty far behind what our early enterprise users expected."

Actions taken

"Ultimately, we chose to let go of the entire lot of remote devs and hired specialized contractors. We did this because we realized we needed a core member represented for each aspect of the product. We were able to pull together four specialists and build the first version with lower overhead. The company was able to move much quicker than when we had the team of 30."

Lessons learned

"The key lesson learned is that it's not the size of the team that affects timeline, it's about what can you get done in terms of value and output. The output should drive company growth. For us, we needed people that were ok with ambiguity. They didn't necessarily need to be an expert in the domain but they needed to be able to have an understanding of it. In general, avoiding groupthink was the best thing we could do to create a product with our original vision. Taking in the opinions of too many employees can allow tasks and features to snowball; you need a core group of management directing the decisions to stay true to the vision. Having a culture that reflects this will ensure that the rest of the team is empowered to make decisions that are good for the company and more importantly the user base."