Top 5 Lessons Learned from Databricks' Journey from $400M to $1.5B+ ARR Nadim Hossain Fmr VP Product

Just going to give everyone a few moments to join us here in the room, but we are so excited to see so many of you here with us and joining us on another lovely Wednesday. We're going to just give folks a few more moments to get into the room, then I'll introduce you to our wonderful speaker for the day. Hi everyone. Thanks so much for joining Nadine. We're seeing some familiar faces but some new folks share, which is always great.

Awesome.

Hi everyone. Thanks so much and welcome to another edition of Workshop Wednesday. We are so thrilled to have you all with us here from wherever you're tuning in from and we would love to hear where that is. We always have folks from all over the world, so make sure to drop that in the chat so we know who's with us today in the room. As always, we are here every Wednesday at 10:00am Pacific Time to share another amazing interactive workshop. We always have an incredible SaaS expert to walk us through some of their latest lessons and today is no exception. We are thrilled for today's session to be with Nadeem Hussain, who just wrapped up his time as VP of Product at Databricks. Nadeem is taking us through his top five lessons that he learned on the Databricks journey and their incredible scale up from 400 million to over 1.5 billion. Nadeem had an amazing post. He's going to reference it a little bit here, but just a very insightful post, kind of wrapping up his time there and we knew when we saw that that we wanted to have him to dive in deeper and answer so many of our questions. So we're really excited to have Nadim with us. Nadim, welcome.

Thank you for having me.

Yeah, as always, we want to keep these sessions as interactive as possible. So please make sure to drop your questions for Nadim throughout the presentation down into the chat and I will work with you to get you in the queue and hopefully you will be able to ask your question live. And Jo, the conversation before we dive into Nadim's full presentation, I'm going to start off with just some of our quick fire questions to get to know Nadeem a little bit more and hear what he's been up to. So Nadeem would love to hear what project are you working on now that you're most excited about?

Yeah, great question. So thanks everyone for joining and for spending a few minutes together. And I see some familiar names and faces and some new ones, so that's great. So I've left Databricks recently after a pretty amazing three years which felt longer in a good way. And one of the things I'm spending time on is besides introspection and kind of things you can do when you take a bit of time off, but really also reconnecting with what's happening in the industry. Even though databricks is and was at the cutting edge of a lot of trends and data and AI, the real action is often happening at early stage startups. So that's been a blast from meeting founders who are just starting out before they even raise any money or have any product or also a bit later all the way up to companies in a 100 million-plus. And it's just been fun to kind of reconnect with that energy. So I'd say the project has been learning, learning about what's happening especially obviously in the data and AI landscape, but in SAS broadly as well. And all of SAS is, my view is that all of SAS is becoming really part of the AI landscape in a way. So it's been a lot of fun.

Amazing. Well, and we're grateful for you to be spending some of that time, Nadim, with us here and we have people truly from all over the world. I'm seeing folks from Korea, from Ireland, all over the us so super exciting for you to make these connections here too. In the last 12 months, what's the hardest thing that you've worked on?

Yeah, there's a, there's a. So I know you were going to ask me that question and there's so many choices, I didn't really narrow it down, to be honest. But you know, I would say just kind of randomly pick one. So one of the things that I can talk about, because we've, we've since launched it, is feature serving. So this is essentially an ML use case. But the, one of the underlying problems was for databricks to come up with the platform to be able to serve something in real time. So very low latency and potentially very high ups and sort of, I guess in terms of database terms. And that's something we hadn't really done before. Most of databricks has been analytical processing, so asynchronous jobs. So that's sort of the backstory. The hard thing about it was the new kind of engineering project, very difficult one to get into closer to real time use cases, not all the way to transactional database, but sort of going in that direction. So it was a lot of fun to work with engineering team, the product team, the founders directly on and also difficult to be clear to tease out the right Way to go after this. And obviously we had this exciting milestone where we launched Feature Serving. And I think that was an example of some of the things I talk about in my blog post, really, you know, being focused on the customer needs and, and trying to get to a milestone as quickly as possible.

Yeah, I was going to say, I think you're going to. That was a great preview for what you're going to be covering and in your presentation too. So excited to hear more about that. And then just one final question, Nadine, before we get kicked off on your full content, but would love to hear what's currently your favorite SaaS tool or platform.

