SPEAKER

Viraj Mody - Co-founder & CTO @ Common Room

Viraj is a co-founder of Common Room and leads engineering. Previously, Viraj led engineering organizations at Convoy and Dropbox, helping both companies scale their teams and products. Viraj was also a founding engineer at Audiogalaxy, where he worked alongside Tom, which was acquired by Dropbox.

SPEAKER

Tom Kleinpeter - Co-founder & Chief Architect @ Common Room

Tom is a founding engineer at Common Room. Previously, he was a Principal Engineer at Dropbox, and before that the CTO at Audiogalaxy and FolderShare, startups which sold to Dropbox and Microsoft, respectively. He’s also the co-host of The Downtime Project, a podcast that helps engineers learn from the Internet’s most notable outages.

Listen to the Downtime Project here: https://downtimeproject.com/

Viraj: "There is no scenario where one of us is successful without really understanding and empathizing with the other person's role. And I feel like as engineering leaders, if you're blind to challenges that the engineering team has, you're going to fail. And as a principal engineer, staff engineer, if you do not understand the challenges of managing people, you will fail. But if you can figure that out, this is like a pretty strong symbiotic relationship. And I think that's what I enjoy a lot about working with Tom."

Tom: I was thinking a few weeks ago about how to compare Viraj and I... and if you go to skiing with me, you're not going to have a lot of fun, but you're not going to get hurt. If you go skiing with Viraj you will not be bored. Like You are going to be doing slopes you are not comfortable with, and it's going to be an intense, memorable day. I love working with Viraj cause he is a great counterbalance to my caution... it's more fun with Viraj."

- Tom Kleinpeter & Viraj Mody

Show Notes

• Tom’s career path - from engineering leader to principal engineer (4:07)
• Viraj’s career path to become an engineering leader (8:54)
• How to reduce mental overhead by connecting with your team and leveraging candor & authenticity (14:27)
• How to shape the culture and execution of an engineering org at a new company (17:46)
• Early company building & values-defining conversations (22:33)
• How they decided to start a company together & Tom’s framework to assess joining a startup (28:27)
• Tom & Viraj’s strong opinions on building engineering organizations and culture (34:34)
• What Tom & Viraj admire most about working with each other (40:33)
• Takeaways (43:01)

Transcript

Tom's career path from engineering leader to principal engineer

Tom, I think to focus on you... you career path is really interesting because you've both phased in and out of engineering leadership as well as, being a principal IC... I was wondering if we could dive a little bit more into your career path... Can you share a little bit more about what that journey was like transitioning into engineering leadership, transitioning away, and getting deeper in the world of being a principal IC?

Tom Kleinpeter: Let's see where to start. So yeah, I did six years at startups, two years at Microsoft. Then I did another startup with Viraj. And most of the time I was doing that, I was an IC. Meaning I would occasionally have an intern or somebody would have to manage. Typically in the tech lead role, if we had multiple engineers working on something.

So I went to Dropbox in 2012, we moved down to San Francisco from Seattle. And I worked on the photos team for awhile. I was a part of shipping Carousel, which was Dropbox's big effort to get into photos then. you know the photos team was growing pretty rapidly and we needed a manager for the photo infrastructure team.

And I said, "Sure, I'll do that. Like this will be interesting. I haven't managed a big team before..." and before I knew it I was had like 15 people on my team. So it was, it was a pretty rapid introduction into the world of management.

And it was completely fascinating. I typically had spent most of my career extremely focused on what I was doing, like the code that I was writing, how much I was getting done, but I really hadn't looked around too much to how other people perform, what varying levels of output were.

And so when I became a manager and started paying a lot more attention to how a team works, you know, how different people are good at different things, people are clearly motivated by different things. It was really educational in terms of just helping me understand, like how you get more out of a team and how you make people happier. People respond to very different styles of management and that, that was, you know, sort of opaque to me before I was actually a manager.

But after doing that for awhile, Dropbox opened the Seattle office. And so I had the opportunity to move back up. And this was about the same time Dropbox was investing less in photos. So I just decided to switch back to being a staff engineer.

