Back to resources

Scaling a Team in Two Parts: The Product and Manager

Managing Expectations
Product
Scaling Team
Leadership
Meetings

2 August, 2022

Viswa Mani Kiran Peddinti
Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Gaining a Larger Workload as a Result of Scaling

Previously, I worked in a team that was called Cities. The team’s goal was to help Airbnb hosts comply with regulations as new cities passed regulations. As Airbnb worked actively with cities, the pace has increased from a few per quarter to many per quarter.

As with cities, the team started to scale as we hired more and more members. Alongside the hiring, we focused on building a platform for multiple people to work on projects together.

Learning to Scale Multiple Aspects at the Same Time

To Scale the Product:

In the beginning, each City regulation was hand implemented, but as regulations increased, we needed a faster way to implement these regulations. To scale, we standardized our offerings and platformed the product by making it config and content driven. This allowed us to express the product behavior as well as the content through some variables. It was indeed an example of upgrading a Cessna into a Boeing. This journey taught us a few things in building product platforms:

  • It’s hard to foresee all use cases of the future and hence getting the balance is tricky. We learned to build incrementally where you treat every use case that is not supported as a new opportunity for use case expansion.
  • It is hard and risky to build the platform in parallel and switch to the “new platform”. You have to start with the piece that is most often customized and make it modular. We also built the modularity in layers where with each new layer, we increased the configurability.
  • Observability and Validations become increasingly important as the easier to launch, the easier to make a mistake, and the impact of such a mistake.

To Scale the Organization:

As the product started scaling, we hired a lot more people on the team and had to scale the organization to deliver effectively. We needed to organize ourselves into teams, introduce new processes and be comfortable with everyone not knowing everything that was going on in the team. The scaling of the organization proved to be harder than scaling the product. We have made mistakes and learned a few lessons as an organization.

  • Separating the platform/tooling team with the product team ended up with a ton of challenges leading to the product team quickly burning out and unhappy. Each team has a balance of building the Platform as well as the product using that platform made a better approach
  • Growing organizations will almost never have time for Platform work. When there is a time crunch, this often gets cut. Integrating Platform improvements into the product build helped with prioritization. So we would take x% more time to build better or refactor the existing platform to support the new use cases.
  • Taking calculated risks like investing the potential time gains of platformization in that work at the beginning of the quarter to leverage those gains later in the quarter was helpful to make continuous progress on platformization
  • Platform investments require conviction from leadership. Showing intermediate results will help in protecting time for such investments.

Scaling Myself as a Manager:

As the team grew, we first had two managers managing multiple teams. Eventually, I had to inherit the other team(s). Scaling myself was especially important as we scaling products, as mentioned above, required a tighter execution. With the two teams following different processes, the following helped in scaling myself:

  • Don’t change any team process immediately. This was important to help each team continue to have the momentum in executing. While this made it harder for me to follow the two distinct processes, it was helpful for the team. Eventually, I changed the process where it made sense to standardize.
  • Moved 1-1’s from weekly to bi-weekly and made 1-1’s more personable by listening to the team challenges. It is important to recognize what you want the most out of 1-1s so this time can be used more effectively. Things like work updates can be done async in slack. It is also ok to have different cadences for different people. Some people need more guidance and others less. Thus we can adjust based on the same.
  • Information sharing is critical when running multiple teams that require close nit execution. A weekly update email with top of mind, meeting summary, and additional context was helpful in ensuring both teams had context and information from the other and avoided repetition of information in 1-1’s
  • Delegate what you can. I was able to find engineers who are passionate about running different initiatives I was running originally opening my time.
  • Block dedicated time to review the work of people async. This is crucial to ensure one has a good understanding of the work and gives continuous feedback. Doing an informal performance review once a quarter also helped with gathering and capturing the work and feedback to be later used in formal performance reviews.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

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
Impact
Strategy
Prioritization
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

High Performance Team in Action

13 October

A high performance team refers to “ a group of goal-focused individuals with specialized expertise and complementary skills who collaborate, innovate and produce consistently superior results.”

Managing Expectations
Building A Team
Company Culture
Feedback
Coaching / Training / Mentorship
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Director at Curology

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

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
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart