SPEAKER

Viraj Mody - Co-founder & CTO

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

Tom 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: "One of my jobs as an eng leader is to be decisive. It's easier to build something, fail at it and go fix it... than it is to just spin round and round and not really make progress. There's going to be some places where you have to weigh trade-offs. Make that call stand behind it. And if it was wrong, you own it. That's okay..."

Tom: Sometimes I think that's one of the defining features that Principal Level IC and engineering leadership really have in common is... one of your jobs is to use your intuition to make decisions quickly. But that's, the job! Is to make decisions that are mostly correct in low information environments... and to have built structures, to let you recover in the inevitable places where it is the wrong decision...

<cite>- Tom Kleinpeter & Viraj Mody</cite>

Check out CrossLead's Team Leader Program!

The CrossLead Team Leader Program is designed for frontline managers of high performing teams to help them succeed in any environment. David and the CrossLead team are longtime friends of our community, our team applies the principles from “Team of Teams” across our organization, and know it’s impact first hand.

The Team Leader Program kicks off April 13th! Sign up with code "ELC" for $250 off

Show Notes

• The Beginning - How Tom & Viraj first met over 15 years ago (3:48)
• The Early Days - Microsoft, Tom’s start-up jump to Audiogalaxy, and why Viraj followed (8:55)
• Lessons in hiring and assessing risk at an early stage startup (15:07)
• ”Yo, I don’t even know how to use a Mac…” + other strong opinions & mantras from their early start up experience (24:07)
• What happens when you remove decision-making delays & non-coding time from an engineer’s schedule (29:03)
• What principal IC’s & engineering leaders have in common... “Your job is to be decisive!” (34:08)
• Takeaways (39:17)

Transcript

How Tom & Viraj first met over 15 years ago

Patrick Gallagher: Thank you both so much for joining us on the show and sharing your stories with us. We're really excited to dive into it with you.

Viraj Mody: Yeah, thanks for having us. I'm pretty excited to do this. We've known each other for awhile, so this will be fun.

Tom Kleinpeter: Yeah, I'm definitely looking forward to this

Patrick Gallagher: So I think that brings up a great point Viraj because the theme for this conversation, in some ways it's sort of nostalgia and reflection and application, because currently right now I'm in the final hours of helping my dad move out of my child at home. And so naturally I'm coming into this with an incredible amount of nostalgia going through all my own personal belongings and just reflecting on the things that have shaped me, thinking about all the memories, the stories, and the things that have contributed to my life.

But that's perfect because for our conversation together, we, in a sense are sort of here to do the same thing for you two. Where after working together on and off for 15 years and more. You both are transitioning to a really exciting new phase of your careers co-founding a company together.

And so we're going to have a lot of fun, reflecting on some different stories, career inflection points, and critical lessons about engineering leadership along both of your journeys.

To begin, the best place may be to set the scene for where you all are at right now. So bring us into your world. What are you up to right now?

Tom Kleinpeter: Viraj and I are starting a company. Well, I guess we already started it. So now we're well into the really fun part, which is building the company.

Viraj is CTO. I am something? Chief architect? I'm not exactly sure sometimes, but we met two other founders, our co-founders Linda and Francis last summer

Viraj Mody: During the episode, I'm sure we'll get into how Tom and I sort of play off each other's strengths and I'm really excited about working with Tom to build this company, because it gives us a pretty unique edge over doing it individually without each other.

Tom Kleinpeter: Absolutely

Patrick Gallagher: think what's so interesting is that, this didn't just happen magically overnight, both of you have a long history working on a lot of different things together. If we could rewind a little bit... How did you both first meet? what were the early moments of Tom and Viraj?

Tom Kleinpeter: I think we actually first met when I interviewed Viraj on our team at Microsoft. I was working on this product called Live Mesh at Microsoft in 2006? 2007?

Patrick Gallagher: How did you arrive to Microsoft and what was the first moment where you met Viraj, maybe what you thought about him. How'd you two connect.