Yeah, I'm going to be super boomer here. You know, for me, LinkedIn is forever. You know, if I, if I just look at, you know, I'd say YouTube and I'm going to exclude them as a SaaS tool. But, you know, you can love or hate LinkedIn and probably all of us do both, but it, it is essential, right? You know, yeah, it can be annoying, but if you're trying to, you know, connect, it depends on your job to be done is. But in my case, it's maybe less about learning on LinkedIn, but it's a little bit more about connecting with people. And for that, there's just no substitute in our industry. Until one of you folks comes up with a better mousetrap, that's what we're stuck with. And again, I say that with love. Many of my databricks colleagues are ex LinkedIn folks.

No, that is a great reminder, Nadeem. And that's an answer we haven't had yet. And I love it that it's just like going back to the basics and obviously a tool that all of us use so much. So that's a great. That's a great answer.

The numbers don't lag. I got to look at my actual usage, not what I'm excited about.

Yeah, for sure. Well, without further ado, we will pass it over to you to walk us through your lessons learned and then everyone will have plenty of time for Q and A with Nadeem. So take it away.

Awesome. Sounds great. So, and I think I put on there. Feel free to follow me on Twitter and LinkedIn. Twitter's @nadimhossein and I did have this talk pinned there. Obviously we're going to go deeper with more Q and A here in case you want to follow along there as well. So just a bit of context, you know, the last three years. I joined Databricks in January 2021, and I just left recently. So just a bit over three years the company has gone from 1600 employees to over 6500. Interestingly, I did see Salesforce at that same stage. So if you have any questions about comparing contrast, I mean that was obviously a long time ago. The error grew from 400 million to over 1.5 billion. I think recently they have said they've crossed 2 billion ARR. And interestingly there was also the same same growth I saw at Salesforce. Again, different eras and different categories and the things that I did. So just very briefly on my background, I'm primarily a SaaS product leader. My first 10 years of my career were pure SaaS workflow, SaaS, things like Salesforce and products like that. The last 10 years really have been about more starting a company in analytics and that really had me fall in love with data platforms and a bit more the data side of things. And from there I went to Uber, worked on a few things including self driving and then came to databricks. So what I've done at databricks specifically, and I'll just go through them really quickly, about 40% of our engineering roadmap, just to give you a sense of scale, but all things that are not focused on the individual data engineer or the individual data scientist. So all of the things that are enterprise focused, all the platforms like the compute platform, which obviously every workload databricks leverages, the security, governance, et cetera. So a bunch of different things that were super interesting but also a lot of context shifting for me in particular, I think even more so than some of the other folks. So that's a bit of quick context. So we're not going to skip lesson one. So a couple of lessons and again leave a lot of time for Q and A. The first thing, and this is a databricks cultural value. So it's not total, it is not a surprise to anyone who's maybe worked at databricks. But what I saw, what I witnessed and took part in was that the company really evolved from a single product company to what is definitely a multi product company and it's fulfilling its vision of a unified data platform. So now that vision, like a lot of SaaS startups, it had a big vision for the beginning and if you want to geek out on that, you can go back and look at old slides and Ali and the founders always talked about unified data platform. But my opinion, my observation was it never really stuck. It's sort of like that meme from Clueless. Stop trying to make whatever Happen and the whatever was unified analytics. Yeah, stop trying to make unified analytics happen. No one really cares. I would say that was a reaction from the industry for a good chunk of the company's evolution. You know that's an opinion. I think it's up for debate. Databricks achieved product market fit on serving data engineers. I mean it was just this much better product from a price and performance and it just took off in terms of product market fit. But to the founders credit, they saw that thinking from first principles that the way that this industry should go is that you should combine into a unified data platform different kinds of workloads, you know, analytical workloads, you know, that are used by data engineers, but also the data warehousing type of workloads that Snowflake really crushed it on. Right. I mean they built the company on that. And in the time I was there in 2021 specifically right when I joined Databricks made two very, very big bets. Things that didn't really have outside of the founders minds. One was on serverless compute and the other was on unified data governance. And it's a bit inside baseball. Exactly why those were really big bets for the company but they were just massive changes. My observation was that we would not have gotten there had it not been Maybe almost the PhD or academic mindset that I love about the company, the founders, which is really thinking about ideas and concepts from first principles, down from the atomic unit if you will. And it led the founders to really see that if we're going to be playing in, you have to have serverless compute. One reason is just a snappy user experience. There's other reasons as well. And similarly if you're going to be a unified data platform, you obviously need some sort of governance to say that Nadim can access this table and not that one, this row and that one, et cetera. So that's number one. Ambitious goals were embraced and executed on and they would not have happened without that cultural principle, that attitude of really first principles thinking which yeah, there's trade offs and we can talk about that in Q and A if you want. It's not all unicorns and rainbows. Everything I talk about here has trade offs as in life. So there are downsides as well. But this really worked well for the company. The second lesson is founders and leaders diving deep. And you know, those of you, some of you might be from, from Amazon or aws, certainly the dive deep cultural principle is not unique to databricks. I think it is very common with founders. In fact I don't know any good founder who doesn't have this, this way of operating it can drive many startup teams crazy. That's why you're working at a startup, because you are crazy. But I think this is really really important. Has been really important for many companies success and I think at databricks it was really important because the founders were specifically hands on with R and D is what I'm thinking but also other aspects of the organization. So the examples I think I gave in my post and then we'll talk things like detailed technical reviews when and I'll just pick on Ali. But it's same is true for Matei or Reynolds, any of the other founders. The expectation was that we'd be able to dive into a PRD in a design doc, right? So the design doc is what the engineering team, the tech leader, the engine managers is writing up and the PRD is mostly what the PM is writing up. But there was a sense of co ownership so the product manager needed to know what was happening in the design doc and commenting on it and editing it and similarly with the tech lead accountable for the PRD as well co accountable and in fact often there wasn't a PM that the ones had to write it. So that idea of diving deep in technical reviews and involved in decision making really serve the company well. It especially for a very technical product like databricks where it's making its bed on innovation and making the right architectural bets, for example, it was very important. This may be less important in other categories. I don't have a unified view of that but at databricks certainly my opinion is that it was really important and one of the trade offs is, you know, it takes time and well for a product manager which is the lens I'm coming from. Managing a product PM team, it can be daunting that your review is with Ali, right, the CEO for example. And that is a real trade off, right. You have to as we talk about later, hire people that can handle that. They'll find that interesting and exciting. It's not for everyone but the real benefits are we made decisions that were high quality decisions because there was deep involvement in that. You didn't simply rubber stamp a document and pass it along the chain for example, which you know, probably most agile companies don't do that but as you get bigger certainly I think you do have to operate a little bit more that way. So the third one I started touching on this and you know, my personal observations are a little bit product centric but I also Think it's one of the things that makes databricks great is, is that product mindset not just in the PMs but really throughout the organization. So, and this is something that I personally really had to help the company solve. And when I joined There were three folks in my entire org, you know, covering that 40% of the roadmap and we were already hundreds of engineers and I had to figure out, you know, diagnose, okay, what is this company, how does it operate and what kind of person shouldn't succeed here. So it really isn't copying and pasting some. It's more akin to, you know, 3D printing, custom PM molds, if you will. I think it should be true for most startups because every startup operates slightly differently. So figuring out if you're a product leader, figuring out, okay, what does my company need and what are we good at? Bad at the opposite mindset would be, look, here's what PMs look like and we're going to force fit them into this company. That never ends well if you're a CPO or a VP of product for reasons that might be obvious. So, and I think in numbers. So the number that I would, the KPI would use for fast paced environment or ambiguity would be rate of growth, rate of growth in the company and rate of change in the industry. And the industry that databricks is in was the company was growing at 90% at 400 million, which is pretty nuts. And a lot of that was thanks to the industry. It wasn't just the genius of the foundries, but really was the need that the customers were pulling the product out of our hands because there's such a need and timing was so good. But internally, this of course is challenging when things are growing that fast. You're hiring new people, you're adding new customers, there's a lot of chaos that's happening. So product managers had to operate at that pace. And that's easy to say, but it's, you know, there are trade offs, right? That means you can't hire people that are straight out of college and train them up in that environment. You can, but it would be very expensive. Actually we're doing it now or they're doing it now, but at the time in 2021, with only 15PMs total, it wasn't an option. So really finding folks that were already 10 plus years in product management was important and finding folks that were going to thrive with ambiguity was important. Something that I really targeted and the metric I used for that there's this, the other is the scope. The reality was we, I think I gave you some numbers, but we were at 30 engineers to a PM, give or take. And you know, if you look at Salesforce or Workday, it's going to be 6 or 7 to 1 in SAS. I'd say the more UX there is, it's going to be closer to that 6, 7 number. Maybe if it's more researchy or platformy, it might be more like 10:15, but you know, 30 to 1 is not, you know, in any best practice. Right. So, so that means that the product managers we did have had to be, you know, and I use the metaphor Navy Seal because hey, who doesn't like to look cool? But you know, but in seriousness, what I think the parallel is, you know, someone who's already had a lot of training, in this case in their prior career, who already has a lot of skills, who's expensive, let's face it, and who can context shift and do different things, it's not just one kind of mission they can take on. They can take on different kinds of missions. And being adaptable and agile and small and fast moving teams and being able to work across every part of the organization was really important, specifically being able to work with the founders on very highly technical topics. So I think that there in 2021, 2022 especially, you know, I think they've done really well and you know, really proud of that success I saw. And that's a lesson that I took away. So lesson four is build what customers want again. As a product manager, that obviously speaks to what I care about and what I've always cared about in whether as a founder or as a PM or a PM manager. But it was awesome to see that at Databricks. And the reason it's maybe slightly contrarian is this is a very technical domain, right? I mean you can look up the papers that were published and are still being published, whether it's now in LMS and sort of the Genai landscape or previously in database technologies. But despite that, despite that, you know, Berkeley AMP Lab cultural mindset, which is, which is an awesome place to come from, there was an immense focus on what customers want and on contrast with I just want to keep them anonymous. I spent a bit of time with this company that's similar in a similar space, 100 million plus but successful. But I noticed that my conclusion was NGMI, right? For this company that's got amazing VCs that you guys would all recognize. The reason it was NGMI is Like the founders don't care about the customers that much. They really believe in their own type and that's really dangerous, especially if you're a successful company. Right. So I thought, man, this company's not gonna make it. All right, peace out. Personally, you know, you know, like that's not an opinion. Obviously people think they're great, but I don't think they're great because they were missing this, right? They were missing this curiosity and desire to do things based on customers. So how does it actually show up? Right. Specifically being practical in driving product development based on customer feedback. This doesn't mean you're an order taker and do whatever they want. It doesn't mean you don't enter new segments or innovate. It just means when you have a vision. So that's more the North Star, the way that what worked well for us was to iterate towards that. Not in a doc. The steps are not dogmatic. So you don't say, hey, I'm going to climb this mountain. This isn't exactly the path I'm going to follow. Instead, as you're climbing the mountain, you're seeing what the conditions are giving you, if you will, to use that metaphor, that maybe going left or right based on where the wind's coming from, for example, to this case, it's really about give you a set of options. Visual that I have in my head is think of you're trying to get from one end of a, a backyard, a big lawn to another and it's covered in flagstones which are, you know, about a foot apart. So you could take any number of steps to get to the end of that, end of that backyard or lawn. But it'll be informed by what flagstones your customers tell you are available. And in this case in that metaphor, the flagstone would be a feature or a specific milestone that you're shipping to eventually get to that, get to that end goal. So I think this was that iterative nature of the roadmap was really important for certainly my team, but I saw that across other teams at databricks and maybe this is specific to this level of growth and the industry changing quickly. But I think it's hard to go wrong with keeping staying grounded and really the customer needs. If you're a product leader, of course as you're scaling 100 million, 400 million a billion, it gets hard because for product leaders you have to come up with planning mechanisms and getting source of truth from customers, prioritization frameworks, you know, the operations part of it to get that right so that you don't lose sight of customers without slowing down. And you know, playing six year old soccer, you know, everyone going to the same ball with the same customer requirements. So it gets complicated. There's trade offs there for sure. But this was a big lesson for me reinforcing something that I've always personally cared about. Lesson 5 so move fast and embrace the messiness. Obviously a bit of an homage to our friend Zuck. And really moving fast is obviously important. We've been talking about that in this talk so far. And embracing the messiness, I think it encapsulates that idea of trade offs is that like you're, you're not going to have perfect processes, you're not going to have that perfect feature, stack rank, you know, many, many examples, things like that. But being focusing on speed and agility and navigating that rapidly changing landscape and a rapidly changing company served this company really well. And I think it a lot of successful SaaS companies, I see that as an attribute. So there's trade offs in this case as well. So we didn't really have a standardized way to do lots of things. For example, prioritizing things, trading things up in 2021, of course that was part of my job is to introduce some of those things. But we weren't optimizing for the process, we were optimizing for the outcome and making the process. The process was good, it just wasn't a button down process, if you will. So really what it meant for employees, for myself or for my team was sometimes you have to embrace the journey and the learning opportunities it brings. And I'll give you one example right there's things, what I told my team when they joined it, these are, I'll give you a specific person in mind. They ran a 150 person team at Amazon, at AWS, very senior person, very, very capable, seen everything in their career and Amazon's an amazing company. Their way really well and especially folks from Amazon because they have such good, I think planning process, people can struggle. They say, hey look, if only we had Amazon's process, we'd be going much faster. Well, I think pretty much the only company that succeeded with Amazon's process is Amazon. So you probably shouldn't copy Amazon's process verbatim. You should learn from it and be inspired by it. But my advice was look, just for the first six months or maybe longer, just observe, see what's going on, don't make any big decisions and try to make things happen that are already underway. Be a good helper, be a good servant. The thing especially for senior people, if you come in and you're trying to fix the messiness, is that you're going to see 10 things that are just weird. You're going to fix all 10. But it turns out one of the 10 was a really important thing that works at the company, right? It's like if you have a weird golf slice and you fixed it, but then now you create a bigger mess because you're not ready to go through that work. So some of the quirks of an organization you have to accept as organizational debt until you can maybe fix it later when it's really important. So thinking, bracing the messiness and being patient with whatever company one joins, but especially this kind of Rocket Ship SaaS Co. I think is really important because all these companies have something quirky about them. So with that said, you know, I said not been a very long talk. So hopefully this is pretty, pretty fresh in your mind. But let's do a recap of some of the key takeaways before we get into Q and A. So number one is innovating from first principles. As we talked about, databricks achieved rapid innovation embracing first principles thinking. Number two is founders and leaders of the company diving deep. And the success of databricks I think I attribute to partially to leaders in detailed decision making. Number three is Navy Seal product managers. Pat on the back for my awesome team. So highly skilled and adaptable PMs that are able to navigate technical complexities, they can operate in a fast moving environment and really across all levels, which takes some experiences. Skill set number four, building what customers want. And really despite regardless of the level of innovation or how visionary you are, which I'm sure you all are, really focusing on building features rooted in direct customer feedback and that helps avoid wasted effort and maintain that rapid pace of innovation to be a bit more incremental, which is a bad word, some context, but we need that in a good way. And number five, moving fast and embracing the messiness, embracing agility over standardized processes and really adapting to challenges versus something's not being ideally structured, for example, so, so those are the five things that were top of mind for me. Obviously there's many other things that I've learned but these five really stood out and I wanted to share them with the rest of the community.