I probably could have stuck with management if I'd wanted to, but I had sort of looked around and I, at this point I had met other senior engineers and I had met executives and I just felt like I had more in common with the staff engineer types. You know, I Just, I felt a lot resonance and more in common with, you know, the, the technology and, and making those choices. Uh, It just seemed like I was better at it too. You know, I had a lot more ideas about how to make things faster and, you know, write, write stuff better than I did about, you know, growing an organization, things like that.

So I was very happy for my time as a manager at Dropbox, because it just gave me this great perspective that I think has made me a better engineer in multiple ways, but it was also fun to get back into the code.

And, one thing I found as a manager is you don't get to finish as many things as when you're an engineer. And for me, that that's a big part of my job satisfaction is, you know, landing the diff, turning it on, seeing the graph go up and to the right. And you know, a lot of times you might finish it one-on-one, but you're probably not going to solve all the person's problems, you know, in half an hour a week so...

Jerry Li: That's definitely one of the challenge for managing people. You don't see the result right away, even sometime years after.

Tom Kleinpeter: Now it is very satisfying when you do get results. Like when you get someone promoted after a long time it's, I think the payoff is greater, but it's definitely less frequent.

Jerry Li: Yep.

Tom Kleinpeter: After that, I spent a little time working on the performance team in Seattle when I got the opportunity to be the, I don't know if we had a real name for it back then, but you might call it the "Uber tech lead" or the tech lead for this big project in Dropbox for business, where I won't get into the boring details of it too much, but we had to make some really. Invasive changes to how ACL's worked Dropbox for the business product. And it was a pretty scary project.

Cause it was, you know, at the heart of Dropbox is business is keeping their customer's data safe, like that is, absolutely important. And that means keeping it secure, keeping it uncorrupted, and Dropbox does super well at that. But there was a lot of risks associated with that, with this project.

And it was also just very open-ended it wasn't exactly clear how it should work. And it was sort of exactly the kind of ambiguous problem that, that spanned, you know, lots of different, bits of code at the company. Cause this really touched every single product from, the clients to the mobile apps, to the web, to the, the core file system stuff.

So they felt that I would be a great person to tackle that because I had a lot of breadth at that point at Dropbox, I had worked all over the place. I knew people all over the company. So I took that on and that took about a year and a half to two years. We had teams in a couple different offices working on it, but but eventually we got that done.

And that was when I got promoted to principal after we shipped that safely.

Viraj's career path to become an engineering leader

Patrick Gallagher: Such a great story, because I'm just thinking now at this point in time, I'm a visual person. So I'm thinking about... in this story, we have you moving down this path, experimenting and learning a lot about what you like, what you don't like, and shaping your career around really interesting, different opportunities.

And then in parallel, we have Viraj... What were you doing this whole time? Cause you went further down the engineering leadership path. Can you give us more of the how and why in your transition in that pathway?

Viraj Mody: Yeah, I started at Dropbox just as any other engineer, just working on a bunch of stuff. This is weird story, by the way, connecting the dots between the Audiogalaxy piece and the Dropbox piece.

Two things happened in that first week that I'll never forget... one is, whenever Dropbox was deployed back then, this was still the early days the site used to go down for a bit. And I found it really comical because Audiogalaxy obviously wasn't nearly the same scale as Dropbox was where we had solved a lot of the problems that Dropbox was running into with their deployment. And I was like, "Yo, we can't figure this out? What's going on?"

But obviously they figured it out and it's like bigger than anything Audiogalaxy ever was.

The more interesting story though was we were talking to some of the, our new teammates and just like getting acquainted. Everybody was super nice and we were telling the story of Audiogalaxy. We described everything, you know, everything that Tom said we had built, "We built this and that!" and we demo the product and we showed them everything.

And then one of the engineers that like one of the managers is like, "So where's the rest of your team?" And I was like... "Ehhh? You know did you build all this shit? It can be just the two of you..."

" No, it was just the two of us..." And they literally, nobody believed us.

Again goes to show, you know, when you're, big company mindset... Not a big company, Dropbox, wasn't a big company... but I just like working in teams or two or three, having autonomy and independence, just results, in a very different velocity than even 10 people working together.

Anyway, so we start at Dropbox. I was just another engineer... it was also when Dropbox does this amazing hack week thing. So I had a pretty incredible project. My first hack week won some award and everything. So I was really enjoying myself as an engineer.