Tom Kleinpeter: I had done two startups before Microsoft. I went to school in Austin at at the University of Texas. And, I did a startup while I was still in school. I called Audiogalaxy, we'll call it Audiogalaxy version one. that was like a file sharing music trading website. That was pretty insanely popular at the time. It was all kinds of lessons learned building that, but eventually we had some legal problems.

And we, we started another startup called FolderShare that was again, a P2P side, but this time for keeping your files in sync. Sort of, Dropbox-esque but before AWS or anything like that.

So after a couple of years of doing that, Microsoft bought the company and we all moved up to Seattle. And I worked on that for a little while before the team got folded into this thing, Ray Ozzie had started called Live Mesh. That was a really interesting team. It was composed of a bunch of just really high performing Microsoft people and it was growing very rapidly. And so I think we were only hiring people from internal, like internal transfers that were also doing really well.

And so I was doing interview loops. I interviewed Viraj and was just amazed. Like this guy is super smart. We got to get him. This is going to be huge asset to the team. And so I wish I remembered the question that I asked you. Probably some search thing. I don't remember the question I was asking back then, but it was a great interview and yeah, obviously we hired him and everything went on from there.

Patrick Gallagher: Viraj. What was your take on the other side of that story?

Viraj Mody: Yeah, this is a definitely a nostalgia, Patrick, so you teed it up Well, so I also went to UT Austin, incidentally. Did not know Tom there. And I joined some Windows Operating System team as a new grad.

There's a whole story here about how when I graduated, I had an offer from Google and Microsoft, and I made the mistake of asking my parents for advice. And they were like, "Bill Gates, Microsoft! What kind of question is this? What the hell is Google?"

This is pre IPO, Google. I'm like, "Ah... I guess I got to go to Microsoft. So..."

That's a whole other story for another time... but that was a good lesson in never ask your parents for career advice in this industry again.

So three years into that team, it was pretty boring. And I'd heard about this secret team that Ray Ozzie had put together. Ray Ozzie back then was sort of Bill Gates' successor. CTO, or something at Microsoft, something like that.

It was a super secretive team. You couldn't even get into their space with a Microsoft badge. You need a special access. And only like extremely senior people... And I was like three years out of school. So I was a kid.

I remember emailing folks on the team saying, "Hey, I want to join you guys." And they basically said, "yeah, whatever, get lost..."

I was like way too junior. I was pretty persistent and I said, "Hey, let me just buy you a coffee. Let me just meet!"

And so I walked in and had a meeting with this person and he literally like had me do an interview loop that day. And I guess I did well, but it was the first time in my life where I had the feeling of all I have to do is not drown. And I will be so ridiculously successful because everyone else there, like Tom said was just hand-picked from across Microsoft. Pretty special team.

The Early Days - Microsoft, Tom’s start-up jump to Audiogalaxy, and why Viraj followed

Patrick Gallagher: What a cool moment to think about it. Cause the meta- narrative, of this whole story is sort of looking at the early formation of personal relationships and how then those impact opportunities, 15 years down the road. And I think that one moment has now sort of led to what's going on with you all in starting the company together now

it's kind of wild to think about that 15 years later that, that conversation and connecting in that moment and working on those projects together has sort of led to this moment.

So to dive in a little bit deeper into some of the, early times in Microsoft together... what was your working relationship like?

Viraj Mody: We were working on in the high level, it was like a pub sub system for this thing that was called Live Mash. Tom was involved in a lot of things. I think I had started looking at one or two components of that system and then building sort of the whole full stack from client all the way through server.

Tom Kleinpeter: Yeah, Live Mesh was building something pretty ambitious, really from very little to start with. It was going to do file sync. It was going to do remote desktop. It was going to do quite a few things, but one of the core components it was going to need is clients holding a connection open to the server and getting notified when something happened.

Or that something was very broadly defined. It could be a whole bunch of different things. And so I was working a lot on this server trying to build something that would scale and would be pretty general purpose. And I think you were working on the client Viraj?

