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

John Wessel  00:03

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

Eric Dodds  00:13

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 Vedas, 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, and it’s 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.

Sokratis Vidros  00:59

Hi guys, glad to be back. Time flies. We just, we thought it was like two years ago, but like when we I know, oh, we’re dead. All

Eric Dodds  01:10

right. Well, give us the story. So give us your quick background and we’ll dig deeper when we dive into the full recording. But what were you doing three and a half years ago and what are you doing today? So

Sokratis Vidros  01:19

At the time, I was the founding engineer and clerk. 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 Notification space called novel. And I guess he actually caught me at the exact same state. So it’s just going

Eric Dodds  01:42

to be a repeat of the previous show.

Sokratis Vidros  01:45

I mean, Clark did great, so I consider this to be a great for instance, yeah,

John Wessel  01:52

Well, yeah, we’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 kind of the 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 the topic that you’re interested in digging in on? I think

Sokratis Vidros  02:17

The other interesting topic is basically to talk about the need for engineers to wear multiple hats on a daily basis, meaning sometimes they have to be the product, sometimes they have to be the tester. Sometimes they have to be both, especially daily 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 years. Yes, three and a half years, exactly in startup time. This is a low time. Yeah,

Eric Dodds  02:52

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 what it looks like. 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.

Sokratis Vidros  03:32

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 the 1012 beginning of 2013 It was the era of GitHub, Spotify, soap, if I HubSpot. It’s a pretty wild time shift, exactly like this kind of tool, like the second generation of online SaaS, or 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 that. That time it was the rails, the Ruby Rails. Oh

Eric Dodds  04:18

yeah, it’s a great point. It’s like so many Ruby apps. And then my sense is that, like they all face a lot of pain at scale when they actually became successful, yes,

Sokratis Vidros  04:26

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, a little bit 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 the clerk. The Head Start of the clerk was supposed to be. Totally easier, because I work with the two co-founders from the states that were brilliant people, but it was a dev tool space that significantly had harder. It’s way more exciting when it comes to tech, but in order to build a business, a sustainable business in the dev tool space, it’s 10 times harder than the Vertica session, 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 gonna do this again. Yeah,

Eric Dodds  05:31

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, and 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.

Sokratis Vidros  05:56

Yes, yes, it was actually pretty good. And it was, you know, at the time we were 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. Yeah, we’re just doing our jobs, and it happened, and in order to get to the same point as a clerk and now in a novel with way more experience, yeah, because, again, it’s a dev tool, it’s significantly harder. Yeah, so the, I mean, one thing that’s certain is that I really enjoy this path to the first million. It’s, as I call it, like creating value from zero. It’s the most exciting part of any startup.

Eric Dodds  06:52

Well, what I’d love to do is we, you know, on the show, we’ve talked for years now, and I say that you know because you know that better than anyone being one of the very early guests about how the date 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’s so many lessons there I think that we can take away. And so I’d love to just dig into, you know, a lot of the things you’ve learned building a software and to talk a ton about software, because I think there’s 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. So, I mean, I

John Wessel  07:55

think a lot of, I think of a lot of our listeners, like, if you’re a developer, data, you know, engineer, anybody in the startup space, like, okay, like, I’m, you know, I’m in this job, and I’m, like, I’m looking for the next things. Like, how do I find a place where, like, it’s, you know, good, a good environment, but like, the startup is going to be successful, because obviously the failure rate is really high, yeah, and you work really hard, you don’t get paid as much as you could at, you know, a larger company. So like, finding something that’s going to be successful is a big deal. So there’s no formula for this, so we’ll start there, but I just 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?

Sokratis Vidros  08:36

