Co-creator of GraphQL and Founder of Dagster Labs - Nick Schrock

Nick Schrock is the founder of Dagster Labs, a data platform that helps you build, schedule, and monitor reliable data pipelines. They've raised $49M in funding from investors such as Sequoia, Index, Amplify, Slow, and 8VC. He is also the cocreator of the popular query language GraphQL. 

Nick's favorite books: The Great CEO Within (Author: Matt Mochary)

(00:01) Introduction and Welcome
(00:39) The Origins of GraphQL at Facebook
(05:24) Explaining Data Orchestration in Plain English
(09:03) What Dagster Is and Why It Matters
(12:37) Assets vs. Tasks: A New Philosophy
(16:51) Balancing Open Source and Commercial Features
(22:18) Growing the Early Open Source Community
(25:26) Signals of Community Health
(27:59) Landing the First 10 Customers
(32:25) Culture Shift: From Engineering-Heavy to Go-to-Market
(37:49) Mistakes DevTool Founders Often Make
(41:21) Selective Micromanagement and Leadership Style
(44:36) Rapid Fire Round

--------
Where to find Nick Schrock: 

LinkedIn: https://www.linkedin.com/in/schrockn/

--------
Where to find Prateek Joshi: 

Newsletter: https://prateekjoshi.substack.com 
Website: https://prateekj.com 
LinkedIn: https://www.linkedin.com/in/prateek-joshi-infinite
X: https://x.com/prateekvjoshi 

Transcript

Prateek Joshi (00:01.621)
Nick, thank you so much for joining me today.

Nick Schrock (00:04.716)
Thanks, good to be with you. Thanks for having me.

Prateek Joshi (00:08.126)
Let's start with, even before you founded the company, we'd love to start with GraphQL, which has become, many people use it, it's very popular and it's very hard to build something that takes off. So going back to your Facebook meta days, what was that, the moment when GraphQL was getting created and...

What led you to do that?

Nick Schrock (00:39.116)
Yeah, I think there's two things. One was kind of the stack we built up to GraphQL. then two is like, what was the instigating event that caused it to be created? think both are interesting. know, leading up to GraphQL, my entire, like, I was obsessed with all I did was work on our PHP code base and specifically our data fetching stack. And so there are some internal frameworks at Facebook that still live on today, not meta.

but it's in the Facebook app primarily. And this is the, like it's effectively a business object layer in a middle tier query language for Facebook. So it's Ent query. The details don't matter, but if you're a Facebook developer working the PHP code base, you like interact with this. It's kind of deep in the code base. And we kind of developed this declarative data fetching API that's in PHP.

but has a lot of similar properties to GraphQL. And in fact, GraphQL in its initial implementation was effectively a thin wrapper on top of that layer. So it was more like a building up to it over time and figuring out how to, it was a very incremental process actually. Then the instigating event about why it occurred is that kind of famously we had bet on HTML5 for the mobile apps. That was a disaster.

We were about to go public. had embarked on this project to rewrite the iOS app from scratch. But we needed a API. They initially tried to build it on top of our platform APIs, which was totally unrealistic. people were starting to build custom REST APIs for the app. But our feed, in particular, is an extraordinarily complicated.

data structure. There's stories and nested stories and attachments and comments. then those kind of like, it's just like, it's an incredibly complicated product actually, with a bajillion stakeholders. Every product team tries to get in the feed because that's how they get distribution. And one of my colleagues who I had previously been right on a team with, but he was on the iOS team, he kind of stopped by my desk every day and was like, by the way, Nick, I don't know what you're working on, but like,

Nick Schrock (02:57.196)
we're screwed as a company if we don't fix this. And like, we can't get actual data into the app. Like, please come help us. And I'm like, well, I'm working on this other thing. But then that kind of like fourth time I heard that, was like, maybe I should look at that. And then kind of a few other people were working on similar problems. Lee was working on the API, kind of the more static API and data modeling of feed. Another colleague, Dan Schaefer, was working on infrastructure and feed. And then I kind of had the

wide angle context, having worked on that stack that led up to it and kind of like, it all kind of like came together pretty quickly to build an initial prototype. And then it was like extraordinary momentum at that point, because we were about to go public. Mobile was an existential threat. It was kind of like, you know, we really felt that this like, you know, very important company in our minds that does a lot of work would die if we didn't do this. So we were highly motivated. And so that's kind of the story.

