The Data Stack Show - 221: The Art and Science of Technical Leadership in Early-Stage Startups: Building World-Class Engineering Teams from Scratch with Sokratis Vidros of Novu

Episode Date: December 24, 2024

Highlights from this week’s conversation include:Sokratis’ Background and Journey in Data (1:19)Engineers Wearing Multiple Hats (2:17)The Era of Early Startups (3:32)Lessons from Building Software (7:15)Importance of Team Dynamics (9:12)Balancing Creativity and Stability (15:00)Version Control in Data Analysis (18:57)Opinionated Modern Data Software (21:14)Creating Dashboards for Company Stats (22:41)Hiring for Intuition in Tech (27:38)Interview Process Insights (30:15)Protecting Intuitive Thinkers in Companies (35:08)The Challenge of Trust (39:21)Loss of Control in Delegation (40:14)Founder Work-Life Balance (42:15)Advice for Early-Stage Engineers (44:03)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Hi, I'm Eric Dotz. And I'm John Wessel. Welcome to the Data Stack Show. The Data Stack Show is a podcast where we talk about the technical, business, and human challenges involved in data work. Join our casual conversations with innovators and data professionals to learn about new data technologies and how data teams are run at top companies. Welcome back to the show.

We have a special guest, Socrates Vidros, who was on the show three and a half years ago. We always say that we like to have people back on the show, John, but we actually do put our money where our mouth is. And sometimes that's a lifetime in software. It is a lifetime in software. In episode 43, I think it was. Episode 43 in July of 2021. So Socrates, welcome back to the show after three and a half years. Hi guys. Glad to be back. Time flies. We thought it was like two years ago, but like when we...

I know, I know. Oh my God. All right, well, give us thec. We just started with the team. We're, I think it was a very early days when we're building the first version of the software. Today, funnily enough, I'm involved in another early stage startup in the notification space called Novu. And I guess he actually caught me at the exact same state.

So it's just going to be a repeat of the previous show. I mean, Clerc did great. So I consider going to be a repeat of the previous show. I mean, Claude did great, so I consider this to be a great coincidence. Yeah. Well, yeah, you're three years wiser now, so we're interested in hearing about your lessons. So

speaking of topics, though, I really want to dig into, we've hit this theme a lot on the show recently, but we want to dig in with software engineering best practices and data best practices. We feel like there's a gap, but the gap is narrowing, so we're going to dig in on that topic.

What's a topic that you're interested in digging in on? I think the other interesting topic is basically to talk about the need of engineers to wear multiple hats on a daily basis basis meaning sometimes they have to be the product sometimes they have to be the tester sometimes they have to be both especially in early stages where i kind of specialize the need there is very strong

love it well let's dig in all right sounds good socrates it feels what does it feel like to you a year it feels like maybe a year and a half yes yes three and a half years exactly in startup time this is a lot of time yeah totally so i mean you and i both have gray hair the listeners can't see it actually no i have more gray hair than you at least you know from what it looks like i have what it looks like. I have them on the side. Yeah, I have them on the side. Okay, so for the listeners who didn't catch the early episode three and a half years ago, rewind back to the beginning. You joined a startup in Greece that became very successful,

and that story has actually repeated over and over. So I want to start at the beginning. Where did you begin your career in tech working for a startup company? So I started my career in a very big company, but that didn't last long. And then I joined an early stage startup in Greece, being the second engineer in the team. And at the time, it was around 2012. Yeah, it was the end of 2012, beginning of 2013. It was the era of GitHub, Spotify, Shopify, HubSpot.

It's pretty wild time. Yeah, you could go- Winterhouse, Benchift. Exactly. Like these kinds of tools, like the second generation of online SaaS, of cloud SaaS. And at the time we were in the HR space. The company was called Workable.

It started along with other companies like Rippling, Lever, Greenhouse. All of these companies started around that time. It was the Ruby on Rails. That's a great point. It's like so many Ruby apps. And then my sense is that they all faced a lot of pain at scale when they actually became successful.

Oh, yes. Exactly. Absolutely. And the trajectory there was super interesting at the time because it was a great school. We had to do everything in the beginning. And when I say everything, I literally mean everything. And we had to do it from Greece. That was an extra challenge for us because at the time the company was fully Greek.