Viraj Mody: Yeah I was working on the more thing. The consumer of what you had built but then also

Tom Kleinpeter: Oh, that's right.

Viraj Mody: Some of our... Where we spent a lot of time working together was the whole heuristic of how it was stateless. So if the server crashes, they got to use the client's to repopulate state and all that fun stuff.

Tom Kleinpeter: Yeah, Ah! Good times!

Viraj Mody: That was fun that was before now you can just NPM install all Pretty amazing.

Patrick Gallagher: So Tom, between you two you made the jump first. Bring us into that inflection point? What led you to start Audiogalaxy part two? And what was that moment like?

Tom Kleinpeter: Yeah. So I had left Microsoft after two years. I could tell there was going to be a lot of complexity organizationally at Microsoft that I didn't really want to fool with. And I was just about to have my first child. And so I kind of wanted to just take a break and take some time off. Cause I had been working really hard for a pretty long time.

So I left Microsoft early 2008 and then the weirdest opportunity came up because we had been sued by the recording industry and shut down Audiogalaxy version one. But they actually, they reached out to us. Someone who was working with them on a new project, actually reached out to us with the idea that we could turn Audiogalaxy back on for universities basically.

It was a project called Chorus and the idea was roughly, there's all these university students who are trading music on P2P networks. Like they're getting sued. The universities are dealing with that. It's a big problem. What if we just had some kind of site license with a, like an approved solution and people could just do as much as they wanted online. And it would just be great.

Which sounded, I mean, I had told myself I'd never get back into the music industry because yeah the music is a tough place for software people. But it was such an interesting idea that I really couldn't pass it up.

And so, the guy that had originally started the first Audiogalaxy Michael he got the call and pulled me in and so it was like "Okay, let's do it again!"

And so then we worked on a little bit and then one day Viraj showed up at my house...

Patrick Gallagher: Yeah! Tell us that moment becuase you know, you've been spending some time building that out. Viraj. What was your thought process? What led you to that moment showing up on Tom's doorstep?

Viraj Mody: Yeah. So when Tom left, I inherited all of his code and was basically, you know, the new Tom, it was fun. It was great. I really enjoy... and that's when I really got to see how he had built the thing. And it was pretty beautiful. And generally Tom and I had spent a lot of time working together. He seemed pretty legit.

But then between when he left and the next, I'd say six odd months. The unfortunate politics of old school, Microsoft sort of happened. And just, it was no longer a special, fun place to be.

Like a lot of the people, it was pretty amazing because if you make an inventory of everything awesome that's happened in the last 10- 15 years in our industry. Many people from that group have their hands in it. A lot of early Facebook crew, everyone who built Facebook platform came from the team. A bunch of people at AWS who built some pretty amazing stuff came from the team. So the team kind of became less fun and all the politics took over. And I was like, "Man, this is not worth it."

And I distinctly remember this one day when two distinct incidents happened where I'm like, "okay, that's it. I'm out of here. This is the breaking point. I need to quit Microsoft."

And I ping Tom. Uh, he had had a kid and I went to go say hi to his kid. Anyways, and so I showed up at his house with a six pack, of Shiner Bock, which is it's really popular beer from Austin that we loved. And I was sitting in his house thinking, "man, I'm just going to pack my bags, move to San Francisco and do some startup thing."

Cause if you can't tell already I am pretty risk happy, the combination of not being averse to risk and being persistent is pretty lethal. So I was like, "yeah, I'm just going to pack my bags and go to SF. And I don't know what I'm going to do. I'll just figure it out. There's all this YC stuff that's happening. Uh, It's pretty cool."

And then we started talking about what Tom's doing and I was like, "man, I should just join you!

He's like, "yeah, you should let me think about it..."

And then him and Michael and spent the next week or so just convincing me how joining them is a really bad idea and telling me all these stories of how people are doing startups, just like it's a roller coaster journey. They know many people who ended up without a spouse at the end of that journey, just like a bunch of like real but scary things. And I was like, "eh, whatever... let's do this. I got very little to lose."