Thank you so much Nadine. We are hearing a little bit of interference on your presentation and just on your connection. So I'm going to have you stop sharing your screen. Hopefully that may Help us and let's just monitor it if we need to. Maybe have you turn off your camera, but we'll go ahead and get a few folks squared away for for Q and A. But thanks so much for that. Great presentation. Already getting some questions. Ash, if you're there, I'm going to spotlight you to ask your question live to Nadim.

Hey Nadim, thanks a lot. Really enjoyed your presentation. Really appreciated the comments about founders and leaders diving deep. Those are the best founders that we found and we work with and then the other one about building what customers want. I'm curious what you guys did while you were at Databricks to capture what features people are really, really keen and interested in both pre product, pre purchase and also sort of post product as you were working with customers, you know, and they were already customers already. And how did you define that matrix?

Yeah, so it's a big question, but the topic is essentially the way I paraphrase it is really what are this how you capture customer signals on what, what they're asking for, what has to be built. And they're. There was a couple of different things that come to mind. So the first thing was there was a. There's a culture. I think I talked about this in my written post. There was a culture of customer sharing customer notes. So especially as the product managers met with customers, they would share the notes. That's less about a specific line item and stack ranking and it's more about creating a culture where we're having this conversation about hey, so and so said this in this context. And oftentimes I would go via email and the founders would jump in, people would jump in and ask, hey, by the way, what was that about? Why do you think that was happening? So you have a conversation about a specific customer need, specific to actual requests for features. So that was one mechanism. And through those customer conversations, those, certainly those customer requests would show up in nprds. So that was certainly one place. But the other source, of course, is with the field, aligning with the field and they're the front lines trying to close new customers or trying to make existing ones successful or very commonly expand the customers. And that's another source of input. And I'd say that one of the things that I took away was you can't really at a certain scale, let's say beyond 100 million, pick a random number. You can't really think of stack ranking and coming with who's number one because you have swim lanes. Right. You can't really compare this innovation bet with Your core business as a SaaS company, you've got to carve out and shelter that innovation bet and say, okay, we're going to put a couple engineers on this. Similarly, you're selling it to Europe for the first time. You really can't compare a dollar US dollar from Europe from a US dollar in the US because it's new and delicate and there's more to it than just the business metric. You have a European team, you've just hired maybe the first ae, guess what? I mean, they're trying to figure out if the company's serious about selling in Europe and getting your first customer. So. So I think there has to be more than just, you know, a stack rank, which is kind of maybe the way that an individual PM or smaller company thinks about it. As you grow and become a multi product company, international company, you have to have a sense of, you know, those nuances and maybe creating a little bit of swim lanes for, you know, pools of engineering resources, for example. So I don't know if that touched on your question sufficiently, but that's kind of what came in mind for me.

