How to Become an Exceptional Engineering Leaders - AMA with Gautam Prabhu, VP Engineering at PagerDuty

Gautam Prabhu, VP of engineering at PagerDuty, has been a startup person for a good portion of his 20-year career run. He began in the dot-com boom working at companies such as Fogdog and CenterRun and Sun Microsystems.

In 2005, he moved on to fulfill his goal of helping found a company, PowerReviews, where he evolved into and remained as vice president of engineering until 2011. He then joined Zendesk as the Director of Engineering before transitioning into Vice President of Engineering.

PagerDuty, where he currently works, took him outside of his comfort zone of starting small and watching the company grow, as they already had 500 employees when he joined.

From small to large scale, Gautam has experienced it all. He admits that his biggest period of growth came when he helped start PowerReviews, and then again as he made the transition from IC to manager.

Throughout the years, one of the topics he remains passionate about is what it takes to make a great engineering leader. At Plato, we had the honor of him joining in on a community AMA with our mentees. In this article, we’ll share the highlights of this AMA with you.

We would also like to thank Vladimir de Turckheim, a Node.js instrumentation engineer at Sqreen. Sqreen is a company that does application security management and we were happy to have Vlad’s participation in the community AMA as he challenged Gautam with applicable questions. A huge thank you to our mentees who attended the AMA as well. We were never short of great questions.

Ask-Me-Anything with PagerDuty's VP of Engineering: "Traits of Exceptional Engineering Leaders"

On accidentally becoming a manager at PowerReview

How does one go from an IC to VP of engineering?

Gautam explained that his story is a very common one for people who find themselves in management positions at startups. The reason he ended up doing it was that no one else wanted to.

On stepping into that role without experience:

I actually got the role of management completely without any training or direction. They said, “Just figure out what to do with this first person.” So I learned how to onboard someone. I learned how to basically figure out tasks that were useful for that person and how to help them. Then the second person showed up and they said, “Well, why don't you take the second person too?” So I kind of grew from there.

On later transitioning directly into VP of engineering:

It looks like a very abrupt transition, and in some ways it was, but it was also probably the most useful learning experience in my career. What I got was a transition that had a very low level of actual responsibility and a high level of theoretical responsibility, because as it grew I was responsible for everything. I was responsible for figuring out what the career ladder would look like. I was responsible for figuring out what our hiring and interview process should look like.

The fact of the matter was, there wasn't a lot for me to screw up. I had this really interesting experience where every decision to be made, I was making on my own, which wasn’t the case on day one. Due to this, I got an opportunity to grow this team slowly.

Reflecting on his learning, Gautam likened his growth at PowerReview to that of a vertical line. This is to say that he suddenly got a lot of responsibility and had to figure a lot of things out on his own. He identified this as a key element of the confidence he now has today:

If there's something that needs to be done, even if it's not something I have prior experience doing, I can make a good try at it. Some of the things I did well at and some of the things not so much. I was a terrible salesperson for example, but it gave me a lot of confidence to just try these things out, because what is the worst that can happen?</em></blockquote>

Management style

After hearing Gautam talk about his unique experience coming into management, we talked about how others learn and discover management, be it in a small company or structured organization.

Gautam shed light on what he sees as the biggest difference between how he was able to do things at his small company versus how he would advise someone to do so at a larger company.

At a very small company where there is no structure in place, a lot of different styles can work. So I was able to create something at PowerReviews where it just fit my natural personality about how I like to run things or what was important to me.

At larger companies, you still have to use your natural authentic style, but it's now within a different structure. It's within a place where there's already maybe a career ladder and cultural expectations. It's much more important that your style matches. You can sort of adapt your style to what's already there for the company and also make sure that you can be effective using that style.

He further clarifies with a personal example:

I think if you asked a lot of people at my first management job, I probably was a micromanager. That was probably my natural inclination as I love to get involved in the details. However, at Zendesk or PagerDuty that style of getting involved in the details is not workable.

It is therefore critical to be able to figure out what is actually important to you. Then, adapt this style to be successful in a different environment and engineering culture.

Vladimir posed the hypothetical situation that if you do not act quickly, people will have forced expectations about your management style. Gautam agreed, and added a few steps to follow to avoid this:

That’s why it is important to have a core set of beliefs that are philosophically important to you. When I came into Zendesk and PagerDuty those were the things that I was looking at. There were a few things which I saw as must-haves and wouldn’t compromise on.

The second step is to see if there are things that you need to change and figure out the right way in order to actually bring about that change. For that, you have to get a sense of the engineering culture.