of how that happened. I look back on it very fondly. were absolute maniacs. The initial diff was like February, and then we were kind of ready to launch in May. So it just a few months to build this entire stack and make it work in the app. Then we actually had to basically pause for like a month to wait to launch it because

of some policy changes that need to be made, but it was really an extraordinary three month sprint. Look back on it very fondly.

Prateek Joshi (04:35.011)
Amazing. It's incredible how what we think of as huge, complicated products in the beginning are usually like they get shipped so fast and things that can take years sometimes they never take off. But this in what is a very compressed timeline, it has made a huge impact. taking a step back, if you had to explain data orchestration, why it matters.

in the engineering world to somebody who's not from technology. How would you explain it? Why do we care about data and data orchestration, especially in these massive products like Meta has Instagram and WhatsApp? So why does it matter so much?

Nick Schrock (05:24.514)
Right, so just to be clear, GraphQL was not a data orchestration product. That was a client server API. what Pratik is talking about is kind of the current project was called Dagster, which is a data orchestrator of the data space. So how to explain it? I think the way I would explain it, and you were asking kind of like to like, give me an audience. There's like,

Prateek Joshi (05:28.833)
Yeah, yeah. Yeah. Yeah.

Nick Schrock (05:49.922)
There's like my mother, there's like the MBA graduate who is not technical. What level are we going at here?

Prateek Joshi (06:01.507)
Yeah, let's go with the latter. Basically, you're at a tech company, maybe you're working on product or maybe you're in marketing, sales. Basically, you're not deep in data land. So how should they think about data orchestration?

Nick Schrock (06:15.34)
Got it. Okay.

Nick Schrock (06:19.584)
Right. So every company has a data platform. So data flows in from applications, from sensors, from external vendors, from your SaaS apps. There's all this stuff that needs to happen. And you need to activate and operationalize that data in any number of ways, all the way from building charts, building machine learning models, and even powering your applications. it is like the...

the lifeblood of every modern business now. These data platforms, the reason why I use that word is that there are tons of different tools that flow this data through the system. And the way to think about it is that all this data is computed. So all data comes from somewhere and goes somewhere. And if you're looking at your chart that is driving your business decisions,

Probably upstream of that in a complicated business are hundreds, if not thousands of other data sources that have been computed along the way. So in order to make all that work, you need kind of a conductor, an orchestrator that orders the computations, orders that this happens and this happens and this happens. And you need to be able to do that reliably. A fancy word for that,

is a control plane, but people generally talk about the orchestrator. Now, this process is very complex, and you're trying to model a complicated world. know, our take, well, I can go to our take later, but that's a, the orchestrator solves this ordering problem, and then on top of that,

it requires observability and debugging tools, because this is where things go wrong in production and where all the different stakeholders in system kind of have to get together, at least ideally, to debug stuff. So it's an operational tool, but it kind of serves to bring the entire data platform together to make sure things run on time and your data arrives in a timely fashion.

Prateek Joshi (08:39.117)
That's actually a good segue into my next question about Daxter. So you founded Daxter and Daxter, the open source project and also Daxter Labs, the company. As a starting point, what's the best way to explain what Daxter is, the open source tool, and then we can go into the company.

Nick Schrock (09:03.694)
So Daxter is a framework that enables people to create data pipelines and data platforms. So it is a Python framework. can install it on your local laptop. And you can start to put together these pipelines in code. Kind of our philosophy here.

is that it's very important to model not just the kind of the set of tasks that end up producing like the data assets that drive your business, but it's very important to model those assets themselves in software.

And that allows you to take a much more declarative principled approach to building data pipelines in the same way that Kubernetes was kind of an advance where you could declaratively say in Kubernetes, like I need this piece of infrastructure, this piece of infrastructure, et cetera, et cetera. You describe the end state you want declaratively. then because you give the system that much information, it can do all sorts of stuff for you.

In the end, what that allows you to do is that instead of just the orchestrator being one of many tools that you have to assemble together to get a cohesive view of your data platform, I know every dev tool and SAS observability tool says this, but we are that single pane of glass for the data practitioners. So they can in one spot develop their data pipelines, understand lineage, understand data quality.