Thank you.

Thanks so much. Ash, Nadine, we have another question from nara. Seema. I'm going to pull them up right now and then you can come off mute.

Yeah, thank you for that.

Yeah.

In the SaaS companies we always see a struggle between prioritization of the product features. Is it based on the revenue it's going to generate, the product feature or the market competitiveness? Like what is your thought process on competing priorities on the product development when the resources are not open ended. Right. And either from the product side or engineering side. So we had this struggle for sure. And your thought process will be really helpful for us.

Yeah, for sure. And this is a struggle that databricks had even still has. Right. The entire time that I witnessed it was always tight on engineering resources. So first of all, maybe a slightly sideways answer. So one thing that I thought worked really well at databricks was a healthy skepticism for centralizing too much. So trying to put as much down to individual engineering teams or groups so they could control their own destiny. So they were semi autonomous, if you will. So you know, one answer is, okay, once you figure out, I don't know, let's say the DB SQL team working on our, you know, sort of the data warehousing product, they can make their own decisions on with it, with their own engineers, then of course comes the question of how do you assign new engineers, etc. Which we can get into so that's kind of one one way to mitigate that then. But separately, especially as a product leader where you're working across multiple groups, how do you think about prioritizing? It is a collection of things. So certainly revenue is important and you can think of it as sometimes we would start tracking blocked revenue. So where often the field would say look, without this feature, you know, without this data encryption feature, we can't sell to this customer. His bank were blocked and they would log that. And we came up with a process in Salesforce way to look at it. That's certainly a signal I would say for databricks what made the. Makes the company great and made it great the time I was there was look, yes, they care about revenue. They always have to some extent because that's what it's a lagging indicator for customer success. But ultimately there was a lot of innovation bets as well, right? There was a lot of bets that saying like the first principle is thinking, saying look, this is where the market is going. We have to start thinking this way. So there's always this tension between. You want to be incremental, you want to serve customers, but you also want to pull the company towards a new vision. So the prioritization was really based on different things. And to be more specific, you know, there wasn't always. So in 2021, just thinking back, far back enough, you know, we added these big new priorities, Unified data governance and serverless compute. They were on top of everything else. Right. And it's. And forgive me Ali, if you're listening, it's not like it helped that much to tell the team that, hey look, these are top two priorities because they had three other priorities that were going to be impossible to get to. So I would say the priorities were clear, but they spoke for a lot more than we could ever ship. So. So there's always. So I'd say the answer to your question, maybe the best answer is there's always tension. Right. Tension is the name of the game. If you don't enjoy tension, probably shouldn't be a product manager in a high growth company. Right? That's, that's sort of the job is that you're getting pulled in different directions and you're not going to make everyone happy, you know, at a much more mature company growing at 15% and much bigger. Yeah. Different story. Thank you.