Yeah. And that's how it happened. I was the first person and the last person to join the team.

Tom Kleinpeter: Yeah. A different kind of startup. I mean, it was extremely risky because it was, built on built near the music business, which, you know, there's just a lot, you don't control. And, we hadn't gone and raised a bunch of funding. We were bootstrapping it ourselves. So we really wanted to keep it small until we knew we had a hit on our hands.

But it was extremely fun and I'm super glad Viraj joined because it would have been much less fun without him.

Lessons in hiring and assessing risk at an early stage startup

Jerry Li: Viraj, I'm curious to learn that conversation between you and Tom that convincing you NOT to join.. How did that impacted the relationship back then? Because I could imagine that this is really a trust building thing because normally you were working at a startup, you would convince people to join.

Viraj Mody: Three people talking versus somebody trying to convince somebody. So, you know, Michael and Tom telling stories about things that didn't go well the first time around or the second time around that they had done this and things that did go well. And what I should anticipate.

I think they were kind of nervous too, to bring in somebody is my guess? I don't know. I never asked you Tom but I'm guessing that was part of it. But also it's like, you know, let us make sure you're thinking of this correctly. Which is a strategy I use even today when I recruit people, it's "look, my goal is to not hire somebody to check a box that says I hired somebody. It's to make sure that people are walking into whatever they are walking into with their eyes wide open."

So I agree with you. It was more like a trust building exercise than really like scaring somebody or convincing somebody.

Tom Kleinpeter: Yeah. I mean, I don't think we were trying to run him off. I think we just wanted him to know what it was going to be like. And I mean, startups are a very different experience than working at a big company. I mean, they are profoundly different, particularly one like this.

At Microsoft, you can have a really valuable career without ever shipping a valuable product. But at a startup. Everything is worthless unless you build the product. It's just very different incentives, very different rewards, a much higher highs, much lower lows. Everything can just go away in a minute or, it can turn out really well.

So it's very different from a big corporate job.

Jerry Li: I just want to tease out that the learning forward on is that a strategy to, to hire people into startups. This is being authentic and really have people's back and finding for their best

Viraj Mody: Yeah, if you don't do it this way, though, you end up solving one problem and creating two more... You now have somebody who joined your team for the wrong reason. Potentially their unhappy. You're unhappy. You have to dealt with it. They have to deal with it. So this is such a no-brainer,

Generally in life being straight and upfront is a no-brainer.

But like when you're hiring for a startup, that's an even bigger no-brainer because there's no nonsense here. Like, it is what it is .If you know what you're walking into, everyone's going to be okay. If you promise somebody something you can't deliver, everyone's going to suffer.

Patrick Gallagher: Jerry, I'm going to quote you from earlier , you stated this really powerfully,

but when we were putting our heads together and thinking about what we wanted this conversation to look like, we were reflecting and we were like, Oh my gosh, between Tom and Viraj like they've pretty much have held every type of job you could have within the engineering leadership career from being an engineer to principal engineer, chief of staff and to now co founding your own company, like everywhere in between, you two have kind of done it.

And so I think, especially with this particular moment in time in both of your journeys, when you're looking at startup opportunities, is there a lesson that you've learned from both sides about... for you Tom jumping and doing Audiogalaxy V2? Or for you Viraj making that risk assessment of, should I jump into this early startup? Is there something that stands out in your mind for how you assess those types of risks and decisions now?

Viraj Mody: For me, there's two memes that were pretty clearly sort of busted, when I did Audiogalaxy and everything since. There's this meme of, "startup equity's worth nothing." And it's that's how you should think about it."

And then there's this other meme of " you join a startup to become a billionaire."

the truth is neither of those are actually true. It's an exercise in understanding the risk curve that you can tolerate. And part of the reward along that curve is beyond monetary... there is obviously the monetary component of it. There's the ability to build in a no-nonsense environment component. The ability to learn, grow quickly. Try things...