Like the team was a bunch of Greek folks from Athens working remotely, trying to make a worldwide and world-class product. I stayed there for almost seven years. Then I tried to repeat the story with Clerc. The head start of Clerc was supposedly easier because I worked with the two co-founders from the States that were brilliant people. But it was a devools space that significantly harder. It's way more exciting when it comes to tech. But in order to build a business, a sustainable business in the DevTools space, it's 10 times harder than the Vertica SaaS.

But still, we did it. And Clerk right now is growing. It's one of the fastest growing dev tools in the Bay Area. And guess what? Then I was like, you know what? I'm going to do this again. Yeah. Third time's a charm.

Well, I love how you just glossed over like, I was there for seven years and then, you know, it was like, well, that's actually a long run. And if a startup survives that long, like, you know, I'm sure a lot of our listeners actually probably like log into workable to you know manage their you know manage their hr stuff

at their job and so that's pretty wild that you joined as the second engineer yes yes it was actually pretty good and it was you know at the time we like, the key thing is what happened in Workable is that we managed to reach to this milestone of 1 million ARR that according to YC textbook is a very pivotal moment for every company. And we managed to do it like it was, again, a bunch of folks in Greece did that in two years and nobody understood how. We're just doing our jobs and it happened. did that in two years and nobody understood how. Yeah. We're just doing our jobs and it happened. Yeah. And in order to get to the same point

at Clerc and now in Novel with way more experience Yeah. It goes against the DevTools significantly harder. Yeah.

So the I mean one thing that's certain is that I really enjoy this path to the first million. As I call it, creating value from zero is the most exciting part of any startup.

Well, what I'd love to do is, on the show we've talked for years now, and I say that because you know that better than anyone, being one of the very early guests, about how the world of data and data workflows are adopting and have adopted software engineering principles. And so one of the reasons we are so excited to have you back on the show is that you've built software at multiple really successful startups, starting from the beginning, going to large scale. And so there are so many lessons there, I think, that we can take away. And so I'd love to just dig into a lot of the things you've learned

building a software and to talk a ton about software because I think there are so many lessons that we can glean. But where I want to start actually is when we were chatting before the show, John, you asked an amazing question about Socrates' ability to pick the winners. Yeah. I think a lot of our listeners, if you're a developer, data engineer, anybody in the startup space, you're like, okay, I'm in this job and I'm looking for the next things. How do I

find a place where it's a good environment but the startup's going to be successful? Because obviously the failure rate is really high. And you work really hard. You don't get paid as much as you could at a larger company. So finding something

that's going to be successful is a big deal. So there's no formula for this. We'll start there. But maybe some trends or observations from you, Socrates, as you've done this multiple times now. And are you taking limited partners for your fund? Yeah. We're getting there. We're getting there, hopefully. The truth is that there is no formula. And as you said, the failure rate is I think it's more than 90%. It's extremely high. As we said before, it's all

about the team. A high-performing team will have to tackle very strong technical challenges, no matter of the vertical and the function of the product. And if you find a team that can actually build anything and can build good quality world-class software,

you basically maximize the chances of the startup succeeding. I mean, this is the recipe for success. And we have to take into account the fact that we will interact with these people for eight to nine to ten hours a day.

In very early stages, maybe more than that on a daily basis. We have to get along. We have to, in very early stages, maybe more than that on a daily basis. We have to get along. We have to, in very early stages, it's very important to say one thing, understand 10, and bring back

20 to the project. Communication can be actually automation around communication is the most important thing. Without processes, without tooling, we don't need all that stuff in the beginning. You just need to be able to work with people that basically get you.

And you get them. Can you break that down a little bit? Sorry to interrupt. Can you break that down? You gave sort of a multiple framework there about communicating at a certain level. Can you break down that framework and maybe give an example?

And that like extract, what's the right word? Yes. Extractability. Extrapolation? Yeah. Extrapolation. Extrapolation. There we go.

I mean, at first, let's actually, I'm going to tell you exactly what happened in Cleric and I think this is kind of a framework you're looking for. Sure, sure. So let's say you start with the one confounder. Let's say you are the confounder, you're one of the founding engineers and the founding members. The first thing you need is you need to find one or two people that basically can be your left and your right hand.

And you can basically trust these people and work with them really nicely. The key thing to look at that point is not necessarily the technical expertise, which is obviously very important. work with them really nicely. The key thing to look at that point is not necessarily their technical expertise, which is obviously very important. It's their ability to solve problems and their ability to basically come up with the right solution,

