Finding start-up leaders
CTO at Opentrons
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.
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.
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!
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.