Yeah, we’re getting there. We’re getting there. Hopefully. The truth is that there is no formula. And as you said, like 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 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. Uh, immediately 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 10 hours a day in very early stages. Maybe more than that, yeah, we have to get along. Most important we have to in very early stage is very important to say one thing, understand 10 and bring back to it, back 20 to the product. Communication can be co actually, so automation around communication is the most important thing, without processes, without ruling, without like you don’t need all that stuff in the beginning. You just need to be able to work with people that basically get you. How do you get them?

Eric Dodds  09:51

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. You. At a certain level. You know, can you break down that framework and maybe give an example that, like,

John Wessel  10:04

extra, what? What’s the right word? Extractability. Extrapolation. Extra, yeah, extrapolation. There

Sokratis Vidros  10:10

we go. I mean, at first, let’s actually, I’m gonna tell you exactly what happened in the clergy. And I think this is the kind of framework you’re looking for, 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 founder developers. The first thing you need is 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. 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. The first takes like they’re looking for intuition. And this is very important, because the moment you have, let’s say more than four or five people, these people create a gravity around them, and then they can attract similarly minded people. Yeah. And this is gonna magically free a lot of your time so that you can actually go back to building and creating products, because we are still busy with communication, people, management, the process is the bureaucracy. In these early stages of 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 detection, actually having the product. This is a very 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 the 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 back end, things are way more especially also in the data space, things are way more well defined. So you’re using a framework, a Rails for old school folks like me, or next, next, next js or remix for the back end. 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 pro of the project, especially in the front end, where people can go wild. We still have a digital route architecture that just works. And it’s very important to sit with the 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,

John Wessel  13:05

yeah, 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 gonna like very good at solutioning, but sometimes, paired with that, personality is, I’m gonna solve this problem differently every time, because it’s fun. Yes, versus like, I’m going to be more 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.

Sokratis Vidros  13:40

Correct. And it’s not just fun. It’s because engineers get bored very easily. And it’s like a game. Like, if you solve one problem, one way, you conquered that solution, yeah. And then you’re not satisfied. You want another solution, yeah. And again, I can, I mean, I always make it a la deck. My sister is an architect, and I always like it. I really like the 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 100 houses, and every time they want to build them differently, they use different techniques, like they do use different types of cement, type of wood. People just say, you know, but this works. They just build it. Take the money, move the next one, right? Engineers kind of 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,

Eric Dodds  14:30

yeah, yeah, but

John Wessel  14:33

It’s so funny too, but 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, like, the company, yes. So there’s that. And then, like, 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, like, I need you to, like, move towards stability and reuse things and not reinvent the wheel. Like, there’s a lot of tension right, pulling in that I think I’m not. Yeah,

Sokratis Vidros  15:00

yes. That’s why it takes a very special type of character, not the technical skill set. It’s more of a soft skill space. It’s the kind of engineers that want to always touch base with reality. So 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 gonna have to face it very soon, and then the product will be crappy. It will be sloppy. And right now, especially around the web, the expectations of the community have been very high, high. Like, like, the amount of Polish we get on recent software is just insane. Yeah, gray forms with great buttons are not cool anymore. Like, yeah,

John Wessel  16:00

yeah. John, 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, you know, how do you apply some of those principles, some 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 work 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. Like, 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 like, present optimizations, you know, like, Okay, sure. So then we’d have those people, and you’d hire them, and then they would, and this was like, 1010, 12 years ago, they would immediately 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 move it. 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 required 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 think it’s a very hard problem to solve. I think the encouraging thing to me is seeing the technological process of over the last 10 years, where the guy that would tend toward like, I’m gonna 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 a more of an analyst type persona. And then, you know, some of the ETL tools, some of the other tooling, all is getting more accessible toward more of an analyst persona. So I think that’s positive, but I still think it’s a struggle, even for people that are like, 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. Anyways, yeah.

Sokratis Vidros  18:55