even if it's not the right solution in the first take. Like they're looking for the intuition. And this is very important because the moment you have, let's say, more than four or five people, these people create the gravity around it. And then they can attract similarly minded people. Yeah. And this is going to magically free a lot of your time a company, you will never get to build the right product. Usually startups start from a project, then they go to the product phase, then they go into the company phase, and then they are trying to make a business out of it.

It's very dangerous if you're trying to jump from the project and go directly to the company. You know, bring a lot of people, bring processes, bring communication problems, add all this overhead without actually having the product. This is a very big, big danger. So yeah, you bring these people, then communication just happens. And then you just take it from there. To me, everything is a framework. Like when I work with engineers, I'm usually very hands-on, especially in the early days of a project

because I don't want them to think about their daily work in the long run. What do I mean by that? Usually in the backend, things are way more, especially also in the data space, things are way more well-defined. So you're using a framework,

Rails for old school folks like me, or Next.js or Remix for the backend for now. They are very well-defined, so you know how to write your routers, your APIs, your handlers. But there are some areas of the project, especially in the frontend, where people can go wild. We still haven't figured out

an architecture that just works. And it's very important to sit with these folks in the early days, work with them, and tell them that consistency is above everything. Like we might have a pattern that we have already adopted. It's working for us. It might not be the best, but if we don't have to think about it every time we work with it in the framework, we just got back time.

And time is the most valuable thing in those early stages. Wow. It's such a leverage point too, because I've seen this working with teams where you have a personality that actually works great in the startup phase, or even just say you're starting a new project. They're the one you want.

They've got the creativity. They're going to like very good at solutioning. But sometimes paired with that personality is I'm going to solve this problem differently every time because it's fun versus like I'm going to be most leveraged and like use existing solutions

reuse code that's not quite as good as it could be and I think that's such a challenge correct correct and it's not just fun it's because engineers get bored very easily and it's like a game like It's because engineers get bored very easily. And it's like a game. Like if you solve one problem one way, you conquer that solution. Yeah.

And then you're not satisfied. You want another solution. Yeah. And again, I mean, I always make an analogy. My sister is an architect and I always like, I really like real estate business in general. Like if I wasn't doing what I'm doing, I would do real estate. And I always make an analogy. I'm like, imagine a builder that has to build a hundred houses,

and every time they want to build them differently. They use different techniques. They use different types of cement. They use different types of wood. It's not just saying, you know what, this works. Let's just build it, take the money, move on to the next one. Engineers have this tendency, and some folks might say that this kind of kills creativity in early stages I will say that

maybe you need to kill it a little bit a little bit it's so funny too you have to find the right person to want to work at a startup that will give away some of the stability and money of a larger company so there's that and then maybe they tend

toward being more creative and they want to take more risk in general. But then you need to tell that person like, oh hey, actually I need you to move towards stability and reuse things and not reinvent the wheel. There's a lot of tension, right? Pulling into that, I think.

Yes. That's why it takes a very special type of character. Not a technical skill set. It goes into the soft skill space. It's the kind of engineers that want to always touch base with reality. So it's basically, they have to engineer their way of engineering so that their output is always optimal based on the current state of the company.

Because this thing is going to change. The moment the startup becomes successful, they will get back time to become more creative again. They will get back time to clean up things. But then on the other hand, you don't want them to just commit very messy and record in the beginning because they're going to have to face it very soon and then the product will be crappy and will be sloppy. And right now, especially around the web, the expectations of the community have been sky high.

The amount of polish we get on recent software is just insane. Gray forms with gray buttons are not cool anymore. Yeah, yeah. John, can I ask you to react a little bit to that, you know, leading data teams? And you've been exposed to software, but you've mainly led data teams. And one of the interesting things, Socrates, you mentioned is sort of the frameworks you use, you know, different programming primitives that you apply. One thing about data that's interesting is it by nature is a lot more exploratory. So if you're leading a team of analysts, there may be a number of different ways to solve a problem that are legitimately more exploratory

than maybe some of the programming primitives that you want to align an engineering team around. So can you speak to that a little bit in terms of how do you apply some of those principles in software engineering of like, don't get cute, like, there's a way to do things? Like, how do you do that with a data team? Yeah, I mean, I think it's I think the similar like tension is there for data teams. Like, for example, one of the companies I worked for, pretty much the entire pitch of the company is, hey, we'll take your data and we will help you optimize your company based on your data. That was basically what they did. So then it's like,

okay, well, we need some really creative people that have domain knowledge that can dig into this data and find inefficiencies and present optimizations. Like, okay, sure. So then we'd have those people and you'd hire them and then they would and this was like 10 10 12 years ago they would immediately like down so download microsoft access and then like write a bunch of macros and like create a little kingdom right it's like all right well maybe we don't want to do that so then you like try to centralize it and and move it yeah so then you try to like centralize it and move it and like have a centralized team

and be like more of a proper quote company like quote do it the right way. So then you but then you end up with people that like don't have the domain knowledge they're not as creative

they're like we got to do things the right way they move a little slower they tend to get misaligned with the business on what we're actually doing that creates problems. So I just

I think it's a very hard problem to solve i think the the encouraging thing to me is seeing the technological process over the last 10 years where the the guy that would tend toward like i'm going to pull my microsoft access database or whatever like there's more convergence of like okay cool like there's some modern databases that are a little more accessible than they would have been 10 years ago to more of an analyst type persona. And then some of the ETL tools, some of the other tooling all is getting more accessible to more of an analyst persona.

So I think that's positive, but I still think it's a struggle even for people that are truly like an analyst to stay aligned with the business and stay aligned with value creation and not just get pulled into like, hey, this would be really cool. Or hey, like, look at this thing we can do and just kind of be misaligned. Yeah. Socrates, anything to add there? Actually, you remind me of a very fun story. When we started coming in Workable at some point, we started dealing with a lot of candidate and job data.

So the numbers started becoming very high. And we assembled a data team without data engineering. And one of the biggest challenges we had at the time, that was about eight or nine years ago, let's say, was the fact that they were analyzing the data, were coming up with conclusions

and they never had repeatability because everybody was running their own scripts from their own laptop. And one of the big wins was basically, guys, there is something called version control, like you can do this in GitHub and we can know exactly,

we can basically run the same experiment again with different data or the same data, make sure that the results match and they check out. And it was a real struggle at the time to enforce this pattern. That's a very strong soft congenial pattern. I don't think any developer nowadays knows how to work without GitLab. Sure, sure, yeah. What clicked at the time was Jupyter Notebooks.

It was the time that they were becoming popular. And they had a notebook that they could actually write was the time that they were becoming popular. And they had like a notebook that they could actually write everything there. And that was actually what unlocked that very simple, very simple solution

to a very big problem. The other thing I see nowadays, because, you know, all of the companies are tempted to use AI, is that right now we have a different thing. Like I don't,

like companies that have to do with a lot of data, we still have data teams, but the reality is that early stage startups, they just delegate all the data function to AI. And AI right now is a commodity. It's an expensive commodity. That's an API call away.

So I see a lot of early stage companies like building good products like good early stage products using AI and presumably being heavy on data with just offloading all the data

to an AI software and to an AI analyzer so that's also another interesting aspect and then of course

the modern data software has become very opinionated and I actually because I'm not a data person but this is what I love about the modern data software has become very opinionated. And I actually, because I'm not a data person, but this is what I love about the modern software around data is that I don't buy the software anymore. I buy their opinion. Yeah. Yeah.

So I don't have to think about it. Like, I don't want to think about it. You know what? I just want to give the data, basically let the software guide me. Can you give an example of that? I'm so glad you brought this up. Yeah. Yeah. I actually want an example of that? I'm so glad you brought this up, yeah. Yeah, I actually want an example of that from you, Socrates, and then John

as well, but what's an example of that? What opinion are you looking for in a data tool? I have a recent example. I was using a tool recently called Hextech. Oh yeah, Barry McArdle, the CEO has been to the show a bunch of times. Great company.

I found this tool very nice, especially for early stage companies, because an engineer can use it, a product person can use it, anyone can use it. And it basically eliminates this early stage problem of, okay, everybody wants to track everything. Then there's a bunch of warehouses, like there's your main database and maybe another database and maybe a cache and maybe you also send the events to a tracking software and then you have Google Analytics and you have Google Tag Manager

and all this kind of stuff that requires a lot of time to print together. So what I liked in Hextech was the fact that the software was delightful to use. It had some issues at the the fact that the software was delightful to use. It had some issues at the time, but overall it was delightful to use. It was very easy to bring all these data sources together and us write the Jupyter recipes. It's very similar to that.