But then Dropbox was growing really quickly. They needed people to start doing manager stuff. For whatever reason, they tagged me as potentially being good at that. And I generally had seen enough bad managers, especially at Microsoft where my whole M.O. was "look, all I'm going to do is not be a bad manager. And that's probably good enough... if I can be good or not is secondary."

Being like a legit engineer makes it easy in some sense where at least you can have, straight conversations with engineers without any concerns. So it was pretty accidental.

It was also like that one year was extremely uncomfortable. The transition from IC to manager is super hard. You need to be able to flex all these muscles that you either didn't know you had, or, you have, but have not developed nearly as much. That dopamine hit thing that Tom mentioned around how you get gratification is completely different.

So for me it was pretty hard, but what kept me going was really understanding the concept of "Leverage" and I think this is applied to a lot of how I think about prioritization and how we build things, even at Commonroom. There are high leverage and low leverage activities. A good manager, is a force multiplier when it comes to leverage, right? If you have a team of six productive, happy engineers, they're producing six times the code that you could produce single-handedly right.

And it's also on the flip side, it really strong negative multiplier. If you do it wrong, you know, a team of six unhappy engineers can cause way more damage than one unhappy engineer.

And so if you start applying this thought and use that to understand and shape your head around how you have impact and what the result of your hard work is. Then it starts to make more sense. Maybe this is, you know, bullshit manager, textbook rationalization of how to get satisfaction from your job. But it's really the only explanation I have for why I was okay making that transition

Because I mean... I was still, and even now I think I'm like a pretty decent engineer. I can still write code. But I understand that if I can then instead go hire 10 people who can write code equal to a better than me... No engineering feat I can perform is going to have that level of impact. Right? And then you recursively apply this to larger organizations, bigger teams, products, et cetera. Okay.

So that's probably the way to bifrocate... and you know, there's many people who've tried it and realized, "Hey, look, I don't actually enjoy it." No harm going back to being an engineer, you're still going to be a damn good engineer."

Or there's some people who like, "Hey, look, I'm a good manager and I seem to be doing well, but I just you know, don't like doing it. I don't get gratification from it." That's okay. You can go back to being an IC.

But that was kind of the fork in the road for me. And then, and the fortunate thing was Dropbox kept growing. More things needed to get done, you know, orgs grow. They find people who can sort of scale with the organization.

That was kind of the second part of what a journey that started at Audiogalaxy that sort of culminated at Dropbox, Convoy, and then ultimately as Dan's Chief of Staff... was just this ability to be a breadth person instead of needing to be a depth person.

It was just easy for me to have a conversation with Sales people and with Marketing and with Engineers and with PMs and with Recruiting all in the same breath.

That's where it was really nice to make this transition as a foreground thing saying, "Hey, look, I could choose to be a really good engineer in one dimension, or I'm just going to become like a really well-rounded generalist on the leadership track.

How to reduce mental overhead by connecting with your team and leveraging candor & authenticity

Jerry Li: Viraj I remember when we first connected you were nominated for the engineering leadership award one of the things stood out to me is the authenticity and candor that connected really well with your team.

How do you leverage that? And what kind of suggestion do you have for other engineering leaders going through that kind of transitions?

Viraj Mody: I used to not be like that. There used to be a time when I used to think really hard about what I said to whom in what context, in what way. And I basically reached the realization... I don't remember exactly how I think somebody helped me...

Yeah, I don't know. I don't know how this happened, but somehow I reached the realization that the only person suffering from doing all of that is me. I have all this cognitive overload of "Hey, when I say this to a PM, I need to say this way. But when I say the same thing to an engineer, I need to say it another way. And then I said this story to this one person in a slightly different way."

It was just so much overhead for myself. Whereas look, I got better things to do with my life than worry about all this extra cognitive overload.

And generally my approach has been, be candid, just be straight and be okay having hard conversations. And then invariably you'll find situations where you did something incorrectly or you made a mistake own up to it and say, sorry. It's actually not too hard when you think about it, it's like yes say what's in your mind, say it nicely and own up to your mistakes when you make them and don't shy away from hard conversations if you can do that, your life is a little easier.

Jerry Li: or imagine that, they can simplify a lot of things...