Thanks Nadim. We have a somewhat. And thanks for your question. Narsima, we have a somewhat related question on the same theme around tension and collaborating on the team. Mark, you have a question about the engineering and product manager relationship. So I'm going to bring you up or you can actually unmute yourself. I don't think you're on video, but if you want to unmute yourself and ask Nadeem live. Mark, you still there?

Yep, I'm here. And Nadim, thanks for, thanks for taking the time. So first off, find me a company that isn't tight on engineering resources, at least one that has a sales team. So as far as my question goes. So you mentioned, you mentioned, you know, seal team, product managers. How do you differentiate the role of a product manager versus your technical leads so that the two are working, you know, sort of collaboratively as opposed to, you know, either overlapping, in which case you've, you know, potentially got, you know, conflict and, and you know, discrepancies in messaging or just, you know, simply you don't have, you know, full coverage when it comes to, when it comes to the project itself and defining all the different aspects of it.

Yeah, for sure. So, so, so there's a concept called two in a box and I don't think it's unique to databricks but the way we embraced it was the owners of a particular, say a new product. There was the engine lead and the product lead and the idea was that the way you'd solve that, how do you make sure they aren't at odds with each other? They're just tied to the hip and they co own the PRD and the design doc. Right. I mean those are the two artifacts. So they're both co accountable for those key, you know, for that output. And of those two things, obviously design doc is more important. It's later in the process and it's the thing you're about to build. So the product manager really would have to be in a fair amount of technical detail. Right. So that's, that's the, that's the reality of it. And you know, how do you define the roles and how do you ensure they're not a dodge? I mean, yeah, I think, I guess you threw that two in a box mechanism. But also oftentimes there wasn't a product manager and the tech lead would be playing that role. Right. So oftentimes they already had practice at being a product manager, if you will. And I joked, actually I believe this, it sounds just a joke that the best product manager of databricks is Mate, the cto and Ali was the first head of product and he's amazing but I didn't work directly with him as a PM or as my tech lead, but I Did work directly with Mate quite a bit and it was amazing how good a PM he was. He's this, in my opinion, literal genius, technical genius, but he also had this great intuition and care for what customers thought. So I'm giving that example because if you're a PM, my PMs couldn't come in and say, hey, I'm the Navy SEAL, you're the engineer. No, it's not like that because they're going to be out everything by Mate. So you can't go in thinking you have to be very humble and not come in thinking I'm bringing this thing that no one else can do. It's really about enabling the success of the overall team, especially when you have very senior and capable leaders that are your partners. Hopefully I hit the answer there. Thanks.