The final step is the ‘How?’ and I think you need to be a bit more careful with it. This is where you need to go actually do that broad socialization of getting to know the company inside and outside of engineering to uncover what strategies seem like they would be most successful.

The aspect of what needs to change is where I think it is important to have a strong opinion. How to actually make those changes, though, should be approached with much more flexibility, taking your time to get to know what is the most socially acceptable way for these changes to actually get affected.

Being flexible with the “How” is not always clear cut. Gautam discussed how he had been able to make big decisions at Zendesk concerning hiring by understanding how things were being done and identifying new strategies suitable to the company’s culture.

When I first got to Zendesk, I think that they had a very good sense of who they wanted, but maybe the actual process of how they were getting there was not right. So one of the things I did was identify that we needed to improve the selection process.

We were getting some false positives and likewise some false negatives, so I knew we needed to drive the interview process towards a place where people were much more likely to be successful. I sat through lots of interviews. I looked at their debrief process. I looked at how they reach consensus and then I started to make some tweaks.

As I started to participate in this process, I voiced that I think we would get higher quality results if people went from saying what they found to saying whether they were an advocate for this person or a detractor of this person. So instead of just giving me a score, I wanted them to tell me what that score means. I wanted them to tell me whether it means a strong hire or no hire. I also wanted them to realize that they have some stake in this.

This subtle shift in the interview process allowed everyone to leave the room with a decision and a more effective strategy that was adaptable to the company. ‍

Traits of great engineering leaders and their teams

Gautam spoke about the difficulty of separating the question of, ‘Is this person a very good leader?’, from ‘Do they run a great team?’ He then follows that statement with three characteristics that he has found to be true if you want to build a good team.

The first is that the team is shipping. Is this team able to take requirements from the business at large and deliver on them predictably? They should essentially take some requirements and say in a responsible manner, “Here's how long we think it will take.” They have the ability to set their own timelines but then deliver on those timelines. So I think a great leader in engineering sits on top of a team that is delivering.

The second thing is the team should be happy. Maybe, happy isn’t the right word to use but engaged. Team members should be interested in the work that they're doing and understand how it translates to business value. Do they understand how it translates to personal career growth? Is the work that they're doing likely to keep them at the company versus to send them somewhere else? Are the interpersonal dynamics of the team making people likely to stay versus likely to leave? So I just call it happy. Good leaders should create happy teams.

The third thing is much more subtle, which is that they create flexible teams. Good leaders create teams that don't have single points of failure, for example. They also create teams that are able to incorporate new people quickly. The last sort of thing that flexible means to me is they create teams that are not purpose-built to do a single thing. Especially at startups, as things change very quickly and you might have to alter strategies.

If we go back to talking about great leaders, aside from the team aspect, here is a trait that Gautam sees as a hallmark to being a great leader:

Great leaders have a philosophy that they're able to articulate about what's important to them and that philosophy should be repeatable as they grow their structure. The philosophy should be something where it tells you how you should run a single team. It should tell you how you should start to run multiple teams and it should also tell you how you should start running multiple organizations. So the philosophy should be understandable and build on itself.‍

Philosophy

Gautam spoke about how a philosophy should be lumped together by the things you believe in, and at the end of the day, it should help to resolve ambiguity.

I think as you get higher and higher-level leadership jobs you are given tasks that are more and more ambiguous. At the highest levels of leadership, you're generally told to come in and make your own conclusions about what's important and then make everything better. You're not given a lot of direction.

He explained why having a strong philosophy on what you believe in, relating it to a north star, can help you evaluate a situation.

You should have a north star that you're looking for in terms of what you think a good team looks like. I think it should help you resolve ambiguity. It should help explain when you make decisions, why you’ve made those certain decisions.

In this way, when you tell people what you believe at a very high level, and then you make some low-level decisions, they should map accordingly. You should understand that this particular decision was made because of an overall belief of having clear lines of ownership or because we should be putting customer needs first or something similar to that. So, I think it's really to resolve ambiguity and to explain to the rest of the team how you're making your decisions.

Part of Gautam’s personal philosophy includes making big decisions out of constructive debates:

If there's a big decision that needs to be made, I think that you get the best quality decisions when you have a broad audience that participates in that debate. You encourage multiple points of view, sometimes opposing points of view, and you have to be okay with that. You have to be okay with a level of discomfort of knowing there's an important thing and there are people who feel very strongly on opposite poles. I think that you get the best decisions out of something that is a constructive debate and collaborative, but not consensus-driven.

Gautam shared that he has always posed his philosophy by asking, “Who is in charge of this decision?” Appointing someone who is in charge of the decision and really making sure that it’s known is critical.

