Articles
Scaling a Team’s Impact with Gautam Prabhu, PagerDuty’s VP Engineering
June 9, 2020

Recently, Plato hosted an “Ask Me Anything” (AMA) webinar with Gautam Prabhu, VP Engineering at PagerDuty. Plato hosts their webinars on Zoom, with David Murray, Cofounder at Confirm as the moderator. Users submit questions in the Zoom console, while other users signal their interest by upvoting it.

The hour-long webinar consisted of Gautam answering questions selected by David Murray. In this post, I’ll highlight some of the themes addressed by Gautam and David.

The need for agile teams and rapid onboarding

For Gautam, synchronizing the activation of teams is critical. If one engineer is ready to start, but is blocked by other dependencies, then you have a valuable resource sitting idle and your project might be delayed right out of the gate.

According to Gautam, “For a team to have a positive impact, it’s necessary to establish a well-formed team very quickly. It’s a pretty bad experience to have people sitting by themselves in Copenhagen or Dublin waiting for other people to show up a couple of months later.”

PagerDuty has engineers in a number of offices around the world. “Whenever we open new offices, sometimes by acquisition, you need to have a fully-formed team there. If we build a new location organically, the expectation is that in week one or week two, we have a functional team there that we can give something to and get them excited about,” says Gautam.

The challenge is hiring and onboarding engineers, whether in the Bay Area or beyond. For this need, the right engineering partner can onboard engineers quickly. According to Gautam, “We use Lohika. One of the advantages there is that we can basically get to that point of building out a team very fast.”

In addition to activating teams quickly, it’s important to take advantage of budget and funding when you have it. Gautam has seen projects fail because of delays introduced in building and onboarding teams.

“It might not always be understood to people who think OK, we gave you the dollars, you can magically translate that into a team of fully functional software engineers who have great working relationships with each other,” says Gautam.

That process takes time and you often don’t have the option of waiting several months for it to come together. According to Gautam, “PagerDuty works with a third-party like Lohika to be able to ramp up teams quickly and on Day One, start moving on big initiatives.”

Gautam adds, “This shift to remote work has been a trend that was coming. It’s been accelerated by 5 or 10 years. I think that being able to work with a company like Lohika in a remote location is something that everyone is going to have to get used to.”

Balancing technical debt with product impact

One of the most upvoted questions focused on balancing technical debt with product impact. Specifically, how does Gautam think about paying down technical debt, compared to building new features or driving more product impact?

To start, Gautam identified two key roles:

  1. The voice of the customer (external)
  2. The voice of the engineering team (internal)

The voice of the customer represents the explicit and unmet needs of end users. According to Gautam, “Every engineering team should understand we are building the software for somebody. And if you don’t know who that somebody is, that leads to a lot of misalignments, confusion and, sometimes, wasted effort.”

Gautam suggests that a dedicated individual serves as the voice of the customer, understanding their needs and synthesizing those needs into things to be built. To complement the voice of the customer, another individual needs to represent the engineering side of the house. 

According to Gautam, “There should be someone who is the keeper of things our customers are not asking for. Someone who’s internally focused on the things we need to do, to make sure we deliver good quality service.”

You might think that these two roles are competing forces. After all, the question did ask how to balance the two. According to Gautam, this balancing act is a merging process that combines what customers are asking for with what internal needs should be addressed. 

“This process is art, not science. I don’t think it’s healthy to say the voice of the customer always wins. Or, that internal engineering needs always win. It has to be a collaboration. And this is really the secret sauce of most successful engineering teams. There’s a healthy collaboration between those two voices,” says Gautam.

How to minimize technical debt

Technical debt was a popular topic at this AMA. The next question was:

“How do you execute and deliver with speed without taking on technical debt?”

For Gautam, the answer is to minimize hand-offs between teams. When one team inherits code from another, the receiving team doesn’t understand the principles and isn’t aware of design considerations or trade-offs that were factored in. The first impulse of the receiving team, in fact., is to completely rewrite it.

Gautam referenced the famous quote from Joel Spolsky, “It’s harder to read code than to write it.” Related to minimizing hand-offs, Gautam discussed the concept of project-based vs. product-based approaches. In a project-based approach, finding the right engineers for a project is the focus. 

You’ll pull people off one project and put them on another with a more time-sensitive need. This leads to short-term building vs. long-term ownership. According to Gautam, “You’re moving complicated systems around between a lot of people. And that in and of itself is often the cause of technical debt.” Gautam much prefers a product-based approach, in which the same team stays together over the long term.

What metrics to use for measuring impact

Before jumping straight into metrics, Gautam stressed that it’s important to first have a well-formed team in place. A well-formed team is structured to successfully deliver software. According to Gautam, “You want a sufficient size to maintain a healthy on-call rotation, senior technical leadership, the voice of the customer and the voice of the internal systems.” 

If you don’t have a well-formed team, then there’s no point of measuring its impact. Instead, call a time-out, and go build a well-formed team–one that is ready to be measured. Once you’re ready, Gautam likes to measure impact by associating the team’s efforts with the organization’s business objectives.

This can be tricky, of course, since you can’t directly correlate an engineering team’s efforts to things like revenue, new customer wins or customer retention rates. As a proxy, Gautam looks to secondary metrics that can be associated with the performance of the team.

“What are the metrics we’re looking to move on? Reliability is one. SLA targets, engagement, user growth. Engagement metrics of features? We built something, how do we know if it’s actually getting used?” says Gautam. 

Cost can be another metric to measure, such as whether costs keep in line with growth.  According to Gautam, “There’s a grab bag of metrics that an engineering team can use to ask whether we’re supporting the higher-level business. You often will find that teams have to gravitate towards a subset of that grab bag. So infrastructure teams will obviously focus on quality, reliability, cost and speed of development.”