Viraj Mody: Yeah, simplification is a big theme in just how I think of management, where you can do processes and systems and all sorts of tooling to make things complicated... To what end? You know, if you cannot explain why this is useful, get rid of it. It's the same thing with just personal interactions, right? Where if you cannot explain why a one-on-one is useful, don't have it. But if you're going to have it, might as well make it high quality instead of checking a box.

Jerry Li: I've seen conversation that went on for a long time in end. It actually it's just, why are doing that to me kind of thing. Was your intention behind that? So if people are open about it, just ask that directly then , it can be a really quick conversation.

Viraj Mody: Yeah, it's something that I try to bring to Commonroom and it takes awhile getting used to both ways, you know, if an engineer has never had a manager who's direct with them, or if, you know, a product manager's never worked with a counterpart on engineering who's just like straight and transparent about everything. It's a little jarring. It's like, "What do you mean this is not good?"

"I think well, I mean, it's not good..." uh, this is, you know, it's pretty unambiguous there.

Cause there's none of like, "what are you actually trying to say?"

" Well, I'm actually trying to say what I'm saying."

Once you cross that chasm, it's just so nice because it's easy, right? If I have something to say to Patrick, he never has to second guess what I'm saying... Again! Where this gets tough is when you're a jerk about it. And so hopefully I don't do that.

But it is a foreground thing where I try and make sure that the words I use are appropriate. But I'm not going to not say something just because I'm afraid to say it. Or because I feel like someone will be sad if they hear it. Yes. If you're sad, I will console you and I will help you get past your sadness, but you know, you gotta lay it out there.

The same thing with a recruiting approach previously, Right? We spoke a little bit about recruiting earlier. It's like yeah, what's the point in, you know, convincing you to make a decision that may not be the right decision for you.

How to shape culture and execution of an engineering org at a new company

Jerry Li: And now speaking of culture now we sort of transition to your new company on the high level. What kind of conscious effort both of you and Tom put together to shape the culture of new company? Especially around engineering and product?

Viraj Mody: I think how you build a company and how you build a product is very analogous. you know, you have a bunch of problems that you've got to solve. In one place you write code. In another place you go, hire people, build processes, build systems.

So a lot of what we do, our company values distill a lot of our worldview... And we're kind of fortunate in a pretty unique way in that we have co-founders who really compliment our strengths.

So we haven't spoken about them yet, but Linda and Francis are our co-founders. Linda has a business marketing, venture capital background. Francis is a designer product designer through and through. You know, Tom and I, you know, now. And so as a unit, we have a pretty unique set of strengths that compliment each other and cover each of those blind spots. It's not so hard to find, you know, two technical co-founders, who are looking for business persons to help, or, you know, non-technical people who like need engineers to come join the team. It's really nice to have a well-rounded group as founders, which has helped us distill our values.

And things around simplification or putting customers first or making sure that it's all about the team and not any individual. But then also having like high standards for what we think craftsmanship should be at a company.

We have a pretty opinionated set of values that we've distilled from the derived experiences that we all have. And then engineering has sort of its own set of principles. A lot of what we learned during our experiences at Audiogalaxy and Dropbox, right? Where velocity matters. Where customer trust matters. Where do we take shortcuts versus not. That's a lot of the culture.

And then one other thing that's pretty obvious when I say it, but not enough companies I think practice it is... building the muscle to recover quickly. You know, There are companies whose entire approach is "let's not make mistakes..."

There are parts of the product where that is absolutely imperative around customer trust. But then there are parts of the product where look, you know what, no matter how hard you try, there will be mistakes or, you'll solve a problem differently than it should have been. Build the muscle to go react and recover very quickly and then everything kind of falls into place.

So that's another thing where we've been trying to practice.

Tom Kleinpeter: One thing that's really important to me is that we let the engineers build things and make those mistakes like Viraj said. I guess backing up a step Viraj and I are very conscious of the fact that we're building a company a different way than we did at Audiogalaxy V2..

That was, is one thing, and this is a completely different thing. And the fact that they're both called startups is like a problem with that word. So, we are planning to build a legit company here. We're going to be a big engineering team in a year. Hopefully we're going to be an even bigger engineering team in two years.

We need to have a foundation of people that can build that Oregon. And that doesn't happen if I'm running around, specking everything out, and then people are just writing it in code. It happens if we have a deep bench of people that have, deep understanding of what something is, and they feel a lot of ownership over it because they designed it and they built it and it's their thing.

So just ownership and letting people really grow and build stuff on their own is really important to me as part of the culture we want to build here.

Viraj Mody: I think the complimentary aspect of what you asked Jerry, you asked about sort of the values and foundation of what we're building. The complimentary aspect of that is how we execute. And this is one where, it has to change with every evolution of the company. There is no one formula that works for a 5 person company that then also works for a 20 person company and a 50 person' company and so on.

But making sure that what you're optimizing for is preserved as you evolve your process. And it comes back to the values and the principles, right? When you're a 50 person team, how do you optimize for velocity still? You know, If you're doubling year over year and bringing in all these new people how do you still build fast while onboarding people and making sure they get productive?

These are not easy problems to solve. And again, this is where some of what we've learned over the last few years will help us prevent sort of the rookie mistakes. But like this is where innovation needs to happen. In some sense, on the organizational side of things or on the process side of things or execution side of things, right?

How do you set the right organizational structures? How do you minimize processes while it's still ensuring that things that are sacred do not get violated? How do you provide autonomy and independence and the accountability that comes with that? A lot of people will talk about providing autonomy and independence, but then fail to hold people accountable.

It's like, no, you can't have your cake and eat it too. Those are hard things you have to deal with. We'll deal with them.

Early company building and values-defining conversations

Patrick Gallagher: I wanted to dive in deeper to what you both are bringing up, because I feel like this early conversation of defining the type of organization you want to build and how you want to go about building it and creating culture, creating processes that really reflect the type of environment you want to create in the business that you want to build.

Intentionality that you both have shared of "We want to build this the way that we want to build it in a way that we think is going to create the best outcome and the best experience..."

It reminds me of some of the lessons that Max Levchin shared with us. He's co-founder PayPal's CEO and founder of Affirm shared about like the intentionality of having the conversation to define values early on.

I would love to know from your perspectives. What was the experience like to have those early company building conversations?

Was it like a formal... "we're going to have this conversation and talk about culture. We're going to talk about the engineering org and the vision for that?" Give us the environment in the story for how you had these conversations. And at what point did you introduce them into the business building experience?

Viraj Mody: Well, I think the thing that made it harder for Commonroom was we were, we are a pandemic company. So we were trying to have all these conversations without being in the same room with all the co-founders. Although we did... I feel like there were a couple of times when we spent time socially distanced outside, that were the beginning of some of this. But there's just another making a hard problem, harder type of situation that we had to deal with the pandemic.

Patrick Gallagher: Tom, you were about to jump in with something as well.

Tom Kleinpeter: Yeah. the pandemic definitely made things trickier. I think, you know, this is kind of a mixture of stuff we sat down and explicitly talked about, you know, like the four of us, let's make a list of values, let's debate them.

And this is again where intuition is nice because we've seen values, you know, where you, build a set of values and then you add 500 people to the org. And then Hmm... Let's look at those values again... Do they still sound as good? Are people still interpreting them correctly? And so we were able to bring a little of that to bear on our values.

But yeah, we were very intentional about setting that up. And, I expect that we'll revisit them continually as we grow. Things change quickly as companies grow and you, you want to be ahead of changes because it's easiest to fix stuff before you add a bunch of people. You know, we want to be on top of stuff and, trying to debug these things as they go. So we were intentional about that.

Some things we were less intentional about... sometimes Viraj or I'll just make a decision and go with it. Typically about, less broadly scope things, and we just kind of trust each other that that's the right call. And if we disagree, we will absolutely speak up with each other.

So... It's a mix. Cause I mean, you make a million decisions when you're starting a company like this. There's decisions up and down the stack, just spanning huge layers of abstraction. And you can't have explicit agreement about everything. There has to be a lot of trust. And that's one reason why I was so happy to do a startup with Viraj Cause I've known him for a long time. Complete trust. And that just makes everything work better.

Viraj Mody: This doesn't start when you sit down to write down your values. That is just a memorialization thing. This starts when you're having those conversations with your potential co-founders. Right? A lot of what we have written down as a value started when we met for the first and second time as a group and had all these discussions about, "Hey, what do you see happening here? How will we do this? How would we do that? How do you think about this thing? How do you think about that thing?"

