Teach Your Engineers To Play Risk with Rahul Garg of Pypestream

Transcript

Ledge: Hey, welcome to the Gun.io Frontier Podcast. My name is Ledge. I’m your host. Today, my guest is Rahul Garg. He’s the SVP of Engineering & Product Management at Pypestream, a customer engagement solution that helps enterprises establish direct to consumer relationships using two-way AI-backed persistent private messaging connections.

Before that, he worked on strategic projects at IBM specifically on the team that was originally tasked with commercializing Watson after the famous computer first won on Jeopardy.

Rahul earned his MBA from Harvard and his undergrad from UMass.

Rahul, thanks for joining us today.

Rahul: It’s great to be here.

David: Awesome! Off-mic, you and I were talking about your experience having moved sort of from engineering to product and strategy in business and then kind a little bit halfway back to engineering.

One of the topics that I found come up in the trends lately is really encapsulated by that because it’s the convergence of engineering and product. You just simply can’t ignore product anymore as an engineer; and, likewise, as a product manager, you can’t ignore engineering. These things are just one and the same now.

Do you have some initial thoughts about that before I dive into a couple of questions?

Rahul: Yes. I think you’re seeing it more and more. I remember back in the day, product managers used to say, “I like salami but I don’t care how it’s made.”

I think the role has changed where, as a product manager, you can’t really plan anything without knowing how it’s going to get there. And you can’t be as high level as you used to be especially in software because there are so many gotchas that you have to plan for.

Having that background, making sure you understand how that all works really helps drive a good product decision making. And I think that’s why you’re seeing a lot more of that convergence.

Back in the day as a product manager, you didn’t have any resources so you can make a plan as much as you want but when those resources get yanked out from under you, you’re left there with just a piece of paper that says “roadmap” but not delivered on.

Right now, you’re held accountable for delivering your roadmap because you have all those resources.

David: Right! Do you look at it as “product controls engineering” or “engineering controls product” or is it just like one new massive function?

Rahul: I think it’s a synergy. I don’t want to say either one controls each other. I don’t see my teams that way. I see them more as “product helps that vision of strategy; engineering helps get it out the door” but they also help refine that vision and strategy to drive a better product.

David: Off-mic, you and I were talking originally how there’s a difference in how you manage the different types of people ─ maybe the personality types and the experience types ─ that go along with engineering and product.

What are the key differences there and what do you recommend for people who are starting to get into that kind of disposition where they really want to lead those two functions?

Rahul: On a product perspective, it’s always been the strategical “This is what we’re going to do. Go do it. Go get the data.” Everything is numbers-driven. You want to see how people are using things and drive that to your value add.

With engineering, it’s a little bit different because you’re working with resources that are very intelligent but they’re motivated differently. They’re motivated by having need or building something amazing. They’re not motivated by Feature A, Feature B being delivered to the market. They are motivated by “The product I’m building has to drive value to someone. I want to believe in that vision.”

So a lot of engineering is motivation as to the mission of the product versus a lot of product management is really strategy around the product.

Those resources are different, too. I spend a lot of time explaining some of the decisions you make to the engineering team as well as taking feedback and having a better understanding of what they think would make for things in terms of the product being better.

I have to tell some engineers, “Put on a customer hat. Think of it from their perspective. Do you, as a customer, really plan to do Steps 1 through 9 just to get something integrated?”

You, as a customer, would want it to be very simple. And it’s stepping them back from “Oh, you just use this” to thinking about it from a product perspective or an end-user perspective.

David: I imagine there’s probably a new level of business empathy that has to come to engineering.

When I was a coder, we were all in the basement and we liked it that way. It was dark and you could just stare at a screen and write a bunch of code but you’d never touch the customer. You’d definitely never touch the business user. You forget about budgets or any of those things. You just had a deadline and a bunch of code to write.

And I still think that’s even close to reality anymore.

Rahul: There are a lot of times when I’m sitting with a client, a client success team, and a client team that bought the product on the other end. And they’re struggling together with “We can’t make it work” and there’s a point where you just have to say, “We need an engineer to engineer a call” because it’s something simple that two engineers could solve but two business people can’t figure out what’s missing in integration that two engineers can solve very quickly.

Now, I have engineers talking to other clients and it’s a completely different world. It’s so different that they are now moving from the dark basement to come up and they can’t say everything that they’re thinking like “Oh, this doesn’t work because you misconfigured it on your end.”

You have to be more “Hey, I think there’s an error in your configuration.” It’s a whole new way of interacting with customers.

My engineers will call me “stupid” and I’m okay with it. I’ll take it with a grain of salt and continue on. But they can’t say that to somebody who pays them in terms of keeping our company alive.

Rahul: It’s teaching them the balance. And so, we spend a lot of time or, at least, when I do those calls with the engineering team to say, “Alright, guys, first, we need to listen.”

What our engineers get into is solutioning right away without listening to the actual problem. Once they listen to it, they come up with probably a solution that’s two to three times better.

So what I try to get them to do is say, “Don’t say anything. Let the customer speak for the first ten to fifteen minutes as to what the problem is that they need help on.”

And that’s just the teaching moment with engineering teams. I think you’ll see that more and more with engineers where they have to learn that business skill of communication.

David: I agree completely. And, to be fair to our engineering colleagues, I also think the there’s a fair amount of education that happens to the business user and especially to the business planner and budgeter that engineering is really a creative discipline and that you, sometimes, can’t predict all the things that are going to happen.