Socrates, anything to add there actually reminds me of a very fun story when we started working at some point. We started dealing with a lot of candidate and job data, so the numbers started becoming very high, and we assembled the 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, we’re 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 GitHub, and we can know exactly, we can basically run the same experiment again with the 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 engineering pattern like I don’t think any developer nowadays knows how to work without GitHub. Sure, sure. Yeah. What peaked at the time? It was a Jupiter Notebook. It 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 in early stage startups, they just delegate all the data functions to AI. And AI right now is a commodity. It’s an expensive commodity. That’s an API call away. So I see, yeah,

Eric Dodds  20:36

That’s what I see.

Sokratis Vidros  20:42

So yeah, 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, yeah, 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.

Eric Dodds  21:22

Can you give an example of that? Like, how glad you brought this up? Yeah, yeah. Can I actually want an example of that from you Socrates and then, and then John as well. But like, what’s an example of that? Like, what opinion are you looking for in a data tool?

Sokratis Vidros  21:35

I have a recent example. I was using a tool recently called hex tech. It’s basically

Eric Dodds  21:40

Darry McArdle, the CEO, has been on the show a bunch of times. Yeah, totally. Great company.

Sokratis Vidros  21:44

So yeah, 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, yeah, 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 the Google Analytics, and you have Google Tag Manager and all this kind of stuff that required a lot of time to put it together. So what I liked in the hex deck was the fact that the software was delightful to use. Yeah, 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 write the not the Jupiter recipes. It’s very similar to that. They don’t call them Jupiter. I don’t remember what they call them. That’s a very similar concept, so that we can easily publish the dashboard to the company and say, Guys, these are the stats of the company. This is the dashboard. This is the graph 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 talk, because the conversations like the early stage startups, you startups, you usually need these North Stars in the graphic format so that they have seen them. And they actually, yeah, get hyped. They get pumped by

Eric Dodds  23:11

that. Let me push back on that a little bit like 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

Sokratis Vidros  23:29

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

Eric Dodds  23:41

It guides you down the right path, like it has an opinion of the path you should take. Yeah, exactly. Otherwise,

Sokratis Vidros  23:48

You know, I can pick 10 engineers in the room and tell them that we have 10 sources of data. What do we do with them? How do we query them as well? Yeah, okay, got it. Got it. Yeah, I will come up with 10 solutions.

Eric Dodds  24:00

No, exactly. Yeah, that’s fascinating, actually. Yeah,

John Wessel  24:03

it’s, it’s not what you would think of at first. And because of what I think of, there’s two kinds of categories, in my opinion, of opinionated software. One is, like, me domain specific, like, I’m gonna run an HVAC company, and it’s, like, very opinionated and like, what to do. The other is, like, what I’m thinking of, like, in this case, is like, technical guard rails, of like, here’s like, all of the things and the right, like, stack, all the things pulled together. Whereas if you throw an engineer on that, like, I’m gonna grab some like, D three.js and I’m gonna use, like, Plotly here. I’m gonna use, like, a notebook here, like, you just end up with like, yeah, totally,

Eric Dodds  24:36

yeah, totally, no, that’s great. We need to let Barry know about the show, yeah, and ask him for some preferred js, yeah,

John Wessel  24:44

but yeah. But I think I mean in

Sokratis Vidros  24:47

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, goes a little bit into the buy versus build discussion. Linear is another great example, sure. Like me, okay, apart from linear, linear is extremely polished as a product, but if you think about it, entering a 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. It’s they sell the opinion of all the pipelines look like,

Eric Dodds  25:43

yeah, yeah. I love it on, on the other

Sokratis Vidros  25:47

hand, Trello or Asana, or people try to care, or the worst, on Monday, which is like, Monday, literally, yeah, Monday. Like, these tools will kind of 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. It’s just something that works. I don’t have to think about it. I buy it, I use it, and I’m happy, right?

Eric Dodds  26:14

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 is 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. Okay, 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. 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 you 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 like, doing that multiple times in a row. So I want to know, you 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,

Sokratis Vidros  28:22

John, you want to go first, or should I?