Tom and I had the advantage of generally knowing where our heads are at, but Francis and Linda were new to us and we were new to them. And I almost feel like our values fell out of those conversations where the only reason all four of us are doing this thing together is because we built that trust and understanding during those conversations.

So if you're trying to do this after you've picked your co-founders, you're probably doing it too late? Part of a founder dating or whatever it's called nowadays is getting to the core of what makes you work as a team. And that needs to happen before you write it down.

How they decided to start a company together & Tom's framework to assess joining a startup

Patrick Gallagher: Speaking of that moment, because I think what's so special because now we're sort of reaching the part of the story where we're reaching the convergence, right? Where there's the decision that's been made, where we are co-founding this company together. And both of you talked about trust being a big part of that, both in the conversations with everybody else on the co-founding team, but also that being established prior with, both of you.

So I'd love to dive into the decision that you made, together, to be like, let's start this thing together. But before that, how did you arrive here first? So how did you maintain your relationship together throughout these different inflection points of your career? And then now make the decision... we want to start this company together?

Viraj Mody: Yeah. So the history here is that Tom stayed at Dropbox until we started Commonroom. But I took over two and a half year detour joining Convoy. Incidentally, Tom and I have never really worked together too much while we were at Dropbox. We were.. I think Carousel may have been about the closest we worked together?

But there were, we were generally in pretty distinct parts of the company. But obviously socially we're friends. So we kept in touch and it's kind of nice to have somebody you know, in another part of the organization. Cause they can be a good bouncing board to like get a read on what is going on and how things are going.

Anyways, so I was at Convoy, did the eng leadership thing there for the first year and a half, grew the team, rinse and repeat. But new mistakes and much faster and optimized this time around.

And then the last year I spent with the CEO of Convoy as his Chief of Staff. Mostly doing everything except for engineering things. And really that reignited the entrepreneurial spirit in me. It was always there, but this sort of brought it to the fore.

And then Tom and I had gone skiing early 2020 before everything locked down. And that was when we started throwing around some startup ideas and generally arrived at like things we cared about if we had to do another startup

... You know, it's nice to have a two hour drive where you're forced to have these conversations because otherwise you're just listening to boring radio...

So we generally a few things we cared about if we had to do another company together, what it would be, but more importantly, what it would not be, you know, it waslike music, nah... Photos? never... Travel, never... consumer software, I'd probably not..

So we knew what we didn't want to do. And then we spent a month or so bouncing around one idea that we were pretty excited about, but then the pandemic happened and we sorta just like instinctly, we parked it and went back to our lives. Cause... you remember the first month where everybody just went into a shell and even the idea of doing a startup then sounded insane.

But then along the way, I got introduced to Linda, we started talking and a lot of what Commonroom is trying to solve, lined up with the conversations that Tom and I had had around what we would or would not do.

And so I was like, "Hey look, yeah, if we're doing this, I want to make sure Tom and I work together..." because working with good people was pretty high up on the list of what we want to do next.

But yeah, that was kind of the TLDR. I don't know if there's anything I missed there Tom.

Tom Kleinpeter: No, I think that's a good background. We had an idea. but the pandemic kind of torpedoed that. But when Linda came along and pitched us on this, it just seemed like it really hit everything I was looking for.

The number one point there just being the team, if you do a startup, you're going to spend a lot of time with the people on the team. Like a lot. I mean, it is, it's not getting married, but it is really important that you are happy with everybody there. And, it just really clicked with Linda and Francis and going into this with Viraj is just amazing, given his experience and his background.

But it also hit a lot of other points on my, kind of test for do I want to do another startup?

It's so hard to evaluate startups. I mean, venture capitalists are not all successful. And even though they have the opportunity of being able to invest in multiple startups, engineers have the downside, they can only invest in one startup at a time. And they don't do it professionally.

So it's hard to pick the right startup. But I tried to come up with like a couple points that as I was thinking through this what should I be looking for just to systemize it a little bit and Commonroom just really seem to check all the boxes,

Number one, just being the team. Is it people that are just going to bring a ton to the table? And I was just super impressed with Linda and Francis and all my interactions with them,

But it also. It seemed like it would have a market size that was, big enough where it just would make it worth my while to spend time on it. It wasn't really a niche thing. And I could, I could imagine it being a large business.