And we’ve intentionally gotten really smart problem-solving individuals not because we’re problem free but because we’re problem rich; and, therefore, we don’t have full predictive capacity into the things we’re going to hit. We just know we have the rich backing of skills and education and smarts to get those things done.

Rahul: I fully agree with that. I’ve seen engineers who are really good at problem solving but they struggle with communicating. The skill that I’m working on teaching engineers is communication so that that skill in problem solving flourishes and that’s really what is going to drive, at least, our business as a product team merged together.

What I try to explain to all my engineers across all of our teams is that we’re one person. Your customer, on the other end, sees you as one whether you’re a customer success person, a product person, or an engineer.

If the product doesn’t work, they see it as “Pypestream not working.” They don’t see it as “Oh, the that we built doesn’t work because the implementations person didn’t build it right.”

They see it as one problem and we have to all to solve it.

So that’s why we have to break down the silos and communicate together well. We can’t just be an engineering team that talks to each other.

David: Absolutely! Having been on the business engineering side so much, how do you explain to maybe non-technical business budgeting and planning on the variability and the risk management?

“Why can’t you tell me how long it’s going to take and how much it’s going to cost?”

Rahul: If I could tell you how long it takes and what it will cost accurately, I’d be a very rich person.

The way I explain it to them is that software is not easy to make because if it were, everyone would do it. It’s not simple to do. There are a lot of variables. There could something like a semi-colon that cuts you off by three days.

When you think about it from a logical perspective or if you play a game like Risk, there are so many unexpected routes that can come about.

And that’s similar to software. There are so many unexpected routes that happen as you’re designing something. You’d always find a bug.

If you’re someone who tells me that software doesn’t have a bug or the software you use doesn’t have a bug and the software you write doesn’t have a bug, I’m pretty sure you’re lying.

Everything has bugs because there are so many different routes to get from Point A to Point B. It’s just uncontrollable. And that’s how I try to explain it to them. It’s like the game of Risk.

You won’t even expect what’s coming at your blind side, sometimes, whether an engineer had to leave for the day or got sick to an engineer who’s working on something and the complexity raised three X because they realized there’s a security hole in it.

David: And, of course, you don’t want us to launch the security hole because that’s high risk. However, risks always manifest as cost somewhere.

Rahul: As a manager, you spend your time to understand the risks. If you launch something, how long will take for somebody to find that risk and can you patch it before that?

That’s why I say that everything we do takes a little bit longer than the ideal.

David: Right ─ which always makes to say, “Why don’t you just double or triple it?” But you can’t do that either.

Rahul: And then, you’re not going to be able to meet market demands. The other thing we do is, as we’re launching products, “Can we break it into very small pieces and launch small pieces very quickly to show that we’re making progress right away versus one big thing?”

A big bang is great but it doesn’t show a lot of progress ─ if you do four of those a year versus twelve.

David: Right. What’s the actual teamwork involved in breaking down a large solution into many more predictable solutions?

Rahul: I think it starts with, first, understanding the problem that you’re trying to solve, the pieces it’s going to touch, doing architectural reviews, and then continuing down that route to break it down.

It’s not easy because you can do an architectural review and miss something or somebody expects something else.

What we’ve started trying to do is make sure everything is written so we all leave a meeting with the same notes; and then, at the end of the notes, we’d published meeting notes and say, “Hey, everyone sign off from these notes by the end of the day or by the end of the week so that we know everyone’s read through it again.”

We find that you’ll see people asking more questions, sometimes. And that really helps because they’re like, “Oh, I missed that.”

You miss a lot over the telephone. And with a distributed team, sometimes, there’s something that may happen on the side here or there with two people in a different room. It’s really trying to get that all into the same place.

That’s why we find that notes are best. And those who are notetakers miss some notes as well. That’s why if other people go in, update it, and everyone has reviewed it, we’re good to go.

So when we do launches which is where you don’t want to miss anything, we do checklists. We do a review a couple of days before the launch to make sure everyone’s okay, then we go through our approval process and then we push forward.

We try to do a dry run on a platform that’s not touched by customers to make sure we hit all the gotchas and approve the checklist. And during a launch, we have a coordinator who helps lock teams through it.

Whether the coordinator is a product person or an engineering person, it doesn’t matter. They’re really just set at coordinating the launch together.

David: Last question: In experience, what’s the right balance of managers to doers?

Rahul: I don’t think there’s a number ─ managers to doers. It’s really having a lot of doers who have strong leadership. You don’t want a lot of doers who can do things that can self-manage themselves. You want a lot of doers who can self-manage and a couple of great leaders to help bring that out.

Managing a team of a hundred or sixteen hundred all depends on making sure you have the right people helping and leading that team.

I can only trust my direct reports to do the best job. I have to trust them that they can do the best job with their direct reports.

There’s no magic number. You could have five hundred people on your team who are all doing quality assurance testing or you could have five engineers who are just doing platform development.

David: Awesome! Thanks, Rahul, for the insights. I really appreciate it.

Rahul: No problem.

David: Any final words about Pypestream or anything about yourself that you’d like to leave the audience with?

Rahul: Watch out for these product officer roles coming about. As I tell my engineering team, “I know you, guys, think I’m just a product manager but I did do this before. I do have an idea as to how to do it.”

David: Absolutely, respect across the aisle from product to engineering and back!

We appreciate your insights. This is awesome. Thanks so much for joining us and we’ll do it again sometime.

Rahul: Yes. Thanks for having me. Talk again soon. Bye!