data observability tools, cataloging tools, and so forth. And that might sound like it's like a bunch of products put to, you know, that's like overly scoped or something. But what's interesting is that when you model the assets in software, it's like difficult not to have those features because you need a list of your assets, right? The lineage just comes with the programming model, right? Why wouldn't you render it? So it's just kind of like the

Nick Schrock (11:19.554)
this sort of like consolidation of tools isn't like a forced marriage. like just, it naturally falls out from the abstractions. And that's really powerful for practitioners and data engineers. It just provides them like one view and also their stakeholders by the way, but that's a little another discussion. So that is kind of our take. In the end, the way I like to describe it is that we have three pillars.

of value here. One is productivity. So we really believe in software engineering life cycles and kind of previous iterations of orchestrators do not, right? They viewed this as pretty clearly as operational tools don't have a really productivity solution. So productivity. then we also think about scale a lot. We're built to be multi-tenant. I didn't really talk about that, but you know, these platforms that are heterogeneous, there's lots of stakeholders. You need to be able to

bunch of any kind of a federated approach there. And then three is context. We provide like unprecedented context on the data platform by having this core abstraction. And then that kind of like represents our entire life cycle from develop, deploy, observe.

Prateek Joshi (12:37.507)
Let's go into the product philosophy for a second. You mentioned assets a couple of times, and I want to dig deeper on that. So assets versus tasks. you talk about thinking in assets. So for listeners who may not have dug deep into data infra, how do you define an asset? why should they care about?

more like thinking in assets here.

Nick Schrock (13:10.41)
so an asset is any durable artifact produced by data pipeline that captures some knowledge about the world. Okay. That sounds fancy. Let's give a concrete example. A table in a data warehouse, a PDF report that gets emailed out. you can think of a dashboard as an asset, a machine learning model, right? Like a machine learning model in the end is a file that's put somewhere.

So those are all assets, right? And we use that term because it represents the reality of the heterogeneity of what's going on in these platforms. They produce all sorts of stuff. assets are the outputs of a data pipeline that is consumed by downstream stakeholders, whether that's a human being or another piece of software. So...

That is what I think modeling the asset is very intuitive, actually. Just think about this example. Some downstream person is querying a database table or data warehouse table, and some data is wrong. They don't know who to talk to. They might know a tool or something. Just the simple act of them being able to say,

hey, table users in this schema looks wrong. They can go and look up directly in Daxter based on what that table name is and understand why it's computed and all sorts of information about it. If instead you're in a pure task-based workflow engine and it's a scale, God forbid, where does the user's table get computed?

There's no index, no information. It's very difficult to trace, actually. So this simple example of you modeling your system in terms of in the language and concepts that all your downstream stakeholders think about is just very powerful in terms of that communication line. And the other thing, then, is that

Nick Schrock (15:26.24)
you have a new source of truth, the software artifact, which represents the asset that you can attach all sorts of metadata onto, for example, and then control all that with software engineering process. So imagine you're like, as a data platform provider, you're like, OK, every single asset that's marked with this tag, say it's like a gold tag or something,

also needs an owner and some cost information, other metadata. You can actually just run a test in your CI-CD pipeline to enforce that. And you do it at the source when it's written. And that dynamic is very, very powerful. And if you don't have that.

source of truth, software artifact that represents the data set or this machine learning model, et cetera. There's no place to plug in to do that. And then what happens with this policy stuff, ends up being enforced way down the...

the curve in some other tool, maybe some other team. Like people are like going around with Excel spreadsheets, manually tracking stuff down. It's insanity. so in a lot of ways by capturing the asset as a software effect, we're able to shift left a ton of processes, which is huge for productivity and management.

Prateek Joshi (16:51.331)
And also you have Daxter, have a thriving open source community and you also have a business to run. What principles guide you to figure out what features stay free, what should land in the paid offering and how do you balance that?

Nick Schrock (17:10.19)
Yeah, kind of divide it into three domains of complexity, so to speak. And one is technical complexity of code and in the framework. That is always default to open source. And that's both for conceptual reasons, but also practical reasons. Like if the code.

is coexisting with a user's code in the same process. Like we're a framework, There are the user writes Python code and then we invoke it. And like we share the same stack trace and all sorts of stuff. almost for practical reasons, you want it to be open source and installable by, you know, in a package registry and all that sort of stuff. But there's also just like the conceptual, there's also kind of the philosophical aspect of that where you want to, you want to,

