Scaling Processes in a Startup
13 April, 2021

CTO & Co-founder at Wavy
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
25 October
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Mrunal Kapade
Director of Engineering at Inspire Energy
14 October
There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan
2 August
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
12 July
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Ram Singh
Principal / Founder at id8 inc