An interview with Rishi Tripathy

We Chat with Rishi, Chief of Staff at On Deck

Today we chat with Rishi Tripathy, Chief of Staff at On Deck, a community where top talent come together to accelerate their ideas and careers. Rishi digs into his experience at Google, his lessons from spending an intensive summer working with Steve Schlafman, and how he's applying product thinking to the Chief of Staff function at On Deck.

Hey Rishi! Thanks for joining us. So you recently started a new role — congrats. Can you tell us about that?

Yeah! So I transitioned away from my product role [Product Manager at On Deck], which was more of a generalist role, into now being the Chief of Staff.

The way I think of it is, I’m still a Product Manager, but instead of a technology product, my product is the company — the team, the executive team, the board. That’s the framing I’ve given myself.

So the question is: what should the company be working on? What’s the right thing to build? How do we make sure everybody’s bought in? I'm using a lot of the similar skills that I’ve learned, having done product prior to this, but applied in a different and slightly more abstract context.

That’s cool. How’d you come to be involved with On Deck? What was your progression like to get to this point?
Whenever I talk about this part of my journey, I always start at the beginning of college. I was interested in biotech and basically, I wanted to cure cancer. I very quickly realized that wasn’t gonna happen. I started off doing biomedical engineering, and I did an internship at a medical robotics company. And I realized, healthcare is really slow. I was working on something that wasn’t going to be launched for years and years. I wanted to do something faster, so I transitioned into electrical and computer engineering.

I did a product engineering internship, which I though was interesting, but at the same time I didn’t feel like I had enough context on why I was building what I was building. That was the piece I was missing. I liked the technology, but I didn’t really know how it was being used, or why I was being paid to build it. So at that point I started to think that, based on my experience, I'm someone who needs to understand the context of what I’m building, and I want to move fast.

That drove me toward product development work. I'd heard about Google’s APM program — apparently a lot of people say good things about it. I applied, and there were some folks at Duke who had done it in the past and were generous to enough to help me out with preparing.

Nice. What was your time at Google like? And your journey from there?

I did the software development internship in summer 2019. I had an amazing experience. Really, it was great. There was a great community, I was learning a lot, sort of like a structured mentorship. I really got to understand how a big company works.

Ultimately, there were parts that didn’t 100% jibe with my own work style. Sometimes the company just felt so big, there were so many different groups with their own distinct goals. That creates almost a sense of competition, and I wondered, why do I feel like I’m working head on with people I should be collaborating with?

So I thought, if I were to come back, I’d like to be part of a smaller team that’s not working too broadly across all of Google. Working broadly like that is a skillset, of course. But I really wanted to learn how to build cool web and app products. So I accepted a return offer to Google, and they had me fill out a form to express my preferences for where I wanted to work. I told them that I really wanted to be part of a small team, just a few product engineers and a designer, maybe. And I wanted to be working toward solving a very specific problem for a very specific user group. Technology from the ground up. It didn’t need to be glamorous, I just wanted to figure out, “how do you build the right thing?”

Which, it turns out, is the core of product management.

I got the perfect team — they assigned me a small education team. And education is an interest of mine, which was great.

I was ready, I had signed the offer last fall. And then through the summer, I did some work in the startup scene with Steve Schlafman, an angel investor and venture capitalist based out of New York.

I worked with him doing sort of an apprenticeship. I thought I knew how the startup ecosystem worked beforehand, but I really didn’t understand it until I did that apprenticeship. I got to see how stuff really gets done. It was a really, really formative and incredible experience for me.

I publicly shared some of the work I was doing to support founders, and I ended up hearing from the On Deck team. They were like, “hey, we’re building something in the startup space, we’re helping founders, furthering education, bringing people together, creating community” — all of that was really interesting to me!

I was so blown away by the caliber of the team, the mission, the vision, the possibilities for growth — so I ended up signing the offer to join On Deck instead.

You mentioned that working with Steve taught you a number of things about the startup ecosystem that really surprised you. What were some of the lessons you learned?

I’m so grateful for that experience. He basically had me riding shotgun all summer, sitting in pitch meetings with founders, reviewing deals, doing diligence, learning how the entire capital network and founder ecosystem play together.

I was learning a lot about how companies start, and grow. And it was so inspiring. I realized that, although I was really excited for my development job at Google, I was nowhere near as excited as the founders we met with were about the things they were building.

I’d say I’m pretty entrepreneurial, and that experience really reinvigorated me. I thought, wow, that seems really cool, to be on a journey where you’re that excited about your work.

And that’s a big problem I see — so many people are unhappy with their work. Maybe I’m pontificating a little, but if we’re going to spend a third or more of our life on something, we might as well enjoy it.

At the same time, that summer I also learned that the hardest thing is meeting with founders who are really trying to further a mission, and having to say “sorry, we just don’t see it the same way.”

[You can read more about Rishi’s summer with Schlaf here, and his last-minute decision to join On Deck instead of Google here.]

You mentioned education — what is it about that space that interests you?

I’ve always been a really curious person, and I’m really grateful that I was raised in a family that encouraged that in me. I was never told that I was asking too many questions.

At the same time, school and college were often frustrating because I felt like I wasn’t learning what I wanted to. Plus, schools have no incentive to help their students succeed, beyond ensuring that they can get alumni donations. I just think education can be a lot better.

And I think that if we can show people what’s possible in the world, they can make much better informed decisions about how they want to spend their time, and what they want to work on. So education is really important.

The combination of education and entrepreneurship in particular is really valuable, because they’re positive. It’s not zero sum. If you’re educating people, you’re not creating scarcity and selling that. Instead, you’re almost creating something out of nothing. Best of all, once you receive an education, whether you paid for it or not, nobody can ever it take it away from you.

Love that framing! How does the product culture at On Deck differ from what you’ve seen or heard about elsewhere?

One thing that stands out is the culture of experimentation. We experiment with everything, from the literal software product that we’re building to support our communities, to the programming, to even the actual fellowships that we launch.

One of the first initiatives I led when I joined was the launch of On Deck Labs, which is our business unit that essentially tests out new fellowship ideas for communities that we can build around the identities of ambitious people. We’re really encouraged to get feedback from the external world, from our customers and users, and people who want to see us succeed, as well as our detractors and people who are skeptical of what we’re building.

Everybody is very customer-focused and mission-driven, which really impacts the way we interface with our community. I’ve really grown to believe that every function is a product function — you have a goal, you’re trying to design a process that works. Sure, you can say “well, everything is also engineering and everything is also design.” But I think there’s something to the idea that we want to choose a set of outcomes, and we’re going to do what it takes to get there.

So how do you view your new role through that lens? What are things you can do when running a staff function that people normally don’t think of?

The Chief of Staff function is kind of unique, because the job is essentially to supercharge the company, the leadership team and the board to make sure we’re working on the right things.

And what you’re building is a company and a culture, and a leadership team that is empowered to do their best work. I think there are a lot of interesting opportunities in a remote environment in particular, working with a distributed team, where we have access to so many different tools.

You're also thinking about how to manage constraints. Constraints around a product team might be timeline or engineering resources, for example. Whereas constraints I’m looking at are, “where is people’s attention divided? What do people care about internally? How can I collect qualitative data and look at metrics, and figure out ways for us to work at an extremely high bandwidth, but independently?”

And just like in a product function, your goal is to align people. In a distributed, remote team, what’s important is making sure that everybody has the shared context, that they’re able to do their best work and make good decisions. We don’t need everything coming top-down from the CEO. So how do we use Slack and Notion and Docs and the Drive to create shared context on goals and priorities? That’s the framework I’m attempting to build out.

It’s all about sharing context, as opposed to control.

Long story short, as a PM my job might be to unblock engineers and designers and marketers and big decision-makers, so it’s not that different. I still identify as a PM in this role.

On Deck started off in-person, correct, and has now transitioned to remote?

Yeah, it was a dinner series for three years, and then an in-person cohort for ODF1 and ODF2, and now we’ve transitioned to completely remote. That has enabled a lot of interesting things for us.

Number one is the power of technology — we’re now accessible to people around the world. Before, people were coming from SF, New York, etc. But now we have fellows from all over the world. It brings an incredible amount of diversity and perspective to the community, which just makes everything better.

We’ve also started to build tools to support the community at a global scale. On top of that, the team has essentially tripled in size since I’ve been here, and that’s way harder to achieve in person. In a way, remote has been a sort of forcing function that requires us to get our shit together and make sure we’re all growing in the same direction.

Do you have any practices that you think are unique to your team that are really useful when working remotely?

Yes. I’d say our internal community Slacks are the best Slack workspaces I’ve ever been in. There are a lot of best practices and tips and tricks we’ve learned over time. I think the average team, from what I’ve observed, uses something like 20-25% of the features of Slack or Zoom on a day-to-day basis. Whereas we’re always pushing the envelope. When we get the release notes from Zoom or Notion, we’re always like “wow, these features now exist! How can we use them?” So our team is always looking for ways to push the envelope.

Another thing we do is try to prototype everything in no-code first. So some combination of Slack, Airtable, Webflow, whatever — that way we can spin up prototypes really quickly, and see if a concept resonates with our fellows. And once we start to outgrow those tools, we’ll build it into software. That allows us to have a happy product team, and happy engineers, because we’ve already validated everything and we know it has product market fit. We’re clear on what the pain points are, we’ve got feedback — that approach really helps us out.

That’s awesome. Have you read anything recently that you’ve found super helpful?

I just stress-read The Making of a Manager, by Julie Zhuo. I have a couple of interns I’m now working with, who are amazing. Basically I graduated from college and now I’m managing people, so I'm on a steep learning curve and that was really helpful for me.

Do you have any favorite apps or products right now?

I just started using Sunsama as a collaborative product, working with our CEO, and I’m finding it really useful. It helps us to understand what’s on our plate, where we should be focusing, how we make the most of our days, etc.

Thanks so much, Rishi!

For more from Rishi, check out his website or sign up for his newsletter. And if you wanna get our Product Thinking interviews in your inbox, sign up for our monthly newsletter below.