solve technical complexity alongside your users. You want them to help you with integrations. You want them to give feedback on your stuff that's involved with integrations where the contract is a little more messy. So there's technical complexity. Then there's operational complexity. The way I like to think about it is that where there's operational complexity, where we can solve problems with massive economies of scale, that is good.

fodder for making a proprietary and hosted. Let me give you a simple example of if we have some complicated index optimized for performance and we need to recompute it, do schema migrations, do all sorts of complicated stuff, maybe like have like a secondary index and elastic search or something like that. That is very complicated to do and rolling that out to an entire community and expecting them to keep that upgraded. Even if we wanted to.

Like we would literally like all engineering would ground to a halt doing that. So I think the reality of that, like, you know, we're a small, lean, mean team. And, you know, instead of managing people across the world, upgrading their infrastructure to have like a search cluster and all this operational intense stuff, we essentially host it and we can roll out these changes extremely quickly.

Nick Schrock (19:33.676)
So, but people also want to run stuff, you know, to production, you know, for a subset of use cases to get started or, you know, midsize production deployments. want that too. It's not like we're not going to fix a bug in our Kubernetes implementation to like, you know, compel people to use the, use the, closed source product. And then finally there is organizational complexity. You know, SSO.

And all the kind of complex application ontology related to that are back and kind of enterprise features. And we think that's, know, it's squarely in the province of the commercial product. One, we've, you know, the reality of the business is that we need to, we need to have an incentive for people to use a commercial product. But that is also the type of capability that we think is much better centrally delivered. You can iterate on products dramatically faster.

in a centralized SAS format as opposed to kind of distributed it out to everyone. And we would never be, I don't think, it would be very difficult in my mind for us to deliver an RBAC product that's as good as ours in the open source domain because it's complicated and interacts with our servers in complicated ways. And we want to be able to fix bugs quickly and not force people to version upgrades and change management rollout. It's just too complicated for us.

So it's kind of a combination of like where our engineering resources have the most leverage and then where we have the right crossover points so that we can have a viable commercial product so that we can run an awesome, you know, our goal is have an awesome business and an awesome open source product at the same time. So, you know, there's also practical realities here.

Prateek Joshi (21:26.467)
That's amazing. Actually, that's one of the clearest answers of her because many times, that's a real answer, meaning many people are like, hey, want the open source to, they have the nice answer, but this is the practical business reality is that sometimes complex stuff, you have to bring it into the paid offering because even if you give it for free, just won't do anything, as you said. Now, in the early days of building the open source tool,

How did you get people to care? Meaning what went right? If you had to look back and say, hey, this is the one thing we did really right, which is why the community grew. Like, what is that? Or rather, what would you tell maybe somebody else who's trying to do that now?

Nick Schrock (22:18.286)
I'm trying to think if I have any novel advice on this front. I think there's a couple of things. One, be differentiated in terms of your messaging. Have a narrow audience in mind that you think would resonate to something, and then communicate loudly about who you're catering to and who you're not catering to.

because if the people who are potentially gonna adopt your technology, if they feel seen, so to speak, they will be willing to tolerate uneven experiences and missing features to get to that core kind of philosophical alignment. So I think it's very important to have a thesis around what you believe in and then communicate that clearly and loudly.

With the knowledge that you're going to exclude people, that's actually desirable. You don't want to attract people to the project who won't successfully engage with it. So in the early days, it was kind of a very simple message for us. It's like, software engineering process is incredibly important data pipelines. No other system tries to address it. If you think that instant feedback loops in your development workflow

and having good CI-CD pipelines and a pleasurable local development experience is critical for you, you should come take a look at us. So just like that sort of talk about why you exist in addition to, and this is different for different projects too. Like for our project, that was that. I like to contrast that with, well, we can get into maybe advice for founders later, but I'll talk about what would work for us.

That and then a combination of that and do things that don't scale is very important. That's kind of very traditional Paul Graham YC advice, but it's very true. You should be on the ground. It's critical to get fast feedback loops as quickly as possible, as early as possible in the development of any product.

Nick Schrock (24:38.046)
And often you have to schlep and work really hard and really spend a ton of time with those early initial customers or users to get involved. that means building rapport so they feel like they're participating in the process of development.

So that means you need to respond to feedback quickly, but then they're also willing to kind of roll with the punches on stuff. So I think managing those early design partners is super critical. And then you can leverage that to further success as they refer people and you can talk. And especially if there are people who will talk loudly about the product experience, that goes a long way as well.

Prateek Joshi (25:26.551)
And moving to Daxter Labs, the company, and today you have a business to run. Are there any community signals that you monitor that could perhaps serve as a good sign of, this is where the health is, and this this information, and I can use it to run the company? So what signals do you monitor that are helpful to you to run the company?

Nick Schrock (25:54.702)
It's a good question. It's kind of changed over time as the tools have evolved and the maturity of the product. Slack is kind of the central hub of where our community lives. So weekly actives is important on there. We have a chat bot in Slack where people can ask.

can ask questions about the product and get answers. Activity there is very important. Then it's also important to capture activity outside of Slack as well, because there's lots of people who want to engage in Slack. think views on your documentation is a very good, quite a good proxy, but maybe less so over time because of AI bots.

That's why I keep on mentioning the tools. The tools alter over time and affect what signals you can get. We use a tool called Common Room, which can aggregate signals from across a bunch of different social media properties. We also do lots of vibe checks, so to speak, on who's saying what. We found actually the data engineering Reddit, particularly high signal, because there's kind of...

real talk and people look at it. So we take feedback given there pretty seriously. it's like the place people look. There are literally employees at Dexter Lab that are like, yeah, I saw all these people raving about you on Reddit. that was very interesting to me. measurements, super hard. Everyone can be gamed.

So I do think you need to kind of take a holistic approach, which maybe sound like a dodge, but it is the reality of world. But those are just some of the signals.

Prateek Joshi (27:59.733)
Now going to the early days of getting paying customers, looking back, how did you get your first 10 customers? And more importantly, what learnings can you share? What went right? And what, if you had to do it again, what would you do differently?

Nick Schrock (28:19.886)
a good question. I don't know if I can come up with a good answer on the spot for you. I can tell you how we got our initial ones, and that was mostly just being high touch with the community. It was definitely all community facing. You kind of know who doesn't want to deal with their infrastructure and who wants the enterprise features. Like, OK, we need like we need.

We need Google off and we need integrations. We need integrations with some enterprise tools and RBAC and all these features. So you should kind of have like a customer list in the open source context. You just kind of know who you're first. Because we closed our first 20 customers in like two months or something. Like it was pretty quick.

Prateek Joshi (29:13.443)
Mm-hmm.

Nick Schrock (29:17.026)
We signed our first customer the end of December, I think, 21. And then we had 30 by the end of January, I think, or end of February, something like that. It was pretty fast. But then we of blew out our pipeline, so to speak, and kind of flatlined until we had

grew up. I think that was very critical. And then, know, it's a lot of like similar to onboarding the open source folks. There's a lot of schlepping at first, you know, especially we had to, you know, we have a bit of a complex infrastructure configuration because people need to run at least some of their data platform on prem.

And so we have this approach hybrid that makes it so that we don't see their code or their data, but we can still host a bunch of the infrastructure forum, like the web server and long running processes that keep everything alive. And a bunch of state metadata state. So that was kind of the story in terms of, I would need to reflect more on what we.

would have done differently. It was actually a while ago. So I feel like I would have to talk to, kind of shuffle through my memory and talk to the people who were around, you know, our head of sales, especially those days. You know, in terms of give, give a lot of flexibility in terms of pricing. In my opinion, I think like one thing we did is I kind of tried to

I, we tried to price the product in a way that like copied something like snowflake and just straight up usage based consumption on a single metric. but it didn't align with the way that the customers perceive the value of the system. and it also didn't align with our cogs, our cost of goods sold.

Prateek Joshi (31:27.043)
you

Nick Schrock (31:31.968)
And engineers are smart, and they don't like that. They kind of morally accept an upcharge on infrastructure, but value metrics are more difficult to justify. So I think really understanding, it helps a lot if you have a deep understanding in terms of how the customer perceives the value of the product and aligning your pricing to that.

instead of trying to optimize only for the business. And we weren't trying to do that for a selfish way. We wanted simplicity. We thought we had a pricing model that good for customers because was one single metric and you could easily predict it. But it didn't align with the way they perceive the value of the platform.

Prateek Joshi (32:25.283)
As you've grown the company from early days to now you've raised Series B or beyond that, how has the company culture evolved? Because as an open source, engineering heavy early team, now you're scaling, you're signing big contracts and go to market, like sales marketing, it becomes just more and more important. So one, how has the company evolved? And two, how has your own style of leadership?

evolved in the last few years.

Nick Schrock (32:59.95)
That's a broad question. I guess I'll focus on the company culture. Well, I mean, I think the obvious things, one is that the competition, the composition of the team changes a lot, right? Before it was like almost all engineering and some ops staff and product staff, almost all R &D. And now we have a substantial go-to-market organization, right?

We have somewhere around 80 and 90 head count and 30 % of, 40 % of that is engine R &D. So we have more go-to-market people than, than engineering folks now, which obviously changes the culture. You know, you end up, inevitably you end up being more metrics driven, at least a subset of the culture.

because there is like, like I was talking before about like, there's like all these different signals from the open source community and, know, and you have to take a holistic approach. Like, you know, once you're a revenue generating company in enterprise SaaS, they're pretty well-defined metrics that you optimize for and they don't lie. so, that instills a more.

discipline process and operational rhythm that inevitably ends up being aligned with quarters and the quota attainment schedule of your salespeople. Because it just is a rhythm that impacts the company. Sometimes you can nicely end from that, but sometimes you get brought in for stuff.

So one thing I really like about being in a commercial context is you actually, in a lot of ways, deepen your relationship with customers and users. you're in an open source community, it's often a little more abstract. You're interfacing through Slack or GitHub or other tools.

Nick Schrock (35:25.69)
and like, yes, you do webinars and conferences and stuff like that, but the relationship is different. Once you have sales processes, I love sales engineers. I think they're like an unsung hero of kind of these businesses. they are technical enough to know what's going on, but they are hand to hand with customers. So to speak, always tell.

You know, if a colleague of mine is kind of moving, say from like big tech to, you know, a, Deb tools company that has, that's a vendor, you know, a frequent piece of advice I give is like, go find the best sales engineers and talk to them. Skip the PMs, make sure to talk to them without the PMs around. because the sales, not that you don't trust PMs, they just will, the conversation will be different.

And especially if you ask the right questions, because the sales engineers know the truth, the good ones do. They live with the product. They see the emotional reactions of the customer. Like they don't have to try to go talk to customers. is their job. They run the demos. They know like what's these like. have the right S.E. who could have the keys to the castle for you. And you want to...

have a good relationship with them and you want to get real information on the ground. And I really like that level of engagement that happens once you have a, know, assuming you have a healthy sales process. And then the other thing you can get more metrics driven too, and you can actually do development faster, which is a little counterintuitive is that you have metrics on people, how people are using your product.

and you can ship it more quickly. So you can actually, and again, I think it's counterintuitive because you think, oh, you're shipping to businesses now and like you have to be more cautious and et cetera. It's actually better for everyone if you can ship quickly. You can ship bugs faster, you can ship features faster. As long as you have processes around it, you're not breaking the site all the time or something. So you can actually get to a more intense execution rhythm with better feedback loops.

Prateek Joshi (37:49.761)
And when you think about DevTool founders, what's the common mistake that the first time founders make when they're commercializing their work?

Nick Schrock (38:06.882)
Good question.

Nick Schrock (38:13.13)
I think building in public too early is a mistake.

You know, ideally, you are deeply embedded in a company, either employed at that company or as like a consultant or something, or you have an early design partner, and you're not beholden to change management in a community, and you can iterate extremely quickly.

Because once you start having open source dependencies and you have a big complicated surface area, people get embedded in their workflows and changing things becomes an order or two orders magnitude harder. So think very deeply about how you will maintain the speed of your feedback loops.

keep be very cognizant of what your, you know, to use a part of your one way doors are right. This is a Jeff Bezos thing. There are one way doors and two way doors and two way doors. You can undo decisions and one way doors. can't. And once you start shipping software to the public, there's lots of one way doors or maybe like one and a half way doors. It's kind of like a, it's like a rental car thing where like you can go forward and you're fine, but going backwards and you pop tire, right? The maybe that's a third thing.

Prateek Joshi (39:36.311)
right.

Nick Schrock (39:42.158)
the two-way door, but there's a trap. So I think that is one thing that I think is very important. think the other, one mistake I made is that I think at a certain stage, I stepped back too much technically. I kind of took the advice of,

Like, you got to let the team execute and you got to like, you know, think about strategy and recruiting only and et cetera, et cetera. I actually think that was a mistake. think like the, the, need a super strong product vision and to keep it cohesive. So, you know, I'm very much on the, Toby looked at, think speaks well on that, how like he kind of strategically micromanages the things he cares about.

And I would highly recommend that you continue to do that. you can't do everything. He has this great analogy. He's like, it's kind of like playing a real time strategy game where like sometimes you have to zoom in and go micro, you know, like really think about tactics and let it all burn down over here. Cause this is what matters to win. And then sometimes you zoom back out and think about resource management and like higher level stuff. And

Like good founders are able to like zoom in, zoom out, zoom in, zoom out very quickly and have a good instinct about where to engage and how to focus their time. And I think like if you're a DevTools founder and you have technical taste and your job is to communicate about the product, it's very important to like maintain control of the product.

Prateek Joshi (41:21.037)
This is amazing. And also to the point of the micromanagement, think Jerry Seinfeld in one of his interviews, he said something similar to the effect of the way we made the show is I micromanage every little thing from start to end. That's how we made the show. It was incredibly hard. It's painful, but if you want to get it right, it's just there's no way around it. And obviously you have to take a step back when it's time. But I think it's a very interesting point because many times

Nick Schrock (41:41.218)
Yeah.

Prateek Joshi (41:50.923)
As companies get bigger, as you said, there's a tendency to like, hey, got to know you, hire great people and let them do their thing. But I think the part B to that is like strategically at times you've got to go way deep and do the thing or else the company is going to just head in the wrong direction.

Nick Schrock (42:06.72)
Yeah. Yeah, it's like selective. You have to selectively micromanage and then you have to be explicit internally about what you're going to selectively micromanage versus not. Because you just can't do it on everything. And there's parts of the business where, you you kind of talk to the team and like, listen, I know what you do is really important, but our relationship is more of like a contract where like you're fulfilling this role and it's kind of abstracted away from me.

And then to this other team is like, I'm be up in your grill, like all the time. And like, if you don't want that, like that's fine, but we shouldn't like, let's have no illusions about that. Cause that's what I care about. And hopefully you're here because you want to work with me in that capacity, right? So I, and the other side is like,

If you want my personal love and attention all the time and every detail of your work, like it's not going to happen. Like I don't have like, you know, it's not my focus. it is incredibly valuable. You know, like I'm not, you know, that's kind of like me. And like, I have this good relationship, I think with our front end developers were like, like, I like the, the, the front end is like incredibly important to our product. It's what sells it in a lot of ways, but like,

Prateek Joshi (43:11.917)
Right.

Nick Schrock (43:28.426)
The front end architecture, it's like, guys, that's your domain. I know you're really good at your job. I don't have differentiated value there. So we're going to communicate about the product ontology and make that all make sense. But you have free rein on execution as long as things go well. But there's other parts of the product where I care deeply about the execution at a tactical level. So.

Prateek Joshi (43:51.651)
I think this is incredible. think your point about sales engineers and now I think being popularized as forward deployed engineers, I think is becoming, is in vogue. yeah, I think it's.

Nick Schrock (43:59.574)
Yeah, I know Palantir, right? We joke around about it. We're like, OK, every engineer at Palantir is Jason Bourne, you know?

Prateek Joshi (44:08.931)
Right. think it kind of the things you're saying, it ties very nicely to the central point is the tightness of the speed of the feedback loop. Whatever you do, the reason you have a sales engineer is that you want to know the pulse of the customer and also your other point. think so it's very for building a dev tooling startup, the speed of the feedback loops, it just matters a lot. I it just helps you iterate. No, this is amazing. We can keep.

Nick Schrock (44:34.733)
Yeah.

Prateek Joshi (44:36.387)
talking all day, but we're at the rapid fire round. I'll ask a series of questions and would love to hear your answers in 15 seconds or less. You ready? All right, question number one. What's your favorite?

Nick Schrock (44:45.678)
Let's go.