Like the reason we have had the fortune and the privilege to have all these different roles and all these different companies is because we thought of this as an opportunity to try different things. And that came true.

Not one always happened, but you know, unless you make that bet it almost certainly won't happen. Like if all you're going to be is a career software engineer at a large company, guess what? These opportunities will not happen by definition because you never even tried.

So that was the big lesson for me saying, none of this is like a "always successful, always failure" type of thing. It's like a risk reward curve, and there's many inputs into it. What the company is, who the people you work with are. What your personal life situation is. What the macro environment is. It's like pretty complicated. You can't write down a formula.

But stepping back and thinking of it as a system of complex variables is sort of the meta lesson from my perspective,

Tom Kleinpeter: Yeah there is no one right answer for everybody. I mean, like Viraj said, it depends on a million things, you know, like you get different things out of different types of companies. You will probably learn better engineering practices at a company like Google than a random startup.

At a random startup, if you're early in, you will probably become much better at dealing with ambiguity and open-ended problems because you may just be handed something that would be a 50 person team at a big company. And they might say, "go do this. Let's see what it looks like in two weeks"

And it can be hard to get that kind of training at bigger companies. It's not really in a big company's interest to give super open-ended ambiguous problems to 22 year olds, you know, because they're probably gonna fail. That they're probably gonna mess up.

And so I, I had the huge fortune that I spent the first six years of my career just almost accidentally doing startups where I was really the engineer responsible for huge chunks of the software. It was just the way it was, you know? And so I had other smart people to talk about stuff with. But ultimately I had to make a lot of decisions and write a lot of the code.

And that was the best training I could have possibly had for being like a principal IC at a company like Dropbox. Because over and over, I had whole projects that I had to start from the beginning with nothing. Make it exist and then deal with the fallout from when I screwed up the first time.

But, I would have made way more money if I'd gone to Google it's just impossible to say.

Patrick Gallagher: think it's so hard to replicate the accelerating effects of increased responsibility and increased scope of work in a rapidly changing environment like that. Like the being able to answer open-ended questions and take on the responsibility of making that happen really does change your operator mindset

"Yo, I don't even know how to use a Mac..." plus other strong opinions & mantras from their early startup experience

Viraj Mody: Tom. I have this crazy story... Speaking of open-ended problems... I was maybe my first the second week I don't even know if you remember, but I had to go buy my own computer obviously, and I was setting it up and I had only ever used Windows in my whole life because you know, Apple was pretty small back then.

But one of the value propositions of Audiogalaxy was it just works across all platforms. And so they had, some contract person who had done like a prototype of a Mac iOS app or something like that?

In my second week after my windows machine was set up Tom and Michael were like, "Oh yeah, you want to go buy a Mac mini off Craigslist because it's cheaper? And use that to build a Mac app?"

I was like, "Yo, I don't even know how to use a Mac..."

Tom Kleinpeter: Yeah just do it!

Viraj Mody: Yeah, I think so, it doesn't get any more open ended than that. Buy a Mac. Learn to build an app, just go make it work. And now I can say this, but I was shitting bricks back then. Like I can still, if I close my eyes, remember the dining table that I used to work from, because of course we didn't have an office. We were pretty advanced. We were doing COVID type remote work back then.

So I was sitting on a dining table trying to fiddle around with this Mac cursing at the mouse, because I could not figure out how to use a mouse and then spent 20 minutes trying to remap a keyboard so that I could actually like use stuff.

It was insanity. And I was like questioning some life choices back then. But, three weeks later the app was built, it was running and nothing could have boosted my confidence more than just building shit. Like my number one lesson from that first month was if you can build stuff, you can do anything...

Tom Kleinpeter: One of my mantras that has served me well, my whole career is it's all just code. Like it's all there. It's all in front of you. It looks hard at first. And some of it is really hard, but it's all there. And if you just spend the time and dig into it, you can usually figure it out.

I mean, some stuff is... it's probably too hard for me, but like typically whenever I've backed away from something because it looks hard and when I go back, it's okay, let me just put in some print statements. Let's see what happens.