I could also see how we could actually get people to use the product, One of the problems we had with Audio galaxy version two was, you know, it was a great product. It worked very well technically, but we just couldn't get enough people to use it. That's just the ultimate tragedy for me is to build something and, " they don't come..." So having an insertion point where we actually think we have a pretty credible path to getting people to use, it was great.

also, I'm just, I was just not going to do consumer software again. I was just done with that. It's too much of a lottery ticket. The payoffs can be huge, but it's much better to be on the side of things where you, you have a much deeper relationship with your customers.

So the last thing I was looking at was, you know, is this technically viable in a way that I really can contribute to it? Is it something where, you know, we need like a, computer graphic specialist or something like that, or, like a deep learning person... or, you know, just things that I don't have. I wouldn't want to found a startup where, "okay we'll get a startup. And then once we hire this person we'll be successful." I wanted to be the person that could make the startup successful.

And so Commonroom just really seemed to check all those boxes. But really it was just getting a chance to work with Viraj again, that that would have gotten me out to a lot of startups. I think.

Patrick Gallagher: What a great framework. cause I think you're right, most people don't get as many quote unquote "shots on goal" when they're the ones choosing to participate in the startup as an employee versus being able to invest in it. And just by the law of probability, that's a much harder space to be in...

Tom Kleinpeter: Yeah, absolutely.

Tom & Viraj's strong opinions on building engineering organizations and culture

Patrick Gallagher: One more topic I wanted to get into because you know, being in the spirit of nostalgia and in reflecting on both of your experiences and the different parallel tracks that you've been on to arrive at this moment.

You know, when you're looking back at all these experiences, and now here you are entering into this new company... What are some of those lessons that you're applying now, or some of the things that you've made a very powerful, conscious choice to do differently?

Viraj Mody: I guess I'll start... I think we spoke a lot about velocity, so I'll skip over that. There's a lot of things we're doing that are optimized for building something from zero to one quickly and making sure you sort of leap frog potential competitors.

But organizationally, this decisiveness thing I mentioned... empowering the team to be that. So making sure that the team really understands problems they're solving and have autonomy and independence on identifying the right solutions instead of a very top down approach of, " this is the problem and this is how you will solve it..."

"No."

You know, "Do you understand the problem?"

"Yes."

"If you don't, I will spend a lot of energy making sure you understand the problem."

And once you do, part of trusting your team is trusting them to arrive at the right conclusions. But also knowing that when they do have questions, they will bring it up to you without hesitancy.

So a lot of where we spend our time is, you know, making sure that people are autonomous and self-sufficient, but also when they need help, we set the right kind of environment that they can ask help without feeling like they're judged or without hesitating.

Cause the last thing I want is somebody banging their head on a keyboard when you know, Tom or I could have answered the question in two minutes. Like that doesn't help anybody. There are legit times when you do need to bang your head on a keyboard. When those don't need to happen, let's not make them happen.

Tom Kleinpeter: Yeah that's something I've seen over and over in my career that engineers come on a team is... Some people have a hard time with the right intuition about when to ask questions. And one big component of velocity is just how quickly you can get new people up to speed. And some of the best people I've worked with, When they don't know something, they will find the person that knows and ask them the right questions until they know as much as that person. And then basically keep asking questions until the person says, I don't know. I don't know. And then they remember it all and they move on.

Other people will, take the "it's all just code" a little bit too far and spend three days digging into something that someone could have answered in minutes.

And so I think we've come up with an idea that I like. And it seems to be working pretty well to deal with this problem, which is, you know, we're, remote company, we spend a lot of time in Slack, but we have a special emoji you put in to ask a question that indicates, "Hey, I'm still working on this problem. Like I'm not a slacker. I'm not giving up. I'm not dumb. I'm still working on it. But in case somebody else knows and they're looking at Slack and they can save me some time, just let me know."

And it, it sort of gives people the freedom to ask a question they might have otherwise spent 10 minutes poking into. People seem pretty happy with that. And I still don't think this problem is one we've completely solved. But, we're very conscious of stuff like that, which I would have just been completely... I wouldn't have noticed that kind of problem 10 or 15 years ago... but now we actually recognize it and we can be deliberate about saying, yeah, this is something we care about enough to work on. So let's build a system for this.