John Wessel  28:27

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, um, find a way. You just can’t always do it. Find a way to work with the person prior to just like, get a really good sense, for example, yeah? So if you’re like, you’re, 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? So basically poaching, Intro coaching, yeah? Or just like, hey, I want to work on this project for you, with you. 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 him on a temporary project, get to know him from some other like, angle linear

Eric Dodds  29:18

does maybe a better job than any other company I’ve seen around this. I just know this because someone who I used to work with very closely here at RudderStack now is on the product team of 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 Okay, oh, there you go. Yeah, you know, yeah, Socrates, so

Sokratis Vidros  29:45

I, my, I have to, like, let’s say two secrets. This one is very relevant to social engineering. The other one is not. I’m gonna start with the easy one. So in general, yeah, linear does this. And. Like the strategy, but in general, I prefer the opposite direction. What do I mean by that? Like, 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. Yeah, they’re under stress. I

John Wessel  30:15

agree, yeah, oh yeah,

Eric Dodds  30:18

because it’s not replicating the actual it’s not similar, replicating the actual environment, for sure,

Sokratis Vidros  30:24

exactly. You gotta never code with these very strict timelines, and you gotta never code with a gun over your head so your boss

Eric Dodds  30:30

isn’t looking over your shirt because you’re trying to solve a problem. I hope not right,

Sokratis Vidros  30:35

exactly, exactly. And also, it’s a profession of it like it’s craftsmanship to Yeah, I go to a painter and tell him, get the next masterpiece in the next three minutes, 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. It lasts one hour. And when we join the interview, I always tell the interview, there’s one thing I want us to get out of this. I want both sides to understand if it will be nice for us to work together. And I also want you. I also want me and the interviewer to learn at least one thing you think 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 code 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 how 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, analyze them, and as I do that, I also check technical questions. For example, let’s say that last week we’re designing or building to analyze search functionality. I’m like, Okay, let’s imagine that we have this website and one with the search functionality. What’s the first thing that comes to mind, we start with open-ended questions, and then I’m like, okay, based on the answer, I would like, okay, how would you do that? What’s a technical challenge, but the database? What is the database going to look like? And usually, in an hour, we talk about one or two features, but it’s enough like it’s enough to see if the CO 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 when I use it, I usually sail a lot, and I like everything that has to do with CNN sailing, especially 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 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 intensively, you know, 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 cannot be a windy day as well. So you have to find the sea, the sun and they win at the same time. And usually, if you do something that’s not the right move, one of the elements will basically

Eric Dodds  33:07

telling you that very clearly, yes,

Sokratis Vidros  33:11

and at the time you get stressed, and if you haven’t rehearsed this beforehand, right, you’re not gonna make the right collective action. You don’t make the situation worse, right? 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 that code. Because if we spend the right amount of time on paper without I mean, that doesn’t mean we’re gonna spend six hours designing then things in code will flow. It’s gonna be much simpler. It’s gonna be way easier for you to think about things. And this applies both in the interview process, but most importantly, when we work. So I try to find people that can have this 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, yeah,

Eric Dodds  34:03

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, you know, doing the hard thinking work, you know, or at least on, you know, 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. And, I mean, I know, you know, in your experience of 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, yeah, 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.

Sokratis Vidros  35:19

This is extremely hard, especially in early stage companies. As you said, like this phrase of it just x, like, what it needs one hour. It’s two hours. Just do it. Yeah, it’s a dangerous path. And the truth is that the best secret is just to ignore it. Yeah, 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 feed nice, because usually the person saying this is your manager, usually you’re being pulled into 20 different directions, but usually 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’re you have to give something back. So you have to demonstrate progress in early stage companies. There’s two things you need to do. You need to do this process for sure and you but you need to time box 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 is no right or wrong, because you have built pretty much nothing yet. So if you build anything, if you could do it good, it’s probably going to be okay, like, it will resonate with somebody, how it’s there, yeah, and then you do this again and again, like, one of the most challenging parts of this, like, 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 early stage companies, trying to find the optimal solution and do user testing and get aggregate data. For an early stage company, we have zero data, and we have 10 customers. Like, there is no statistical gravity to what we’re trying to do. Like, it’s just 12 people using the software just to build anything and make sure you build it well. It’s as simple as that at the end of the day, but it’s very hard, like when you are in this thinking process, it’s very hard to get out of it and think that, okay, let’s just build it. Let us build this. Yeah, yep. I love