Yeah, I think so. Thank you so much. Nadeem. Kind of similarly, on a team perspective, we talk a lot in here about recruiting the right folks and, you know, that's a huge challenge that everyone has across the board, depending, you know, regardless of if they're in sales or in product or in marketing and or even all the way up to the founder. So what were some of, what are some of your top tips for how you found folks and how you vetted during the recruitment process to find those people who can embrace the messiness, who can kind of align with that culture that you had at Databricks?

Yeah, that's a great question. So again, I led a number of product teams and so I talked about coming up with that, you know, the custom mold for what a PM should look like. And then the next step was, of course you got to go find them and you find them on LinkedIn. There's really. Where else would you find them but the specific thing. So there's some things that were coming from the company and the cultures which by the way, I might have pushed back on examples of this are has seen grade is really important. Not going to hire someone. Our database is not going to hire someone unless they've already seen great somewhere. Right. Maybe you worked at some other highly successful company, you went to a great school, but you have to have some aspect in your resume where you're really going to raise the bar because you've seen people operating at a high level and that's controversial for some very obvious reasons which we don't need to get into. But so how do you find those people? So specifically, for example, in, in 2021, again, I'm going back early because those decisions, you've seen the outcome of them we needed to invest in a product leader for security, the product security roadmap. And one of the things I figured out was, look, Databricks is a startup still, but it's operating in this massive similar scale as a hyperscaler. When they offer analytics services. We should go look at Google Cloud and Azure and aws, but find people that joined those efforts early. And this is, you know, so, so in 2021 I'd be looking for people at Google Cloud that joined again. I forget exactly when they started, but I think it would have been about eight years before that, give or take. And so I found those people, right? And I messaged them on LinkedIn when we had a paid for expensive recruiter account and, and just try to engage them, right? So that's how I found them as I personally messaged them on LinkedIn with a personalized message as the BDR, if you will. The recruiter saying like, hey, here's who I am, here's what we're doing, here's why your background is going to be a fit, you know, would love to chat if you're open to a conversation. You know, nothing, nothing, no rocket science, but really trying to find, I guess targeted outreach as opposed to looking for, you know, blasting people. But more that was sort of this in the first key hires and there's a number of examples of that. But then later on when we hired a few more, maybe a bit more at scale, it was still giving the recruitment once we had sourcers, which was, I don't know, probably sometime in 2023, saying, here's the profile that I'm looking for. I'd love someone who's worked at a startup. This is me personally. Other execs might have a different profile. They worked at a startup and they've also worked on one of the hyperscalers. That's the profile. Now of course, you can break that profile. You find someone who's at VMware instead of it AWS. Sure, it could probably work. So things like that were how we try to target.