Viraj Mody: One of the comments. I get a lot from people who watch or work with me is like, "How could you do all this crazy stuff? You haven't done this before. Why do you want to do this? You have no experience with this stuff."

I'm like, "I don't give a shit because I can figure stuff out." And I have the confidence that I can figure stuff out, build on top of a lot of these kinds of stories. Where... " Hey, I had to go do something that I had never done. And I was really scared. But now that feeling of being scared is actually what gives me confidence that, "okay. Yeah. I've been here before. I've been scared. I figured it out and I basically survived."

It all being code is interesting. Cause at some point we'll get to how, when you go to the people management side, it's nothing like code... like, I was like I wish I had a debugger to stick into your brain right now.

Jerry Li: On the other side is also reflect the insights that as a an engineering leader, how powerful it can be by giving that type of open ended question to young folks and then let them try and fail. So that he can have similar experience to what Viraj had in early days, which becomes, I think pretty important later on.

Tom Kleinpeter: Absolutely. I think I'm ultimately responsible for a lot of the technical decisions that happen, but I really would prefer if other people can make a lot of those and feel responsibility as well. And yeah, we're going to make mistakes. People are going to screw up that will just happen, but we will recover and we'll proceed stronger... because I really want to build a strong bench of people at the company that have this same mindset. That they can take on open-ended things go make them happen. And the only way to really learn that is by doing it.

So that's a key part of how I think about, what people work on.

Jerry Li: Yeah, that's an important part of the culture. I believe.

Viraj Mody: Yeah, that's, it's one of those things where, you know, the sum of our experiences from Audiogalaxy and Dropbox and Convoy and Tom, before that with FolderShare, it's all sort of coming together where, you know... we have a strong opinion on how we're going to build this thing both from a technical perspective and an organizational perspective.

And it's not a question of what is right or wrong because that's subjective. There's, what is right for us is probably what matters. And I think a lot of what happened, you know, I'm sure we'll get into the details of how we built Audiogalaxy.

But a lot of that has resulted in strong opinions on, "Hey, look, we want to optimize for velocity. It comes with trade offs. Here's what we will trade off. Here's what we will not trade off. "

"These are the class of decisions that we want to spend time on. And these are the class of decisions that like, if we're spending time on, we're doing something wrong."

I could not have come up with that list 15 years ago. I doubt Tom could have either. But the sum of all of these experiences allows us to do it sort of our way this time in a way that we think is what is right for us. But it's full of opinions. You know, some of this may make people cringe, or like we don't do this at all. It's like what? But every handbook says you should, But, Hey, you know what? Life has taught us a few lessons that handbooks cannot.

Jerry Li: Yeah, I guess it's less about, what is right it's more about who we are and what we believe.

Viraj Mody: Yeah. And being able to understand and articulate and be okay with it.

What happens when you remove decision-making delays & non-coding time from an engineers schedule

Patrick Gallagher: So speaking of opinions, what are some of the opinions that you formed at the early times in Audiogalaxy? I think the key thing about Audiogalaxy V2 was just, we did a ton of stuff. I mean, Viraj and I wrote just an unbelievable amount of code over a couple of years. Now, we built a ton of features. We built multiple product surface areas.

Tom Kleinpeter: I mean, geez, so got a desktop client that ran on three platforms that would do P2P music transfers. It had all the fun at piercing and network relaying stuff. We had a, a really interactive website that would stream music from your local machine or through a relay. It had community features. I even wrote my own markup language. So you could, if you referenced a song or an artist in the forum posts, it would render it referenced in a cool way. we built an acoustic finger printer. when it would scan your music would actually match it against our database. I built the training data set for that myself by like ripping CDs with tons of different software to try and, get broad coverage. We built a desktop installer that would bake your credentials into the installer. And this was, 12 years ago? So you just, you're signing the website, you click download and you have an installer that's unique for you.