They don't call them Jupyter recipes. I don't remember how they call them, but it's a very similar concept. So that we can basically publish a dashboard to the company and say, guys, these are the stats of the company. This is the dashboard. This is the graphs you need to care about. Bookmark this page. Open it every day and see if your work makes them go up.

Because this also brings us back to the previous topic of the conversation, like the early stage startups. You usually need these north stars in a graphic format so that the engineers see them and they actually get hyped, they get pumped. I want to push back on that a little bit. Before you said that

you like software that's opinionated, but when you described Hex, which I agree is a great product. We love Hex and they're great friends. But like, what you described wasn't opinionated. It just sounded like an amazing product experience. Like,

it was, I mean, they have some, you're actually right. It's not that opinionated when it comes to what they need to show by default,

but it's very opinionated on how they aggregate the data and how you can build a report out of it. It like guides you down the right path. Like it has an opinion of the path you should take.

Exactly. Otherwise, I can bring 10 engineers in the room and tell them, guys, we have 10 sources of data. What do we do with them? How do we create them as well? Okay, got it. I will come up with 10 solutions at the end of the day. No, that's super helpful.

Yeah, that's fascinating, actually. It's not what you would think of at first. Because what I think of, there's super helpful. Yeah, that's fascinating, actually. Yeah, it's not what you would think of at first. Because what I think of, there's two kind of categories, in my opinion, of opinionated software. One is domain-specific, like I'm going to run an HVAC company and it's very opinionated on what to do. The other is what I'm thinking of, in this case, is technical guardrails of here's all of the things

in the right like stack all the things pulled together whereas if you throw an engineer on that like i'm going to grab some like d3.js and i'm going to use like plotly here i'm going to use like a notebook here like you just end up with like yeah totally yeah totally no that's great we need to let barry know about the show yeah and ask him for some preferred shares. Yeah, yeah, yeah. But yeah, but I think, I mean, in the vertical space, this is more obvious. Like for example, let's use Workable as an example. Why do you use Workable initially? You use it because you have a need in HR, like you need an HR department to begin

with, but you can actually use it if you don't have an HR department in order not to get one anytime soon. And this is also very important. It goes a little bit into the buy versus build discussion. Linear is another great example. Sure. Like, to me, okay, apart from linear, linear is extremely polished as a product. But if you think about it in another space, that's extremely condensed.

How many project management tools exist out there? Right, sure. Hundreds. And all of them are successful. All of them are in business. But when they joined the game, especially for engineers, the key change was two things.

First of all, it was built for engineers and technical teams. Right. But first and foremost, it wasn't configurable. They sell the opinion of how the pipelines look like.

Yeah. Yeah, yeah, like yeah I love it on the other hand Trello or Asana or or the worst Monday which is like literally

or Jira these tools can configure everything even the color of the border but at the time like I don't I don't need that especially in early stage startups I don't need that I just need something

that works I don't have to think about it I buy it I use it and I'm happy right yeah okay

I have a question for both of you actually and this is jumping back I guess I don't know 20 minutes in conversation but

Socrates you made a statement about intuition that I think is really important. And I think it's critical. I think it's critical generally. I think it's really critical in product and engineering and data as well. And it's this ability to understand the context and to make the right decision without all of the information, right? I mean, intuition's a much more elegant way to say it, right? But people who have a really good gut sense. And so if you can find someone who makes really good decisions from their gut, not perfect, but like then you can trust them and you can delegate things to them, which ultimately gives you leverage when and leverage is time to your point. You know,

Socrates, like which is absolutely invaluable. OK, I think probably most of our listeners have had a taste of what leverage from intuition is like. Working with someone where it's just like, why do I love working with this person? Well, I love working with them because I don't have to share much for them to understand the right thing to do, right? And that is

so wonderful. Like, communicational leverage. Totally. It's just so wonderful to, like, share a couple Slack messages, wonderful. Like, communicational leverage. Totally. It's just so wonderful to, like, share a couple Slack messages, like, yep,

I got you, or, like, hop on a five-minute call, right? Not, like, a 45-minute call where I have to explain everything. That is just,

that's what everyone's shooting for. Okay, so here's my question. How do you hire for that? Because that is so difficult, but, Socrates, you've clearly been successful in doing that multiple times in a row. So I want to know, what are your secrets? And if there are no

secrets, then what are your guiding principles for hiring through intuition? And then John, the same for you, because I think you've done the same thing well. Zolan, you want to go first or should I? I'll go. Okay. I don't know. I don't know if I have any secrets though. Yeah, I do have a secret actually. Ooh.

