Scaling Processes in a Startup

Problem

When I joined my past company, I was the second senior developer on a back-end team. Needless to say, the way any team with two senior developers works is vastly different from how a five-person team works. Two senior people don’t need a lot of processes. There is typically a lot of informality and most conversations are ad hoc.

Within a year of me being there, we hired two more people and became a team of five, including the CTO.

Typically, in software development, when you build something, you’ll build it for a single-use case. On a second use case, you’ll build a second implementation. By the time a third use case comes in, you’ll need to standardize things. This problem is the 1,2, N problem. The same occurred as we added new team members. The number of conversations and processes happening increased, and the ambiguity of how the team worked increased. It was time to standardize.

Actions taken

First and foremost, we started to talk to each other and listen to everyone’s input. We introduced weekly one-on-ones setting them for continuity following onboarding. We also had to diversify our conversations both in terms of format and content.

We realized that we had to share the existing business knowledge. As you are scaling, knowledge shouldn’t be kept in silos. If team members are not talking to each other, planning and designing their features together, a lot of that knowledge will remain tribal or will be lost for good. To help with that, we introduced weekly team meetings so everyone knew what the other person was working on and could bring suggestions onto the table early on in the process. If there was a larger tech investigation, the purpose of our meetings was to involve the right people and make sure that there were no surprises.

Initially, we didn’t have any coding standards, and building those came as a priority. To set standards, we often had to go to the basics. But we also had to align on more advanced issues, for example, what constructs in Ruby we would use and how people would feel about choosing those. The goal was that whenever one comes into a code review, they should know in advance what the standards we were following. Otherwise, any new person joining would bring their own standards and unique experience.

Finally, we added fire fighting rotation, so we could all share the load of supporting our clients and other teams and learn about the business problems other teams face. Also, it created an opportunity to learn more about problems our clients were having and have developers move closer to the business and understand where the real-world problems come from.

Lessons learned

• The first few people are critical in how you will shape the future of the team.
• All processes have their learning curve. It took us around six months to have everything set together.
• When your co-workers feel they're listened to and that you are taking action on the feedback they provided, there is an increase in motivation and engagement. Being heard, they will be more motivated to put their best foot forward at work.
• Communication is key, and it reduces a ton of confusion. I don’t believe there is such a thing as overcommunication. People are absorbing different things at different rates at different times. Therefore always keep repeating and reiterating until everyone is on the same page.
• Knowledge shouldn't be kept in silos. Always share your ideas and build space for sharing of ideas. This is how creativity is sparked and nurtured.
• There will always be gaps no matter what you do. The question is how you will decide to move forward in tackling those gaps.
• Sometimes it doesn't matter what the decision is, as long as a decision has been made that everyone can align on and follow.