Then mobile came along and were like, all right, let's build Android iOS apps! We had shared native code for doing the buffering really efficiently and well. We got into some early ML stuff.

And it was just the two of us! I mean, we were two writing code. it was great training at the technical level for just building a ton of stuff. But it was also great training for the really key points you need working at a startup, which is just to be relentless and creative.

Just like you have a problem. Okay. You have a problem, fix it and move on, come up with another way to fix it.

If the problem's too hard, do you really have to solve that? Can you go around it, but just keep going. Don't stop. And if you just do that for enough hours each day, You can build some pretty cool stuff.

It was kind of like, you know, a long time ago you could speed up your computer to play a video game. Yeah, not artificially, slow it down. Some play an old video games that you play on hard mode for a little while with no turbo on your computer. And then you switched back to playing the regular mode. It's much easier. So, uh, Audiogalaxy V2 was, was, very much like just speeding everything up so you could just get more reps in.

Viraj Mody: It was pretty ridiculous. I remember It was very normal for me to write PHP. C plus plus Java script, Objective C and Java all in a day and not even flinch. I wouldn't even think twice about jumping between all of these. And this was before, you know, all of our clients who are a hundred percent native cause there was no cross-platform browser-based Atom stuff. And we were doing everything at the network stack even,

Couple of stories. I remember distinctly. I was on vacation in the Netherlands, I think in Amsterdam while I was really trying to make streaming work well on iOS. this was the early days of the iOS platform. I think we were the, one of the first few apps outside of the native music app that actually did audio stuff. And there's a whole interesting sidebar here around, the Apple app approval process. But one of the things that really frustrated me was network quality back then, 3g, I think it was a state-of-the-art two G was still like. Still pretty good. How do you stream without dropping packets? The iOS audio APIs were sort of, okay.

We literally wrote a codec by hand and I remember spending about half of my vacation sitting in the library in Amsterdam because they had internet access making that codec work. So that when I came back, it was great.

And then Tom used to go jogging and he used to take his Android phone and then send me bug reports on, "Hey, this song stopped buffering at this point." And then I would have to go figure out what happened.

It was pretty ridiculous that... I don't know if I could do that again today, but I know I did it 10 years ago or 12 years ago, whenever.

Tom Kleinpeter: Yeah, it's always fascinating to contrast that to bigger company life. when I think back about what we didn't do? There was, we weren't hiring anybody else. So there was no interviewing. There was no recruiting. We had one meeting a week that happened over lunch. Where we would go and get lunch, some teriyaki place, then get coffee afterwards. So that was about two hours a week face time with other people.

We worked from home. So we had no commute and we didn't do code reviews unless there was something really tricky because, we sort of accepted that we just weren't going to have a very good bus factor at this company. And...

Viraj Mody: if you're broke it you fixed it!

Tom Kleinpeter: Yeah it's always okay to wake me up when I'm at a startup.It doesn't matter. Just page me and Viraj felt the same way.

And so when you take all that other stuff out. And it's really just, okay, you got eight hours today, you just. Yeah, as much as you can type that's what you can get done.

I think one thing I missed that's super important is we just made decisions extremely rapidly because we had all the stakeholders on IRC available all the time.

And Viraj and I both had all the product context, we need it to where, we could, PM stuff on our own a lot of the time, because I mean, hey, it was a music app. Like we used it ourselves. We had strong opinions about how it should work. And so when you take out the delays for making decisions and all the non-coding time in engineer's schedules you can really do a lot.

What principal ICs & engineering leaders have in common... “Your job is to be decisive!”

Jerry Li: How do you apply that learning later on at Dropbox?

Viraj Mody: it showed up for me is, again, as I sort of switched later on into the leadership role, one of the crystallizing things that came from this experience is...

One of my jobs as an eng leader is to be decisive. And this is something that I think generally leaders do not really understand. You can almost tell leaders who get it and leaders who don't.

You know, if you run a big organization, whatever engineering sales, doesn't matter if a problem bubbles up to you, and if your team's capable it's because they didn't know what choice to make. Right? Everything's about pros and cons.