Find a way. You just can't always do it. Find a way to work with the person prior to just get a really good sense for them. For example, yeah. So if you're at a company like i've been really successful like stealing people from other departments or roles for example and i just like boating boating yeah basically poaching intro coaching yeah or or just like hey i want to work on this project for you with you i i just i'm sure there's people that

are like really great at like the interview format and like sussing things out via that. I just, I at least personally like you can learn some things, but it's just hard. So my only secret would be like, find a way to like get them on a temporary project, get to know them from some other like angle. Linear does maybe a better job than any other company I've seen around this. I just said this because someone who I used to work with very closely here at Ruddershack, now is on the product team at Linear,

still a very close friend. We text and talk on the phone all the time. But it was a super intensive interview process, you know? Was there like project work? Oh, totally. Yeah. Like a week of intensive project work. Okay.

Well, there you go. Yeah. You know? Yeah. Socrates. So I have two secrets. The one is very relevant to software engineering. The other one is not.

I'm going to start with the easy one. So in general, yeah, Liner does this and I like the strategy, but in general, I prefer the opposite direction. What do I mean by that? I don't like assignments when it comes to the hiring process, and I hate live coding sessions because I've seen great engineers doing really poorly

and they're under stress. I agree. Oh yeah, because it's not replicating the actual... It's not simulating replicating the actual environment, for sure. Exactly. You're going to never code with these very strict timelines and you're going to never code with a gun over your head.

Your bot isn't looking over your shoulder because you're trying to solve a problem. I hope not. Right. Exactly, exactly. And also it's a profession of craftsmanship. It's like going to a painter and telling him to create the next masterpiece

in the next 30 minutes? It doesn't work like that. So my secret is that I do an interview process that I have like two goals. There's always a technical interview that lasts one hour. And when we join the interview, I always tell the interviewer, there's one thing I want us to get out of this. I want on both sides to understand if it would be nice for us to work together. And I also want you, I want also me and the interviewer to learn at least one new thing out of this process. Like I want you to teach me something and I want you, I want to teach you something that you didn't know. And the best way to do that is that I usually start, it's a technical interview, right?

Strictly technical. They never have to go live. But I usually start with what problems do I have in the current company, in the company that I'm working for this week. And let's try to solve them in this hour. Let's talk about it.

So I always take a problem for production. I always take a design meeting that we had two days ago. So I use real-life examples and I start analyzing with them. And as I do that, I also inject technical questions. For example, let's say that last week we're designing or building, I don't know, a search functionality. I'm like, okay, let's imagine that we have this website

and we want to build a search functionality. What's the first thing that comes to mind? Like we start with open-ended questions and then I'm like, okay, based on the answer, I'm like, okay, how would you do that? What's the technical challenge? But the database, how is the database going to look like? And usually in an hour, we talk about one or two features, but it's enough. It's enough to see if the conversation has flow, it's a very good indication that we're getting there. That's one thing.

The other thing is that I usually sail a lot and I like everything that has to do with this in sailing especially. So in sailing, I had a teacher in the past that used to say that when you sail

and you need to make a move, you need to change something in the sailing boat, you need to think about before you do it, you have to lay a sequence of actions in your head

and think of all the possible outcomes. Like it says, but not intensive. Sure, sure. The reason you have to do that is because at the same time you're fighting the elements. Like it can be a very sunny day, but it can be a windy day as well. So you have to find the sea, the sun, and the wind at the same time. And usually if you do something that's not the right move, one of the elements will basically... Tell you that very clearly. Yes.

And at the time you get stressed. And if you haven't rehearsed this beforehand, you're not going to make the right collective action. You're going to make the situation worse. So I also try to apply that. And that's why I have another motto that says, guys, let's spend more time on paper when we build something

and when we talk about something rather than code. Because if we spend the right amount of time on paper without, I mean, that doesn't mean we're going to spend six hours designing, then things in code will flow. It's going to be much simpler. It's going to be way easier for you to figure out things.

And this applies both in the interview process, but most importantly, when we work. So I try to find people that have the skill that they can actually play. They can run the algorithm. They can run the solution in their head and come up with good and bad scenarios. Okay, I have a follow-up question to that

because this is, I think, a challenge probably for a lot of our listeners. I totally agree with you. And when we spend the time up front doing the hard thinking work, or at least on my teams, we talk about doing the product work, which for us is really sitting down

