Back to resources

Scaling Processes in a Startup

Scaling Team
Team Processes

13 April, 2021

Neshay Ahmed
Neshay Ahmed

CTO & Co-founder at Wavy

Neshay Ahmed, CTO and Co-Founder at Wavy, tells of her efforts to scale processes in an early-stage startup that doubled in no time.


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

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

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.

Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

How to improve engagement and retention in remote engineering teams?

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.

Company Culture
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

How I failed at my startup

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.

Mission / Vision / Charter
Scaling Team
Building A Team
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Scaling a Team in Two Parts: The Product and Manager

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.

Managing Expectations
Scaling Team
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

(Re)Organizing Your Teams Using Domain-Driven Design

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.

Scaling Team
Building A Team
Internal Communication
Ram Singh

Ram Singh

Principal / Founder at id8 inc