And if someone comes and asks you a question about, Hey, we need a decision. If your response to them is non-committal or if you go and ask them, like give them pros and cons that they already know about, but don't make a decision... your entire organization grinds to a halt., right?

They're coming to you because they need somebody to say, okay, do this. and there's just so many leaders who are indecisive, who always asked for, "go get me this information, go get me that information, and then I'll make a decision. Or maybe then I'll still ask you for more information."

Like that's the kind of stuff that I've gotten allergic to largely from this experience where, you know, it's easier to build something, fail at it and go fix it. Than it is to just spin round and not really make progress.

Tom Kleinpeter: Sometimes I think that's one of the defining features that. Principal level IC and, engineering leadership really have in common is... one of your jobs ~~~~is to use your intuition to make decisions quickly. Like you're not going to have all the information a lot of the time when you need to make a decision. But that's, the job! Is to make decisions that are mostly correct in low information environments and to have built structures, to let you recover in the inevitable places where it is the wrong decision.

So I think that's something that technically, I think I've done pretty okay with by just spending so much time at startups where you get to build a ton of stuff like strengthens your intuition about things. But yeah, I think that's the job in a lot of places. It's just, how do you make decisions with low information?

Jerry Li: Yeah, I think this is such an important notion

The essence of that is to make decision quickly. But since you guys, evolving sort of parallel career paths uh, Raj on the leadership side Tom on the, principle engineer.

Do you have examples of applying that insights for very different contexts contact? Viraj, when you mentioned making a decision quickly. a lot of these things you're referring to are more about organizational, strategic, or people related versus the type of decision Tom is making is more around technology.

Do you have each of example of how to apply that insight?

Viraj Mody: Yeah, there's probably a common denominator to some of these where it's essentially about weighing the pros and cons and then determining which trade-off you're comfortable making.

I think this applies to the technical side of things, as well as the organizational side of things. I can think of countless examples on the recruiting front or on product decisions. It's "look, we can choose to do this, or this."

Many leaders will say let's do both. And I am very allergic to that where I'm like, "okay, no, if it's this or this, let me ask a lot of questions and get the information I need."

But then my job is okay, here are the pros and cons for going this way, here are the pros and cons for going that way. Let's pick one! Literally the worst thing I can do is say, give me both of these. Or say, Oh, you know what? This sounds good. But then also let's do a little bit of that... That sort of thing is what slows stuff down.

You can apply this to recruiting things where it's look, if you've done your job correctly of having an objective recruiting process and evaluation criteria, not every decision is going to be, fully on one side or the other.

There's going to be some places where you have to weigh trade-offs. Make that call and, stand behind it. And if it was wrong, you own it. That's okay. You don't have to be right, but I think the cumulative experiences that you've gathered over the years help you become more right and wrong. If you're comfortable in making decisions.

If you're not, that's when you get in trouble, right? If your default is to always punt the decision down the road, you're essentially not exercising that muscle that you're going to need when you have to make a decision. I don't know if there's any specific technical examples Tom there may be different.

Tom Kleinpeter: Where this comes into play a lot, technically is with prioritization because I think engineers can usually tell you like a long list of things they could do. If you have a system, it's not hard to enumerate a lot of the ways it could fail, a lot of things that could go wrong. And any ways you could fix that.

But I think where intuition comes in very helpfully here is, what do you do? Let's say you have a system, I would like to be able to look at that and say " the likely failure modes are these. Let's write a consistency checker for this, and you know, let's not go nuts and do every possible thing we could do to verify this. But, you know, maybe if we put a small investment in here, w we'll spot a large class of problems early, and we'll be able to fix them before they're that big of a problem."

My job, I feel like is helping to, figure out what the ROI of different things we could do are, and just having some experience about problems you've seen in the past and what could go wrong and how hard different things are going to be.

I think, spotting problems and figuring out how much to invest in them is a good example of where the technical intuition can come in.