and thinking really hard so that when we put a requirements document together, you know, everything else flows from there, engineering design documents, and then eventually code. The challenge with that on a practical level is that you have all these internal stakeholders who don't appreciate the value of that time.

Oh yeah, absolutely. So so, and I mean, I know, you know, in your experience, Socrates, there's no question that you've experienced that, right? And like, John, of course, for you, it's like, well, it's just a dashboard. It's not that hard, right? And it's like, well, you know, so how do we manage that? Like, how do we manage the need to protect our best intuitive technical thinkers and developers, right? But first thinkers, then, you know, then engineers. How do we as managers help protect that for them, but also manage stakeholder expectations?

That's super hard. This is extremely hard, especially in early stage companies. As you said, like this phrase of it's just X. It needs one hour. It's two hours. Just do it. Don't do it. It's a dangerous path.

And the truth is that the best secret is just to ignore it. It's very hard because usually… I love that. But you don't have to ignore it too much. Like, because you're working on thin ice, because usually the person saying this is your manager, usually. You're being pulled into 20 different directions,

but usually it comes from the upper level. One way to basically tackle this, I mean, you kind of ignore it a little bit, but at the same time, you have to keep something back. So you have to demonstrate progress. In early stage companies, there's two things.

You need to timebox. You need to do this process for sure, but you need to timebox it as well. The other thing is that you need to understand that in the very early stage, there should be usually one or maybe two people in the room that have the vision. And because it's early stage,

usually there's no right or wrong because you have built pretty much nothing yet. So if you build anything, if you do it good, it's probably going to be okay. It's going to resonate with somebody out there. And then you do this again and again. One of the most challenging parts of this, on one hand, it's what we've said. Upper management is asking about this yesterday.

But on the other hand, I've also seen a lot of people, especially in real estate companies, trying to find the optimal solution and do user testing and get aggregate data. Like guys, we're an early stage company, we have zero data and we have 10 customers. Like there's no statistical gravity to what we're trying to do. Like it's just people

using the software. Just build anything and make sure you build it good. It's as simple as that at the end of the day. But it's very hard. Like when you're in this thinking process, it's very hard to get out of it and think that, okay, let's just build it.

Let's just build this. Yeah. I love the time boxing thing. I think that's very helpful. And I've also noticed that I often have people on the team, you know, assuming it's a team of multiple people, you will have some people that are just natural, like craftsmen, like that's just their like approach. And that's really good. And I think you can also have some really good people that are like really good problem solvers, really good. They're, they're're really fast and if you can mix that the right way and even like because and even like and there's always trade-off decisions being made so we're like i'm gonna put the craftsman on this because like this is the right fit i'm gonna put the you know generalist the person that's like really fast and like kind of good enough on this

like i think there can be a little bit of give and take on that. I agree. I think the other thing that comes to mind for me is that it's easy to think about management or business stakeholders. We often cast them in this light of they need it yesterday and they're never satisfied.

I think what's actually true is that most, not all, but most are actually more than willing to trade time for impact if they trust you. Right? Yeah. Yes. Yes. Absolutely. And that's like, I think if you can build that credibility of like, look, when I deliver something, it's going to have impact. And what I'm going to ask of you is that you trade some time expectations for that. If you do that and someone, if you deliver on that and someone builds trust, that can create a great dynamic. And I think most people are willing to make that trade off, but I don't know. I think the unfortunate part here is that most people's experience is that like as a leader is like if i push i know i can get this done faster and i've never actually

seen it get done better if i didn't push i think that's i think that's most people's experience that's a great point yeah they don't actually know what the result of a craftsman doing their job right and that could be that they haven't worked with like some really great yeah before Great point. Yeah. They don't actually know what the result of a craftsman doing their job is. Right. And that could be that they haven't worked with some really great people before. That's a possibility. Or it could be that they just have this locked into this mentality where they've never given the great people a chance. Interesting.

Yeah. Yeah. Yep. And there's also another side of this. So imagine that you are building something from scratch. You're probably one of the co-founders, but you actually delegated the part of this initial product to somebody else. At this point, if basically you give them what they need

and that's effectively time to get back to you with a solution, as you wait, you're pretty much doing nothing when it comes to that. This feeling of, I have no control. I don't know if there's progress. I'm actually incapacitated. I think this is another drive that makes this kind of request