Viraj Mody: And then the derivative of working this way is that, the types of people who will thrive in an environment like is, are probably more experienced engineers versus your typical new grad or relatively junior engineer.

At some point, we're going to have to expand to make sure that they can be as successful as the more senior engineers. But for now this is another one of those short-term, trade-offs where, we would rather have mature senior... or like mature, experienced engineers on the team.

Just because, imposter syndrome is a real thing. I've suffered it, Tom suffered it, I suspect Patrick, Jerry y'all have had to deal with it too. And moving incredibly quickly means not falling into some of the traps that experience is the only teacher for.

So again, this is an opinionated choice that we're making that we're going to have to revisit sometime soon. Cause you know, I was a kid and people helped me out and I want to make sure I do that for other engineers. But for now, The way we've set things up it would be extremely hard for someone relatively inexperienced to come in and hit the ground running. So that's another one of those choices that is conscious. You know, the other thing that is probably broader than just Commonroom is understanding the dynamic of how someone like a Tom works with someone like me.

There is no scenario where one of us is successful without really understanding and empathizing with the other person's role. There's memes out there about, you know, pointy haired bosses and just like mean jerk principal engineers...

Like that stuff is real only because there isn't enough understanding and empathy for the challenges that the other faces. And I feel like as engineering leaders, if you're blind to challenges that the engineering team has, you're going to fail. And as a principal engineer, staff engineer, if you do not understand the challenges of managing people, you will fail.

But if you can figure that out, this is like a pretty strong symbiotic relationship. And I think that's what I enjoy a lot about working with Tom.

What Tom & Viraj admire most about working with each other

Patrick Gallagher: I know we're reaching our time and I wanted to ask one more question related to that last point Viraj for both of you.

What's so special about this conversation between the two of you is that we have 15 years of history and we're examining both two different engineering and engineering leadership career tracks in parallel. Which is now manifesting into a new co-founding relationship.

And we get to both examine the early factors that impact your career decisions, and also the executive level choices that you all are choosing to make to define your new business. So to see both of those things in parallel is a very special and really, really amazing experience. But with that, it's apparent that both of you have a ton of admiration and respect each other. And so I was just wondering to close, when you thought about the opportunity to work with each other, what were the things that you admire most about each other?

Tom Kleinpeter: I think Viraj and I compliment each other very well, I was thinking a few weeks ago about how to compare Viraj and I... and I we've been skiing together a fair number of times and that this sort of to make some kind of analogy or, maybe I quipped close to the point I want to make is...

if you go to skiing with me, you're not going to have a lot of fun, but you're not going to get hurt. If If you go skiing with Viraj you will not be bored. you are going to be doing slopes you are not comfortable with, and it's going to be an intense, memorable day.

So I, I love working with Viraj cause he is a great counterbalance to my caution you know, like I see all the problems. I know everything that's going to go wrong. My wife refers to me as the health and safety officer of the house, cause I know what temperature you have to cook everything to. And all that stuff.

But you know, Viraj likes to, to push and to go and so it sort of pulls me along, which, I think we ended up in a great place. And hopefully I can contribute some amount of safety to that, to the trip as well.

But it's more fun with Viraj.

Viraj Mody: If you want to go skiing, have a great time and not get hurt. You bring us both along!

No, that's actually a really good analogy. I did not think of that before. That's pretty good.

Basically mirroring that. It's really good to know that as you're pushing forward, the role of a engineering leader or any leader is really to push the team forward. Right? You don't lead by stepping back and asking people to march, like you lead the charge and inspire others to follow. But then you know that somebody's got your back. Which is important.

And I really like that about Tom, where, you know, it's like, "look, I may be trying to run a hundred miles an hour here, but like, if I'm going to step into a pile of poop like, I'm pretty sure somebody from the back's gonna yell and their voice is going to be Tom's.

Which is good. Right? I guess I got a less eloquent analogy there.

Patrick Gallagher: Tom and Viraj, what an incredible conversation and just what a special moment to reflect on and think about all of the experiences and stories that you've two shared together. And all of the things that have brought you here today. So just a big thank you for all of this. This is a ton of fun.

Viraj Mody: Yeah. Appreciate it.

Tom Kleinpeter: Yeah. Thanks for having us on! This was great!