Articles

Tips on Scaling Teams from Engineering Leaders at Pinterest and Alteryx

April 1, 2021

Recently, our friends at Plato hosted a half-day virtual event, Elevate Spring Summit. At the event, senior engineering leaders shared advice on engineering leadership. The talks featured a lot of Q&A, in which audience members had their questions answered by the presenters. The presenters represented companies including Shopify, Range, Netflix, Zoominfo, Jellyfish, Facebook, Pinterest, Alteryx, Equinix and Workday. 

Panel discussion on scaling quickly

Two Lohika clients (Dave Burgess and Derek Knudsen) were featured in a panel discussion titled “What Breaks When Scaling Quickly (And How to Fix It).” The panel:

  • Shweta Saraf, Head of Central Engineering, Equinix Metal (moderator)
  • Dave Burgess, Head of Data Engineering, Pinterest
  • Derek Knudsen, CTO, Alteryx

In this post, I’ll summarize key segments of the panel discussion.

Lessons learned from scaling quickly

Shweta asked Dave and Derek to share a story about scaling quickly and what lessons they learned from it.

Dave told us about a start-up he onced worked at. He scaled the engineering team from two to 20 people. His focus was to hire the team and build a great product. His mistake? He didn’t spend enough time with users. 

He and his team built what they (i.e., the team) thought was the best product, not what users thought was best. For Dave, the fact that he had a top-notch team that consistently delivered two-week sprints didn’t matter if users didn’t use the product.

Dave’s lesson?

That delivering on customers’ needs is the number one priority. Don’t scale before you understand their needs, says Dave.

Derek joined Alteryx during a period of rapid growth. In a very short period of time, the engineering team doubled. Derek focused mostly on managing that growth, with less attention paid to whether the organization was properly structured for it. 

Looking back, Derek is reminded of Conway’s Law, which says that teams design and build systems that mirror their own communications structure. In other words, Derek found that what teams were building reflected the structure of the organization. Derek worked to optimize the team structure. Once that was achieved, the next challenge was on the process side. So he evolved internal processes in order to scale more effectively.

Note: Lohika’s Serhiy Masyutin wrote a related blog post, “Organizational structure, Microservices and Conway’s Law.”

Working with external engineering partners

When is the right time to bring on external engineering partners?

According to Derek, “I have ‘dated’ a lot on the partner side and I have not been very successful. That changed with Lohika. They’ve come in and seamlessly fit culturally into the organization. They have cultural sensitivity for that dimension. Their productivity has been outstanding. If you can find a company like Lohika that you can build trust in, that’s something you want to hold onto.”

Derek has worked with a number of external engineering partners. He’s had bad experiences with some partners, which makes it very important to find (and keep) the right ones. 

Dave says that external engineering partners can be a big help when scaling quickly. According to Dave, “To scale quickly, sometimes you need vendors like Lohika. Lohika has been a fantastic partner. I really enjoy working with them. You have to select partners well. It’s like getting married. Test them out with a few projects. Treat it like a long-term relationship and make sure you have a strong partnership.”

Strategies for scaling

Shweta posed this question to Dave and Derek: “What happens when your team size is fixed, but you want to scale your customer use cases?”

Dave noted that when scaling with a fixed team, things will undoubtedly break: systems, reliability, support processes and speed (i.e., things get slower). When this happens, it can impact the happiness of the team, as well as the satisfaction of customers. Dave reiterated his prior point, which is to ensure you have product-market fit before scaling.

Next, says Dave, focus on having reliable production systems. Doing so means that less developer resources are required to support those systems, which gives them more bandwidth to build new capabilities. 

For any production issues, Dave says it’s important to have a detailed post-mortem to find the root cause and fix it. Dave has his team use the “five whys” methodology, which employs a series of why-questions (i.e., five times) to understand what caused an issue.

Echoing comments that Dave made earlier, Derek’s approach is to make sure his team is building what customers need and want. Derek cited research that says that 70% of product features provide zero or negative value. Teams must be precise and surgical in what they build, says Derek. At a fixed team size, deficiencies cannot be made up for with extra capacity. It’s important that whatever you build is bringing value to customers.

Keeping culture in mind when scaling

The next question Shweta presented Derek and Dave was “Tell us about your approach to scaling your processes and culture?”

Derek noted that managing culture is a challenge during periods of rapid growth. When scaling, it’s necessary to add process frameworks to ensure the team is consistently delivering measurable outcomes. But processes add organizational layers and formality that can cause friction in the culture. 

Processes can feel heavy-handed. For Derek, the key is to develop trust with the team that leaders have their best interests in mind. Derek referred to Daniel Pink’s book “Drive: The Surprising Truth About What Motivates Us,” which notes that people are motivated by autonomy, mastery and purpose. 

Note: Colin Cox referenced the same book in his Lohika guest post, “How to Keep Remote Engineers Productive? Fulfill These Three Basic Desires.”

Dave’s approach is to document the company’s culture. He identifies the “cultural carriers,” those team members who exemplify what you want in your team and culture. He then supports those people and gives them recognition. When scaling processes, Dave says to identify the biggest pain points and address them. Once you reduce or eliminate those pain points, the processes become more efficient and scalable.

Watch the panel discussion

For all of Dave and Derek’s insights, watch the recording of their panel discussion.