Great, thanks so much for those details. It's always just helpful to hear how everyone kind of sees different, sees it differently and how they've done it differently too. So I know everyone. Again, recruiting is always a big focus for everyone that's joining these. And then we'll close with just one final question. Thank you so much for your time, Nadine. But we have a question from Katie. It's several questions loaded in, but it's going back to your very first lesson. Katie's Asking if you can elaborate on how your team leveraged first principles thinking, how did this play out in the day to day versus overall strategy and were there any big aha moments that came out?

Yeah, no, it's a tough one because if everyone is just doing that all the time, you're not going to get anything done. Right. You know, for example, we've all had the experience where, you know, your founder or CEO is like questioning, okay, I don't know what, I don't know recruiting system you're going to use. Like really, come on, just buy the best thing off the shelf so we can't have cost. Thankfully we didn't have a lot of that kind of principles thinking. But to your question, how did my team leverage it? Really? It was taking the example of the senior leaders and the founders and trying to put that in your own work. For an example would be when we were launching serverless compute. You wouldn't just say, okay, again not going into too much detail, but you wouldn't just say, hey, this is how everyone does containerization for serverless compute products. This is just the industry standard that wasn't going to fly. Right. It was going to have to be specific to look, this is how people do it. So my team would have to think through these different options. This is how we might do it. These are two different approaches. We might prototype them both. And here's the implication on the business if we take these different approaches, which means that it's more expensive, resource wise to get ready for some of these decisions, which. So I'll give you one anecdote. What I would tell my team is, look, you're going to have a series of reviews, right? We know again, it's pretty flat. So it might be directly with the CEO. You're going to not be ready for any of them, no matter what. Because if your high level strategy resonates, then you're going to be asked for details which you're not going to have yet. But that's the whole point of this dive deep. And first principles thinking is that you start having those conversations pretty early, but by the time you have, maybe for a big product, might have three reviews over the course of a year or something, or six months or something, by the time you progress, you're going to really have a bulletproof product plan and that's kind of ultimately what you care about is not to, not to take the company in the wrong direction.

Amazing. Nadeem, thank you so much for all the insights and thank you to everyone for joining. Nadeem dropped in all the ways to get in touch with him. So please make sure you're following him and you're connecting with him on LinkedIn. And Nadeem gave us all a huge tip that he's a big LinkedIn guy. So let's make sure to take advantage of that and continue to utilize all the vast knowledge that you have. Nadeem, thank you again so much for spending some of your time with us today. And everyone just reminder that this session is available on our YouTube right after Nadim. You'll be able to see it yourself too and share with your network on LinkedIn afterward. We also are going to put the slides up afterward too. And then next week we are back with an amazing revenue focused session. It's going to be with Kyle Norton, the CRO of owner and he's going to be talking about go to Market efficiency. So please make sure to join us then and bring your questions and then we will see you then. Nadeem, thanks so much for joining us and we'll see you soon.

Thanks everyone.