Back to resources

Finding start-up leaders

Scaling Team
Handling Promotion
Leadership
Hiring
Career Path
New Manager

6 December, 2017

Gautam Prabhu
Gautam Prabhu

VP Engineering at PagerDuty

Gautam discusses how to identify leaders, to improve the organizational structure of startups.

Problem

There is a common pattern I've noticed in small start-ups, where managers come into the start-ups and everything is very flat. You'll often have a team led by a single engineering manager, and in some cases that might be their first stint doing management, especially if they are a founder. At some point, this structure can become overwhelming.

When I started working at Zendesk, there fortunately was an experienced engineering leader in place, but he was spread too thin. The development team immediately started to report to me and this team steadily grew until it had about 30 people. This meant I was faced with handling 30 one-on-ones, 30 performance reviews, and I had 30 people to keep track of. I needed to break this large team down into smaller and more focused groups.

Part of the challenge was working out what the right functional groups to make were. I had to work out how to take a software system and break it into logical pieces that can be worked on independently. However, the more important challenge I faced was finding the right people to lead those groups. It was difficult as the team members were used to all being peers, and I needed to give some of them lead roles.

Actions taken

I started out by sitting in on every single meeting that I could and I dealt with every stressful situation that I could. For several months, I had the role of making decisions and working out complicated situations. But then I slowly began to talk less and observe more, and let the team start to work out problems without me. This allowed me to see who was filling the gaps naturally and without being asked to. In some cases, there were people who were obviously doing it and in others there were people who needed a little bit of a push.

I identified three different people who I thought were the right set of people to be engineering leaders. They all had various strengths, but different ones stood out for the 3. One of them was great at socially organizing a team and could ensure it worked well together. From a technical standpoint, he was great but his strength was in getting a team to function well. The second was great at filling in technical gaps, and whenever there was a technical issue that the team was facing, they could escalate it to him, and he'd sort it out. He wasn't an experienced leader at that point, but the team ran really well, as they knew they could get help if they ran into a technical issue.

The third person was a mix of those two strengths. He was technically strong, but also good at organization. He was the most prepared for a leadership role, as he had strengths on both sides. While he wasn't able to solve every technical issue, he knew enough to solve most. He was also good at the social/organizational side. The team liked him, he had a good personality for this type of role, and he was also naturally willing to deal with conflict. His strength was in making sure that he was shielding his team from issues going in our company that didn't need to affect his team. However, he also would let them know of issues and pain points, so that they could connect organizational issues with the work they were doing. When there were times he needed to protect his team he was able to do that. But when we needed to put pressure on the team, he was also able to do that.

After identifying these three people, I took my team of 30 people and divided it into three groups. Initially, this was based on taking the software system and breaking it into logical pieces that could be worked on independently. However, once I had made these teams, I was able to assign the leaders based on my personality assessment of each of them. My next step was putting them in charge.

Lessons learned

The first lesson that I learned is that while it's important to socialize the concept of putting a hierarchy in place with the team, you will never get unanimous consent on it. There were people on the team who felt the existing structure was fine, or advocated for a different structure than the one I proposed. I incorporated what feedback I could, but also made it clear that I was going to do this, but check in frequently with the entire team for feedback and to make course corrections if needed. The second lesson is that you need to give your new leaders support as well as "breathing room". This can be tricky: you don't want to be there all the time and interfere with their decisions. Sometimes you need to let these new leaders grow by experiencing some pain! At the same time, I wanted to make it clear that I supported these leads. I chose to rotate through each team's scrum meetings - for the first few weeks I would try to "embed" with a team for a week at a time. Then I slowly reduced the embedding frequency, and within 2 or 3 months, I was out completely.
The third lesson was in the timing: it's nice to do this type of restructuring during a period of low pressure. I held off on doing this until our major deliverable for the year (which involved most of the team) was delivered, and there was an opportunity to "reset" the way we worked.
Lesson 4: different leaders have different styles! Try to match the team members and the subject matter to the style of the lead. And understand that teams will function very differently from each other; some of this is because of the nature of what they are working on, and some of it will come from their lead. The last lesson was that this stuff takes time to get right. Some teams were immediately successful, others were not. It takes time to get things right, expect to make lots of little tweaks and changes until the team feels like it's happy and efficient!

Discover Plato

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


Related stories

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

How to Enter QA With a Non-Technical Degree

2 August

Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.

Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Career Path
Lewis Prescott

Lewis Prescott

QA Lead at CeraCare

Congratulations you're an Engineering Manager! Now What?

29 July

Congratulations, you have just been promoted to an engineering management role. Once you are done celebrating the promotion you have worked hard to earn you might start to ask yourself, now what do I do?

Leadership
New Manager
AJ St. Aubin

AJ St. Aubin

Director Software Engineering at The RepTrak Company

(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.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty