Leader Spotlight: Learning how to have hard conversations, with Mahesh Guruswamy

---

Mahesh Guruswamy is Chief Product and Technology Officer at Kickstarter, a global crowdfunding platform focused on creativity. He started his career as a software engineer at Vanguard before transitioning to Fidelity Investments, where he became Director of Architecture. Mahesh then worked at Homesite Insurance and Houghton Mifflin Harcourt before managing Amazon Alexa’s software development teams. Before his current role at Kickstarter, he held leadership positions at Smartsheet, Kajabi, and Mosaic.tech.

In our conversation, Mahesh talks about his experiences learning from and coaching others on how to have difficult conversations, as well as how this topic inspired him to write a book. He also shares how he promotes a culture of trust in his teams and stakeholders, such as being upfront about the “messiness” of current situations.

---

The importance of transparency

In addition to your role at Kickstarter, you’re also the author of a book, How To Deliver Bad News and Get Away With It. Could you talk a bit about your overall approach to communicating setbacks, or any kind of negative feedback that you have to give?

It really depends on the situation. That’s one of the reasons why I wrote the book — you can’t use the same playbook for every situation. There are times when you deliver bad news to stakeholders, customers, your boss, peers, or your team. There are nuances in each case that you need to be aware of, but the one common thing across all of these is transparency. In the end, everybody wants to know what’s going on. The commonality is that people are looking for transparency.

What’s your process to prepare for delivering bad news? Are there certain steps that you go through before you sit down and have that conversation?

For sure. My favorite example is when you have to deliver bad news to a customer when something blows up. In my past life, one of the value propositions of the systems that my teams were building and managing was that it could send marketing emails. This was a huge source of revenue for customers who were using the platform. For a day or two, all of our emails were blocked by the provider that we were using, so no marketing emails were going out.

In the beginning, I was getting frustrated that customers were not being patient. Then I realized that they were just looking for transparency. I process information by writing it down, so I wrote what had happened to date, what our hypothesis was, and our next steps. I shared what we comfortably could and provided a rough ETA.

The first update was not very rich. It said, “Hey, this is what’s happening, and this is the impact. We don’t know what’s causing it, and we don’t know when we’re going to be able to get the system back online.” I was expecting customers to be upset, and a small population was. The majority, however, said, “OK, great. Systems go down. We get it.” They thanked us for sharing what was going on publicly.

In the next update, we had better responses. We knew what was going on — things were getting blocked because some customers were sending spam. I said, “This is what’s happening. We’ll have to shut down some accounts because their actions are causing instability for the rest of the population base. We’re going to take some stronger actions.” Everybody responded well to that messaging. Eventually, we resolved the issue and got the emails flowing back again.

Speaking out to the public

In larger companies, especially those with big comms departments, sending out that message might require many levels of approval. What’s your view on that or how do you handle it?

It’s interesting because many companies, and specifically PR departments, often advise against jumping into a public forum and talking about what’s actually going on. I’m completely on the other side of it. I don’t ignore the PR department’s recommendations, but I’m very comfortable going out in public and talking things through.

In that public Facebook post, I wrote, “Every two hours I’ll give you an update. And if I’m sleeping, somebody else on my team will give you an update until this issue is solved.” I wanted to provide that level of response, because I understood this issue was causing a huge problem for our customers.

How did that situation change or reinforce your stance on communication?

After that incident, I’ve always emphasized being as transparent as possible — even radically transparent. For example, in one of my jobs, it looked like there might have been a data breach issue. At the mention of a data breach, the company went into full, high gear. They wanted to make sure they managed the message. I worked closely with them, but I said, “We have to tell people.” Rumors were already spreading inside the community and people thought we were choosing to remain silent. To avoid feeding those rumors, I knew it was best to hear directly from an exec who’s responsible for the situation.

Thankfully, it wasn’t a data breach. It turned out that a customer had shared their password with an admin, who then deleted a bunch of stuff without asking permission. This was good feedback for us because we realized we needed to introduce a new role in the software that could do all but a couple of things. Even in those situations, I was very comfortable being public about the incident and our investigation.

How has your method of delivering bad news impacted decision-making processes with your teams?

There are two things. One is that with the teams or leaders who report to me, anytime I bring something unpleasant to them, it sends a strong signal that I’m comfortable with not just delivering, but also receiving bad news. It actually de-stigmatizes that whole conversation. A lot of really good leaders over-index on wanting to please others — their bosses, teams, customers, etc. Oftentimes, they have a hard time saying, “No, sorry, this is not going to be ready when we thought it would.”

When I speak openly and say, “Sorry, I messed up. This is what happened. We can’t do this because of these reasons,” it sends a strong signal that I’m willing to be OK with conversations like that. That has increased our level of mutual trust. My team is very open in telling me what is and isn’t possible. It’s the same thing going upward, too. My executive peers and CEO know I’m not going to hide the messiness. I’ll always be upfront about it.

The correction of errors process

When you deliver news about something that hasn’t gone as well as you’d hoped, what is your process to mitigate that or prevent it from happening in the future?

Back at Amazon, we used a process called correction of errors (COE). We used it more in the context of system issues, but a similar process can be applied to any tough situation. For example, if your project got delayed, if you found out that the hire you made didn’t work out, or if you have to tell your team that you’re going back on the word that you gave them. I don’t ask my team to go through a COE on all issues, but definitely for operational ones. People also call these root cause analyses or postmortems.

Specifically, I like to dig into what we would do if we had to cut down the time it took for us to detect the issue. I also like doing the Five Whys. Even in business situations, I find that really helpful. It’s also important to do these things when the situation is fresh in your mind and not a lot of time has passed. It’s a good way to frame your thought process on what you could do better in the future.

Do you use this process for recruiting and retention as well? For example, if a new hire didn’t work out, would you use this method to determine if the issue was with skill set or culture fit?

Exactly. In one of my roles, I was the leader of a new company office. We hired a bunch of people and later had to let a few go. I reflected on that, trying to determine why those people were not a good fit with the team.

We concluded that our way of assessing culture fit was not accurate enough. People were going for likeability. One of the phrases someone used was, “Could you go have a beer with this person?” I think that’s completely flawed because you shouldn’t aim for likeability, you should aim for a good cultural add or fit for your team. We then removed all of those likeability culture fit questions and said, “OK, we want ownership. We want to be able to disagree and commit. We want this person to be able to be in the details.”

We crafted questions that assess those as a result. I’d ask questions like, “Tell me about a time when you made a mistake.” I’m genuinely looking for this person to tell me when they made a mistake. And if they say something like, “This was a mistake, but it wasn’t entirely my fault,” then that’s a signal that they’re not self-critical about what their process is. Same thing with being able to dig into the details.

Sharing insights with the next generation of leaders

Do you have any insights from a time when you had to deliver bad news, you went through your process — wrote everything down, decided how you were going to deliver it — and it was not received the way you thought it would be?

I’ve gotten slightly better at this because I’ve been doing it for so long. About a decade ago, I was responsible for a huge project. It was meant to be a promotion project for me to go from director to VP — my first executive role. Three months into it, I realized that we were not going to be able to deliver on the timelines we committed to the business.

I flew in to see the executive sponsor who was underwriting the project. The success of this project was very important to them. I was ready with my script, like “This is what happened, and this is my responsibility. I’ll work extra nights and weekends but we still need extra time to go deliver this.” The first meeting was terrible. Even after saying all that, the exec was not happy. They had trusted me to deliver the project on time.

Even though the first meeting went terribly, I provided constant updates over the next few months. I also invited them to fly over to my site and spend time with the team. I wanted to show them that the team was working hard. It’s easy to be upset at people you don’t interact with. By interacting with the team, they understood that everyone was committed to the project and putting in the hours.

Eventually, we delivered the project. It was late, but we delivered on the new timeline that we committed to. I thought that the exec was satisfied, but it did come in the way of my promotion, and I get the reasoning. This is something I coach my managers on too — don’t expect everybody to immediately react positively to your bad news, no matter how you frame it. In the end, nobody likes to hear bad news. It’s just not in our nature. But if you show people that you have their back, you have the work under control, and you’re able to give them the right updates to answer their questions, you’ll get them on your side.

Trust is hard to build and easy to break, and it just takes a while for people to rebuild their trust in you.

In addition to refining your own leadership skills, you’re also passionate about enabling the next generation of leaders. Could you talk about that?

It’s interesting because especially after I moved into an executive role, people were quick to make quick assumptions about me. I’m South Asian, so people thought I must be very academic and have done great in college. The reality is that I didn’t go to an Ivy League school, and I was a very average student.

My wife says that my superpower is being able to react to situations very quickly. In whatever new problem I have to tackle, I can recalibrate myself quickly and figure out what I need to do. Throughout college, all my professors told me that my programming skills were average. But at my first developer job, after grad school, my tech lead said, “I’ve never seen anybody code like this before.”

I didn’t follow the regular patterns, I just did whatever I thought was the easiest and fastest. I realized that the rules don’t apply anymore — at work, you can get creative if you want. Programming and coding are actually creative fields, which didn’t seem to be the case when I was in school.

Everything that I’ve learned about coding, product management, engineering management, and executive leadership, has been self-taught. This is why I have a lot of respect for people who take non-traditional paths into software engineering or tech in general. I’m a big fan of people who change careers. I want to enable those kinds of non-traditional career paths, which is why I wrote my book and share content on LinkedIn.

I don’t think the future generation of leaders will come out of traditional schools and academic routes. I think that what’s really important is the ability to build trust with peers, the practice of regularly asking for feedback, and making adjustments based on that.