like, okay, but I need it and I need it now and I need to do it fast. And to an extent, because I've worked with technical co-founders who were not technical co-founders technical co-founders with non-technical co-founders in the past, especially from non-technical co-founders, this is a very big problem

because they, first of all, they don't understand the size and the scope of the work that's being done. But most importantly,

they also feel that they are not in control. They actually delegate control at the time and it takes a lot of maturity to understand that if I need the results, first of all, I need to trust the other person, as you guys said.

Most importantly, I also need to be patient. Yeah. And wait. So there is this, like, one of the things I really don't like is when, you know, people get to you, like, on a daily basis. How are we doing? How does it look today? Will I have the result today?

Will I have it tomorrow? It's the most exhausting thing because even if, you know, it's just another meeting that consumes like 30 minutes, it actually puts you in this mindset of, oh, I have to demonstrate something. I have to, instead of just focusing,

you know what, right now I'm in the zone, in deep focus mode. i just need that i don't think totally any distraction yeah yeah so yeah this is like it's also this loss of control that creates this impatience yeah i i think that's so big and and i haven't talked to like met a lot of founders over the last couple years talking to him i think one of the things here too is like how can you find a way to like as a founder to think about that because most of them are locked in like i'm going to work 80 hours a week and i'm going to be doing something for this company or 60 or whatever the number is and to realize that the best thing this week for your company might not be 80 hours like it might be in that like or at least

80 hours on what you want. You might need to be doing like things you don't enjoy as much like it's you know talking to or doing sales

or something if you're a technical guy. You know like there's probably always work to do but like you want to spend 80 hours on the technical problem

and that might not be the space for it. It depends on the skill set of the co-founders to a big extent. Like there's a funny story like

there's a lot of technical people who want to join us who basically want to start a startup because they want to focus more into technical problems.

And all of these folks I'm sure if you ask them they will tell you that oh fuck I built a startup and the only thing I don't do is technical

problems. Yeah yeah, totally. That's awesome. I remember calling the CEO of Clerc, he's a very tech-savvy person, like, we can talk about technical problems for hours. It was always his complaint,

like, I started a company to focus on technical issues, the only thing... I manage people, I talk in podcasts, I have to sell, I have to do conferences, I have to do business. focus on technical issues. The only thing. I manage people. I talk in podcasts. I have to sell. I have to do conferences. I have to do business. I set out to solve a technical problem

and accidentally became a CEO. Yeah. So it's super funny. All right, Socrates. Well, we're over time and Brooks isn't here, so we can, you know, that's okay. But just one more question for you because we're at the buzzer here.

I'd just love for you to give a piece of advice to someone who's in an early stage company, whether in an engineering role or a technical role. You know, they're trying to understand how to have intuition. They're trying to understand how to make the right decisions. There's a lot of ambiguity. What would you say to that person? You've been there and sort of seen that through successfully multiple times. What's the top piece of advice you would give to someone in that role? The best advice is that if you demonstrate the necessary amount of attention and you actually care for what you're doing good, and you're a craftsman, as we said before, you are maximizing,

basically you're betting on yourself, especially at the very early stage, and you're a craftsman, as we said before, you are maximizing, basically you're betting on yourself, especially in the very early stage, and you're maximizing the chances of the venture being successful. At an early stage, you have to balance between being a very good IC that is doing the work of enabling the rest of the team, like you're not actually building the actual software necessarily, but you're building the necessary framework for the rest of the team. Like you're not actually building the actual software necessarily, but you're building the necessary framework for the rest of the team to work with while trying to assemble the right team for you

with all the characteristics and the intuition we said before. These are the two key roles if you're building a team and if you're one of the co-founders or the founding members, if I may. And that's pretty much it. Like if you feel that you're basically betting on yourself,

I think you're going to do a good job eventually. I think it's as simple as that. And again, startups are not easy, especially on their stage. But I don't think there's any other stage in a company that can give you the same level of creativity and the same level of freedom. Yeah, I agree. Well, Socrates, it's been a while, but it was even better the second time around. So thanks for coming back after three and a half years. So many good lessons. Congrats on the

success and best of luck with Nuvo on the new venture. Thank you, guys. Thanks a lot. Thanks for having me. And hopefully I will see you again, not in three years, but... Yeah, shortly. In three years. All right. Thanks, Dr. G. The Data Stack Show is brought to you by Rudderstack, the warehouse-native customer data platform. Rudderstack is purpose-built to help data teams turn customer data into competitive advantage.

Learn more at rudderdersack.com