John Wessel  37:36

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 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 that give and take on that. I agree,

Eric Dodds  38:25

yeah, I think the other, I think the other thing that comes to mind for me is that it’s easy to think about management or like business stakeholders. You know, we often cast them in this light of like 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. Like, 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 an 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 anybody else. I

John Wessel  39:21

I think the unfortunate part here is that most people’s experience is that, as a leader, it 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 multiple experiences. That’s a great point, yeah, they don’t actually know 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. That’s a possibility. Or it could be that they just have this locked into this mentality where they’ve never given them a great Yeah,

Sokratis Vidros  39:55

yep. There’s also another, another side of this. So I. 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. Yeah, at this point, if basically, you give them what they need, that has 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 fun, I have no control. I don’t know if there’s progress. I’m so incapacitated. I think this is another, it’s another drive that makes, yeah, 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, 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, as you guys said. But most importantly, I also need to be patient, yeah, and wait, yeah. 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 is it looking today? Do I have, will I have this all today? We’ll have it tomorrow. Like it’s the most exhausting thing. Because right even if you know just another meeting that consumes like, in 30 minutes, it actually puts you in this mindset of, oh, I have to demonstrate something I have today, instead of just focusing, you know, but right now, in the zone, in deep focus mode, right? I just need that. I don’t think there is any distraction, yeah. So, yeah, this is, like, it’s also this loss of control that creates this impatience. Yeah,

John Wessel  41:54

I think that’s so big. And I have to, 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 technical, yeah, you know, like, 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, yeah, the space for

Sokratis Vidros  42:41

it depends on the skill set of the co-founders to have a big stand. 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, right? Because they want to focus more on 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 don’t do exactly,

John Wessel  43:05

yeah, totally, yeah, that’s all I

Sokratis Vidros  43:07

remember. Like calling the CEO or clerk is a very tech savvy person, like we can talk about technical problems for hours. It was always his complaint, like I started the company to focus directly on this user. The only thing is, I manage people, I talk in podcasts. I have to sell. I have,

Eric Dodds  43:28

I set out to solve a technical problem, and accidentally became a CEO,

Sokratis Vidros  43:33

yeah, yeah. So it’s super like, yeah.

Eric Dodds  43:39

All right, Socrates, well, we’re, 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, because we’re at the buzzer here, I 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? Like, what are the top pieces of advice you would give to someone in that role? The

Sokratis Vidros  44:14

The best advice is that if you demonstrate the necessary amount of attention and you actually care for what you are doing, it’s good. And you’re a cast man, as we said before, you are maximizing, basically, you are betting on yourself, especially at the very early stage. And you are maximizing the 10s of the venture being successful at an early stage. You have to balance between being a very good I see 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 to work with while trying to assemble the right team for you with all the characteristics and the division we said before, these are the two key roles, if you’re building a team and if you’re on the co founders. All 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 gonna do a good job eventually. I think it’s as simple as that. And again, startups are not easy, especially in the early stages. But I don’t think there’s any other stage in the company that can give you the same level of creativity and the same level of freedom?

Eric Dodds  45:23

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

Sokratis Vidros  45:39

you guys. Thanks a lot. Thanks for having me, and hopefully I will see you again, not in three years, but yeah, not three years next time. 

Eric Dodds  45:44

All right, thanks. 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 rudderstack.com you.