Nick Schrock (44:50.478)
All right, I'll limit it to the kind of business startup context. The Great CEO Within by Matt Mulcair. I don't like the title because it sounds too generic businessy, but it's an incredible book for any manager, think. Anyone managing up a CEO and for prospective founders to make sure that like this is what your life is going to be like once the startup grows. Are you down with that? And be honest with yourself.

Prateek Joshi (45:18.423)
Right. Which historical figure do you admire the most and why?

Nick Schrock (45:25.55)
It's a good question. I think my default answer for that is Churchill. I think he was the greatest man of the 20th century and saved Western civilization, which I care a lot about. So, but you know, that changes by the month. So I'll go with Churchill for now.

Prateek Joshi (45:43.874)
Yeah, is a yeah, think his story is fascinating, especially in his formative formative years and in South Africa, the Boer Wars. This is a great book. Yeah, his story is fascinating. All right. Next question. What has been an important but overlooked AI trend in the last 12 months?

Nick Schrock (46:03.52)
Have there been any overlooked trends? I think it's kind of hard to answer. I literally, my entire world is full of AI. I'm gonna have to take a pass on that one, because I think like, I feel like every trend is looked at, but.

Prateek Joshi (46:21.475)
Right.

Every trend is, yeah, looked at too much and analyzed in great detail. Maybe a different way to ask the question, what AI advancements are the most exciting to you, the more recent ones?

Nick Schrock (46:28.407)
hehe

Nick Schrock (46:39.79)
So I think, so the most exciting ones to me, I am very excited at how the application layer is going to develop over AI. Like the foundation models and the chatbots are like incredible. And that, but kind of everyone sees that incredible. I think there's a ton of innovation to do in the application layer. I'm supposed to do this in 15 seconds, right?

So like the one I'm living with right now is that I'm kind of a little late to the party cloud code adopter. And I think cloud code is pretty amazing. It's kind of an application layer over the core models that speaks to me as a more experienced software developer. I feel it's like a bridge tool for late millennial Gen X software engineers to AI. Cause like I'm practically a boomer when it comes to this sort of stuff. the, yeah, I'm, I'm very excited about the AI.

Going beyond the chatbot interface is what I'm excited about. I think would be the long and short of it.

Prateek Joshi (47:47.585)
What's the one thing about data infrastructure that most people don't get?

Nick Schrock (47:54.422)
I think that most people don't get. Everyone is very tempted or so interested in all these scale problems and data scale. But I think most people get about data infrastructure that now the big challenges are massive complexity scale and managing all these different stakeholders. Again, it's kind of like application level.

In some ways, a lot of the info problems, not all of them, think there's a lot of startups pushback are like more solved than these like higher level concerns. Um, so I think, I think the most evaluated deliver is, or a lot of it is in the application layer.

Prateek Joshi (48:37.687)
What separates great AI products from the merely good ones?

Nick Schrock (48:42.478)
For me, transparency and control. So a very simple example is I really like Diamond, which is Graphite, which is a code review tool. They have a kind of a code review bot and it's very transparent and very scoped of what it claims to do. And I think that's a great way to get broader adoption and also get, cause like whenever AI,

product feels like a hallucinating demon, you like lose all trust in it and you just want it to go away. So I think these like the great ones have trust and control so that you can like be empowered rather than terrified.

Prateek Joshi (49:25.802)
It's amazing. The CEO of Graphite, Merrill, he was on the podcast a couple of months ago. So he would be happy to hear that Graphite is being used as an example here. All right, next question. What have you changed your mind on recently?

Nick Schrock (49:33.206)
Yeah, yeah.

Nick Schrock (49:42.926)
I guess, sticking to the AI theme, I was very skeptical about the ability of AI tools to contribute to production code bases. I have flipped now, think that properly conceived of, and I think there's a lot of undiscovered country here, that they will be instrumental in even large systems going beyond vibe coding.

Prateek Joshi (50:07.075)
What's your number one advice to founders who are starting out today?

Nick Schrock (50:13.208)
Be in person until product market fit.

Prateek Joshi (50:16.739)
That's amazing. That's brilliant. And I couldn't agree more. You got to like just be there and yeah, that's great. That's great. Amazing. Nick, this has been a brilliant discussion. I love the depth of the answers on both the technology side, but also just the founder company building side. So thank you again for coming on to the show.

Nick Schrock (50:35.564)
Yeah, no, I had a great time. Thanks so much.