That person's role now is to solicit as much input as they can in a responsible way and actually have that be as public as possible. We should have a public discussion about this and everyone who can contribute to this or should contribute, should feel like they've been given a voice, but ultimately one person will have to make a decision.

Hopefully, this process will have led us down a path where the decision is obvious. I think if you run that process correctly, you've reached an obvious decision because you've discussed it. Patterns start to emerge, consensus start to merge, but if not, we're going to break this jam by saying this person is ultimately responsible for making the decision.

Gautam demonstrated how he is applying this philosophy to a current experience at PagerDuty:

We are just putting in an architectural working group at PagerDuty right now. This is where we have some significant, high-level architecture decisions we want to make. We have an open public debate about it with a group of people who sort of facilitate and encourage that debate. Ultimately, if there's no consensus that emerges, that group has to make a final call.‍

Stepping away from tech

At a certain point in your career, as you transition into a leadership role, you’ll have to learn how to let go of the technical aspects of the job. This can be complicated. It is something that Gautam confessed he still struggles with but has learned to make his peace with.

I still want to be involved in a lot of details, and those include technical details, but it's not appropriate for me to do that anymore. One, because I'm on a management track where the dynamic is a little bit different, and two, because I've lost touch with the deep technical stuff that probably makes it appropriate for me to weigh in on that.

So, what I've done to make my peace with that is follow the advice that my first boss told me, and something which has stuck with me forever, which is, “The best engineers are lazy.”

What he meant by that was if someone comes to an engineer and says, “Here's something that needs to get done.”, the best ones will say, “Okay, how do I make sure that this person doesn't need to come back and ask me to do the same thing again?” Maybe there's a bug, so it's like, “Okay, well, I'm going to write a test, so this bug doesn't come back.”

So his point was not that all the best engineers don't want to do any work, but that their job is just to write code that basically answers questions forever.

Over the years, Gautam has adapted his management style to mimic that advice:

I tell people this pretty openly that when someone comes to me and asks me for something, my first question in the back of my head is, “How do I make sure that this question never comes back again?” Along with that, it’s “How do I make sure I never have to do this thing again that I had to do today?” I’m not saying I don't want to do it or I'm lazy, but rather, this is the role of management.

My realization is that this is what organizational structure is. The north star should be that you don't have to ask the question. It should be obvious and that's what a structure gives you. You already know who owns what without asking questions. If you don't, it's fine, but we should put something in place so that this question answers itself next time.

So that's how I've made my peace with it, in that I've decided that this job will be very similar for me to the IC track, in that my role is to create something which is no longer software, but a structure that answers all these questions that make me eventually be out of a job. Most engineers, for example, want to automate themselves out of the job they're doing so they can go onto the next thing, and that's how I view the management job as well.‍

Transitioning into management with the wrong idea

One common mistake Gautam sees during the transition into management is that candidates are being chosen based on if they are good technical decision-makers. Now more than ever, the industry is separating technical work from management work and Gautam was quick to explain why IC’s are getting caught up in the wrong idea of what a management role truly entails.

You see IC’s who transition to management and their goal is to be able to get their technical decisions pushed through. This is either because that's what they want to do or that’s what they think they need to do.

I think that's one end of the spectrum, where there are IC’s who basically don't realize that they're supposed to be winding down their technical involvement and empowering others to make those decisions. The other extreme being IC’s whose only goal now is to make this team happy and they're not actually able to drive accountability or delivery.‍

One-on-one’s

An AMA participant asked Gautam how he viewed the importance of bi-weekly one-on-one’s:

I think one on ones are incredibly important. Frankly, I find even that biweekly can be a little bit too slow. So I would say that my goal with everyone who I manage is to sit down with them once a week. I miss it occasionally, but I try to reschedule it and sometimes I can't even do that. However, my goal is a once a week cadence.

What if, however, the CEO wasn’t on board with this type of regularity due to excuses such as high costs and not focusing on the goals the company is currently trying to achieve?

In my experience, the things that come up in these one-on-one meetings are the things that are very important. I can tell if there are issues on people's minds which are having them think about, “Is this the right place for me to grow?” or “Is this the right company for me?”

If they end up leaving, part of the reason they left is that no one ever listened to them or actually sat down to hear their concerns. That will be a much bigger dent on productivity than the half an hour every two weeks you spend sitting down with these people. So I would push back pretty strongly and say, “In the short term this looks like it's not the most efficient use of time, but this is risk mitigation at a minimum.” This is risk mitigation to understand the facts on the ground about our people. People at the software company are the most important thing.

This is a cliche, but the Google CEO said, “99 percent of the value in this company leaves the building every day. If everyone just didn't come back tomorrow, this company is gone.” So, I really think that one-on-ones are not just a foundational, important thing for the relationship between a manager and the person they're managing, but frankly, between that IC and the company as a whole. If they don't feel like they're given that space to sort of express their feelings, concerns, and goals, and they move on, the replacement cost is immense.

Hiring

Gautam pinpointed his current challenge as recruiting, especially with the type of emphasis it currently has on defining the role of an engineering leader. That role is to create a structure where gaps can be identified and appropriately filled in a responsible timeframe for the business.

I think that what people have to realize is that there are some companies, you know, the big companies everyone knows, where recruiting is in full service to engineering. So you tell recruiting, “Here's what we need,” and you can expect that you will find the people that you want coming through your interview process. That's the exception. I think the more modern thing that's happening at most startups is recruiting and engineering needs are done as a partnership. A true partnership, where you have a shared goal of, “We need to hire this many people,” and “What are we going to do about it?” There's some division of responsibilities, but you have to treat it as a shared goal.

He illustrates this point with a prime example from his experience at PagerDuty and how he has been trying to grow in this challenging area:

Given the crazy hiring needs we have, that partnership is taking the form of a lot more personal outreach. We're hosting dinners for a small number of candidates. I meet people out of the office all the time. I'm doing a very slow building of relationships with people. That’s what it means for me personally.

The other thing is just starting to get the rest of the engineering organization aligned around that too. Knowing that this is a partnership and we are not able to just sit here and wait for candidates to come in through the recruiting pipeline. We need to, at minimum, work with recruiting to make that pipeline better, by partnering with them to better figure out the type of candidate we're looking for.

So it's really taking engineering and recruiting, that are side by side, and trying to smoosh them together and force them to be more like one team, rather than two separate teams that have dependencies on each other.‍

Impactful Relationships

Another audience member asked Gautam if he had a mentor or advisor who had been exceptionally impactful on his career. ‍

I had one mentor who was extremely impactful and he was a mentor by almost not being a mentor.‍

He expands on this by recounting a story that took place at the company he helped start: ‍

The CEO wanted me to do a sales call. I’d never done one before and I started making all these excuses. He, in turn, told me, “I have to leave the office to talk to a VC. There's no one else left in this office and so at 11 o'clock, you can do one of two things. You can continue to write your code and I'm sure it will be great,” and he was kind of being dismissive about it, “and we will have a zero percent chance of winning this customer, or you can put down your laptop for half an hour, call this phone number, try to get these people to buy our software, and then maybe, you have a two percent chance of winning this customer.”‍

He did two things there. The first thing he did was, obviously I'm a competitive person, and so I immediately thought, “I know I have more than a two percent chance. It's at least a 10 percent chance, so screw you.” The second thing was, he was trying to get me to understand the worst thing that could happen in trying something new. The worst thing that happens is they say no, which is what they were going to say if we don't get on the phone with them.‍

For this reason, he was just a really good mentor for me at the time because everything was ambiguous. Everyone had to do a little bit of everything and his point was, it's a small company, this is why you do a startup. Some of it's because you get to do things you wouldn't normally get to do, and the other thing is, don't be afraid to screw things up. You're going to screw things up. That's what happens to everyone, just don't be afraid of it. I don't even think he thinks he was being a mentor, but that message has basically informed the rest of my career.‍

A further extension of this question was if there was any one engineer that Gautam managed who had an impact on the way he saw management and engineering management. ‍

I was still in that mode where my view of management was much more focused on driving technical decisions. I had an engineer who was working for me who was probably the most talented engineer that I've worked with in my career and we still have a good relationship today. Even at the time, we had a good relationship, but ultimately, I think my tendency to go in and feel like I needed to have the final say on certain technical decisions or get very involved in them was what caused him to leave the company sooner than he should have.‍

I had some soul searching after that where I realized this is not in the long-term interest of me or the company or this person. The realization was that I was too micro-involved in things where I needed to let other people make their own decisions and mistakes. Also to realize they're going to make mistakes and probably the mistakes they make are not going to be as bad as the mistakes I was going to make. The fact that they made a mistake is not sufficient to say, “Okay, I should have stepped in more.”‍

That one was a very impactful thing for me. That realization alone helped me a lot. It was unfortunate that that's what it took to help me, but I've backed off significantly from there and I think it's led me to be able to run larger teams and basically have more credibility with larger teams.

---

‍ We are so pleased that Gautam was able to take the time out of his busy schedule to share his experiences with us. ‍ These were just some of the main points that we were able to touch on from what was an hour-long AMA of the incredible insights that Gautam shared with us. Please feel free to read the full transcript as well.