Subscribe
Share
Share
Embed
Honest conversations with the engineering leaders, CTOs, founders, and engineers building real software with real teams. No fluff, no hype — just the messy, human side of getting great products out the door.
Zhenya Rozinskiy - Mirigos (00:07)
Ben, thank you so much for joining. Thank you for being on this episode of our podcast, Build the Humans. We're talking about different things related to technology, but not technology itself. It takes a lot of effort to build a product, be it a SaaS product or an app, doesn't matter what it is, there are teams, there are processes, there are teams within engineering, there are teams between different groups, sales, marketing, business.
and we'll have to work together. So this talks about the human side of building things more than anything else. My background, I run technology teams for about 30 years. Now I'm running a service company called Mirigas. Our tagline is we've solved what's broken in outsourcing. And the idea being we help teams really build top quality engineering.
from resources in Latin America and Europe by not stepping on the underwater rocks and all the known problems that typical outsourcing companies do. So that's us. Please tell us about yourself.
Ben Stiefel (01:09)
Sure. So I'm Ben Stiefel. I'm a senior engineering director here at Sidecar. I've been here for about a year and a half now. Before that, I was director of engineering at another VC-backed startup called Measurable, which was in the ESG space. And I've been managing teams or teams of teams for about 10 years now and been in the software world for 25 years this October.
So a lot of varied different experience almost entirely on the web. But yeah, I've always had a passion for building things that help people get stuff done more quickly. I had my first email account in, I want to say 1992 as a freshman in high school. And
Even though I didn't focus on technology in school, I actually studied anthropology. I fell back into programming and fell into professional coding when I moved back home after college. Literally met a guy at a car wash and he talked to me for a while. I told him I taught myself programming and he said, that's cool. Do you want a job? And I thought I might be on candid camera, but he was serious and he, he,
interviewed me. He told me to take home the Sam's Teach Yourself ASP in 21 days and told me I had one week and I brought it back and that was it. I started programming, yeah, like I said, October of 2000. So, been here ever since.
Zhenya Rozinskiy - Mirigos (02:43)
Well, if
we really wanted to age ourselves, then we should talk about time spent on IRC.
Ben Stiefel (02:48)
I hope we don't have to do that today.
Zhenya Rozinskiy - Mirigos (02:49)
Well, yeah,
probably people don't even know what it is. One question that I, you you mentioned you are now building, you know, managing other managers, right? It's teams of teams. And we've seen a transition over the years and sort of doing this full circle. used to be large teams, then we've broken them into different pods or scrum teams, whatever you want to call them.
then those teams went into complete silence. This team does this, this team does that, and they never meet. And now there is more talk, in some cases, let's bring it together, right? Teams are good, pods are good, but it's not a silo. We're still building the same unified product and there should be a lot of communication. Talk a little bit about it. Like, what's your experience?
Ben Stiefel (03:33)
Yeah, that's a great point. So at my last place, we were definitely in those pretty siloed pods. We had microservices. We even started to go towards micro front ends by the time I left. So there were a lot of silos, and there was the trade-off of you might have duplication, but you can go faster on your own. Here at Sidecar, we're still on a monolith.
We have one front end, one back end. Everything kind of touches each other. So we are struggling a bit, you know, with how many, like, how do you break down silos when one team has cross-functional requirements? And how do you challenge that? And I think the, how do you break through rather that challenge? And I think that the, the best way is literally just talking.
and having communication. So getting people, whether formally or informally together, which is harder when you have remote devs that may be quieter, more introverted and on another time zone. But reducing those barriers, Slack hangouts are a really good way to get people together. You can be off camera and still comfortable. It's just one-on-one.
We have a weekly engineering, what we call an engineering demo, half an hour every Friday. It's kind of morphing a little bit into a little bit of a scrum of scrums, like a standup that all of the engineering team can come to and say, hey, what am I working on? And how does that affect others? And then people can have, give feedback. It can be technical or just architectural or just talking out ideas as well.
Zhenya Rozinskiy - Mirigos (05:10)
You mentioned on cultural differences and I'll get to that a little bit later because that's something that very close to my heart because that's something that I'm working on and I live day in day out. managing teams of teams, you've seen teams scale, you've seen them go from small to large, large to even larger, and each one comes with different challenges.
What would you say important to do early on or what you wish you've done earlier that would help at a later stage? And again, I want to position it, we're five people, we're all sitting in the same room, assuming we're in the same room, or we're not in the same room, but we're on Zoom or Slack all day. We don't need to document anything. We don't need to worry about processes because we all know what we're doing. And it's true.
Ben Stiefel (05:48)
Mm-hmm.
Zhenya Rozinskiy - Mirigos (06:00)
And then five goes to 10, 10 goes to 20, 20 goes to 100. And now the person 99 has no idea the name of the person number two, right? Much less what they're working on. And so the same process don't work. You're trying to reestablish them, but sometimes it's too late.
Ben Stiefel (06:17)
That's a great question. scaling is, yeah, scaling effectively is incredibly difficult. every person you add is going to change your team's culture a little bit, change the way that things work. Hopefully you hire people in your process, you're checking for that and you're making sure that this person would be a cultural add to the company.
not just to the engineering team, but to everybody in a whole and filtering for people that want to be part of a team. And I always try to cheerlead on engineering that we are part of the company. It's not us versus them. So that's one part is breaking that down and saying, it's not a fight the way that it used to be.
so far apart that you complain about accounting or you complain about sales, promising things that you couldn't deliver. But within engineering, it's definitely important to make sure that, again, people have time to get together. And you're probably going to want to not shy away from reteaming somewhat regularly, even if the pods are settled and so forth. And you have to be aware of, you you're going to
you're gonna go back to storming and norming from the team formation. But you're gonna get a stronger team because you're gonna have that better mix of ideas. like, I did this over here, what about that? And then that will adapt the new team. People will learn new and better ways of doing things.
When building new teams though, like you said, if you're scaling up from 10 to 20 to 60 and so forth, one thing I learned, the worst I can do is to staff an entire new team just in new hires. A team that has no context, that they may all be amazing engineers and have an amazing manager, but they don't know anything about how things work here now.
That can be incredibly disruptive at best, and it can be a complete failure at worst. And where people just look at you and go, why would you do that? Like this team is doing nothing, they're struggling, they're actively slowing other people down. So when I'm scaling teams, I always think about how can I, kind of like sourdough bread. You take a little bit and you let that ferment with the new flour.
Zhenya Rozinskiy - Mirigos (08:40)
Mm-hmm. Mm-hmm.
Ben Stiefel (08:45)
and then you build a better life that way.
Zhenya Rozinskiy - Mirigos (08:48)
I think it's a very good analogy and I find that that works the best as well. We have clients that come in. So we have very wide range of clients from it's a startup. I need to hire the first person and then build a team around them to we're a fully functioning company and we need to hire a few people to augment the existing team to.
we're launching something new and we need to build a brand new team, right? So anything in between. conversation constantly for us comes in location and are they collocated or not? And when I say collocated, it's not the same office, but it's the same similar time zone. And we cover two regions. We work Latin America and Europe. We don't touch anything else. And so one of the most
Common questions again, what's better? What do you recommend? Do you recommend this hiring in Europe or do you recommend this hiring in Latin America? And I always say, tell me what you want to hire for and then I'll give you a different answer of what you're set up. And for example, if you've got an existing team and you're trying to add, and you have a 10 people team and you're trying to add two people to it, you probably want to stick to closer time zone. If you're building a brand new self-sufficient team, then it doesn't matter or matters a lot less.
Ben Stiefel (09:49)
Yeah.
Zhenya Rozinskiy - Mirigos (10:00)
And then you may want to consider Europe because of a different approach, different engineering approach. But there's no right or wrong answer. But I do want to come back to talking about culture and being able to bring it all together. How distributed are you? Do you have, is everybody in same location, different locations? How do you do this work?
Ben Stiefel (10:19)
Yeah, right now we have the bulk of our team, I would say is in San Francisco. We do have engineering managers. have two engineering managers that are remote. One is in Idaho. One is in Tennessee. And we have six contractors that are in Latin America. So the furthest forward is about four hours ahead. But for the most part, people
work and operate on West Coast time in the product design and engineering circles. And then outside of that, we have three hubs of the company overall, or four really. have Seattle, San Francisco, New York, and then a couple of our executive team are in Houston still, though that may change. But yeah, we're pretty much on US time zones.
and then plus one for Argentina, Brazil. So, but they, again, like I said, they tend to at least be available more West Coast times. So it helps with...
Zhenya Rozinskiy - Mirigos (11:15)
Yeah, that's what we find.
Interestingly, people are concerned, again, in our business, people are concerned about time zones and they'll say, well, we don't want to hire in Europe because it's a 10 hours or nine hours, depending on what in Europe you're, nine or 10 hours time difference. What they don't realize, and this is going to culture exactly where I sort of want to take this conversation, people in Europe work much later than they do in US.
Ben Stiefel (11:36)
Yeah.
Zhenya Rozinskiy - Mirigos (11:38)
and somebody says, well, you know, we're willing to hire in Europe, but want to make sure they're up online at least until, you know, 11, 12 a.m. our time. like, no, they'll be up way past that. That's not the issue. It's just you're not going to get them at eight o'clock their time, 8 a.m. their time. It's just don't count on it. But, you know, 9, 10 p.m. local time, sure, they'll go.
Ben Stiefel (11:48)
Yeah.
You
Zhenya Rozinskiy - Mirigos (12:05)
and that's not a problem whatsoever.
Ben Stiefel (12:06)
Yeah, one of the best QA engineers I ever worked with was in Kenya. he's like, yeah, it's four in the morning, so what? ⁓
Zhenya Rozinskiy - Mirigos (12:12)
Yeah.
Exactly.
Kids are finally asleep. I can do some work. Sometimes I find myself doing the same thing. So let's talk a bit about bringing culture together. you interestingly you mentioned we have people here, here, here, and then you said, and contractors in Latin America. What do you do or do you do to make sure that they're part of your team? Because that's something big on our part. We don't
Ben Stiefel (12:19)
Yeah.
Zhenya Rozinskiy - Mirigos (12:38)
think of people we place are contractors. Legally they are, obviously, right? They're not contractors. But we don't think of them as contractors. And we encourage hiring managers not to think of as contractors. We think of them as the same core team member just happens to be in a different location. So what do you guys do to bring it together to gel the team, both culturally and in every way?
Ben Stiefel (12:42)
Yeah.
Yeah, I mean, to bring them together, literally we bring them together three times a year. So we have two engineering off sites a year, as well as an entire company off site. So everyone is invited to those, including the people who are in Argentina and Brazil and Mexico. So they come there physically together for part of the year, at least three weeks. But then the rest of the time,
Yeah, we have, you know, we have on screen time throughout the week. So each team has their standups and they get to talk and, and so forth. And as well, we're, we're trying to have more time for less technically focused, I guess, or less ceremonial stuff as well. So we have, the good news, happy hour.
which is usually at about 11 o'clock on a Friday morning for us. So mid afternoon for some people. And, you know, people can come and just talk without all the pressure of like, I need to get work done part of that. Additionally, you know, our people team is really good at calling out work anniversaries and birthdays and making sure that each person gets the same treatment. So.
Yeah, treating them equally I would say because well, frankly most of them have been here longer than I have so they're even more of a part of the company than I am That's that's You know, I think the most important part is to not act like they need to be siloed or separated just because They're not in our HR is system, you know as full-time employees
Zhenya Rozinskiy - Mirigos (14:33)
Of course. Yeah.
I remember.
Ben Stiefel (14:36)
If we could give them
more stock options and so forth to drive the point home that they are actually invested in the success of the company, that would be a really good way as well. That's a good. Yeah.
Zhenya Rozinskiy - Mirigos (14:47)
Interestingly, a lot of our clients do. They give
them stock options, right? Even though they're not employees, but they give them stock options or stock, different ones do different things, but they do. Yeah, I remember this is right before I ran. This is sort of what prompted me to build this company. was VP of engineering at a Fortune 500 large company and they brought me in. They had this different outsourcing shops in various locations.
Ben Stiefel (14:55)
Yeah.
Zhenya Rozinskiy - Mirigos (15:14)
The majority of the team was local in LA, so was in Los Angeles, but they had outside. And it wasn't working. And they were like, well, it doesn't work, you gotta fix this. And I what have you done? Well, we changed this company, we changed this company, it still doesn't work. well, have you thought about it? Maybe it's not the company that's the problem, maybe it's something else that's the problem. So I went in and I rebuilt it completely from scratch where we build our own teams, back then it was in Ukraine. And...
long story short, about a year, even probably less than nine months into it, we had, so we were running pods, right, different scrum teams, but there were managers of managers, right? So one, there was a manager who had multiple scrum teams, which makes sense. And historically, you always had managers in the US and they manage teams, both in the US and remotely. And the first time,
Ben Stiefel (16:02)
Mm-hmm.
Zhenya Rozinskiy - Mirigos (16:04)
I had a manager that was, and we had some managers that were remote and they only manage remote teams. Fine. And for the first time, I took a remote manager, somebody who was remote, and I said, well, you're going to manage some remote teams, you're going to manage some US teams.
Ben Stiefel (16:16)
And how did that work?
Zhenya Rozinskiy - Mirigos (16:17)
It worked out great. The reactions, initial reactions were like, you're breaking the covenant. It can't be done. I'm like, why? Why can't you have somebody who is elsewhere managing somebody who's in US? It's not upside you, from up down. It's just, there are two locations. Can somebody in New York manage LA? Can somebody from LA manage New York? Why can somebody from Ukraine manage LA?
Ben Stiefel (16:35)
May.
Zhenya Rozinskiy - Mirigos (16:43)
And so he was a great guy and it worked out really well. But I remember changing the mindset of, or having to change the mindset and going through the process just because they're remote, that doesn't mean they're different. That means it doesn't mean they're worse. Doesn't mean they're any less valuable. They just happen to be somewhere else. And this is back way before COVID, right? So everybody is co-located. Everybody's in office and nobody's remote or virtually nobody's remote.
Ben Stiefel (17:01)
Mm-hmm. Yeah.
Zhenya Rozinskiy - Mirigos (17:11)
So that was very interesting.
Ben Stiefel (17:12)
Yeah, I'd imagine outside of engineering, there would be a lot of pushback because they think maybe this person wouldn't be the best for the business or all these other things. But inside of engineering teams, think that would be far less friction.
Zhenya Rozinskiy - Mirigos (17:30)
The funniest thing was that it was both outside of engineering and within engineering, the friction was the same. But the funniest thing that I had to work on this was like today, it's hard to comprehend. When you're talking to them, turn on your camera. And people are like, camera? I don't look good on camera. I don't have my makeup on. Like, who cares? Who cares? Turn on the camera.
Ben Stiefel (17:35)
mistake.
Yeah.
Yeah.
Zhenya Rozinskiy - Mirigos (17:52)
And today where we all live on camera, I don't do any calls for that. I I'll do phone call, obviously, when I need to. But if I'm talking to somebody and sitting on the computer, turn on the camera, let's see each other, even though we're in different countries. But that's sort of the next best thing is to be next to each other. But back then, was just, I remember convincing people, turn on your camera.
Ben Stiefel (18:14)
Yeah. A lot of, yeah, a lot of people, mostly engineers that I know are, they have very specific feelings about that. Some think, yeah, I should just have my camera all the time. I don't care. Like whatever. Others are thinking, I don't want my camera. It's just, it's a source of stress for some, for some reason. And it's, I guess maybe,
personal invasion. They don't want people seeing their house. It's different person to person. So yeah, I always think if it's your team, if it's your group and you need to connect, try to have your camera on. If it's a big group and there's 30 people in a team-wide, in an engineering-wide meeting or so, it's awesome. No one's looking directly at your little box.
Zhenya Rozinskiy - Mirigos (18:43)
I'm sure.
Absolutely. Yeah, I was on a call this morning.
I was on a call this morning, right? wasn't the client, it was just one of those things. There's 30, 40 people on the call. I didn't have my camera. I mean, I turned on my camera to say hello, and then I turned it off because I'm listening and I'm doing other stuff. So, but that's different. No, I'm talking about when you're actually talking to someone. Cool.
Ben Stiefel (19:12)
Mm-hmm.
Yeah.
Yes, yeah,
if you're talking to people, they're listening to you. It's much easier to read people, which is again, that's why I try to encourage people to at least get on a call, get on a Slack hangout. So you can at least hear the voice and the intonation because text is a very flat medium. And when you're writing something quickly, a lot of people won't get the intonation that you're trying to put into your writing unless you're
Zhenya Rozinskiy - Mirigos (19:23)
Yeah.
Mm-hmm.
Ben Stiefel (19:46)
amazing writer, and most people are not. So give him a call.
Zhenya Rozinskiy - Mirigos (19:49)
Oh, people
misread messages, text messages or short messages a lot because they assume something that's not there. It's not even misinterpretation. It's like, well, he said yes and didn't say anything else. That means he's pissed. No, it just means he's on his phone, just hit yes. That's it. It just does not mean anything else. Don't try to read it. It just doesn't mean anything.
Ben Stiefel (19:59)
Right, right.
Yeah. Right.
Yeah.
That's one of the interesting things I think about our entire productivity growth and focus of especially the Europe and the Americas is people feel this need to be responsive and to move things forward 24 hours a day at the cost of deliberating and making a, know, taking the time to
Zhenya Rozinskiy - Mirigos (20:32)
⁓ huh.
Ben Stiefel (20:39)
Yeah, bring context, explain your thoughts, and actually connect with someone.
Zhenya Rozinskiy - Mirigos (20:44)
That's very true.
All right. Something completely changing the topic or changing the conversation. What do you think the big or biggest myth about what it takes to build a great engineering teams or biggest things that you wish founders and tech, not tech, non-tech leaders knew, especially in startups, right? When they're building teams or growing teams.
Ben Stiefel (21:08)
The biggest myth is probably that people are plug and play, that you can just replace someone with another person. I would say the biggest misconception that I've seen is people not understanding, whether you call it the iron triangle or the, you you can have quality speed and low cost pick two and people think
that they can find a hack around that, especially when they haven't been through a tech, not been at a technology company for very long, that they think, you know, I can go fast. What, you know, I, had people, I've had people ask me things like, why, why would it take two days to put a button on a screen? You honestly expect me to believe that. And the real answer is you, get two days if you're lucky.
that, you know, there's, it's not just writing the code and putting it on the screen. You know, you'll get a really terrible user experience and then no one will want to buy your product if that's all you're doing, if you're just throwing stuff in. And it takes a lot of time, research and effort to do, to know why that button needs to be there. What should happen when you click the button in every potential case.
you know, think about security and make sure that someone's not filling out a form and trying to break your website when they click that button and so on and so forth. So there's a lot more that goes into it than I think people realize to make good software. You can make bad software really quickly and no one will buy it and your company won't be very long lived. But yeah, and that's, guess the other thing.
A lot of people don't, a lot of people I think believe that a technical person should also know everything about building a product. And that's, that's a very rare skill and you can build it, but I don't think a lot of software engineers get enough exposure to product design and management that they, that they have those muscles.
So expecting to be able to go to an engineer and say, go make me this screen. And then actually getting what you want instead of going to a team that has a product manager and engineering manager and designer and a team of engineers to build it saying, this is what I want. What's actually going to happen then is you're going to have a conversation. They're going to say, is this really what you want? What? And then you'll hopefully get to the best outcome, best design.
and best product that you can that you think, I just want to go and put in my information and be done. And they think, well, what makes the best interface for that? What about putting it on mobile? What about all these other things? So I think a lot of people think you can just brainstorm to an engineer and then they will kick out an amazing piece of software for you. But there's a lot more that goes on underneath that.
Zhenya Rozinskiy - Mirigos (24:00)
Absolutely. And you mentioned a few things, brings back memories of my engineering days. I remember we had a very complex product. The company was at that time 40, over 40 years old. So you can imagine how that product evolved and grew. And there were components that nobody knew existed much less how they work. And a newly hired manager decided
Ben Stiefel (24:20)
Yeah.
Zhenya Rozinskiy - Mirigos (24:24)
to put a newly hired junior engineer to change how one of the functions, one of the things worked.
a very well-meaning but also new executive was very happy to hear that I'll only take a couple of
Ben Stiefel (24:41)
Hahaha
Zhenya Rozinskiy - Mirigos (24:42)
Yeah, that did not go well.
Ben Stiefel (24:44)
Three months later.
Zhenya Rozinskiy - Mirigos (24:46)
you
Ben Stiefel (24:46)
Yeah, I've been there.
Zhenya Rozinskiy - Mirigos (24:47)
Actually,
yeah.
So, all right, one, guess I'll give you one more thought provoking.
Ben Stiefel (24:50)
Wow.
Zhenya Rozinskiy - Mirigos (24:55)
We're seeing a lot of changes that are happening.
things are moving much faster than they did 25 years ago. We have very different approaches in how things do. Somebody asked me this, it actually came up the other day, I was going through some of the old interviews that I did, and this question came 10 years ago. So somebody asked me 10 years ago, it just popped up on my screen a couple of days ago. And somebody asked me, we were talking about the cost of fixing bugs and why QA sort of didn't die but really changed.
compared to what it was 25 years ago. Then I said, well, 25 years ago, we burned our product on a CD. And I actually did it on a flat piece before that. And a cost of fixing a bug was literally yanking that CD from every customer and sending them a new CD or later DVD. This is before DVDs. So today, the cost of fixing a bug is when you log into a production system and change a file.
So it's a little different doesn't mean you don't care about quality, but it just the cost is much lower So with so many changes and again the most important speed of changes How do you think engineering teams will look how the junior organizations will look say in five years?
Ben Stiefel (26:08)
Wow. I am historically loathe to predict that much just because, yeah, looking at where things went every five years I've been. I would say engineering teams in five years will probably have at least one to two agents that work with the whole team.
That's one thing I think right now people are trying out AI and they have their, you know, it's code complete plus plus or, or super auto complete is what a lot of people say. But I think there will, you know, that will be commoditized after a certain point, the way that everything else is. And I think there will be a lot more automated tools to help people to get,
from A to B, whether that's zero to one of like, have an idea and a green field and I can do anything and I want to launch it, or it's I have a 10 year old application and I need to find all of the places where, you know, I need to change X to Y. And we'll have a lot more automation of that. You know, we've already got command shift F, I can find everything, but.
it'll be more contextual, know, find everything that hits this service with these different kinds of inputs, something along those lines. And then I think the teams themselves will need to talk even more. They'll spend a lot more time discussing the best solution and then handing that off to those agents possibly. And hopefully to junior engineers that they can bring up.
which is one thing I think a lot of people aren't considering right now. At least where we are right now, these tools are, they will make a senior engineer incrementally or significantly faster, but they will take a junior or mid-level engineer who's relying on these and it will explode your development cycle because they will...
try something out, not knowing how to correct it. And that will increase your loop of getting stuff out. So I think we'll get to a point where teams can take an idea and deliver a larger idea rather than incrementally building on smaller ideas, if that makes sense.
Zhenya Rozinskiy - Mirigos (28:13)
Yep, absolutely.
It absolutely does. I think a lot about what's going to happen and how it's going to change. Actually one of the big questions I keep asking different people, nobody has an answer. don't have an answer, nobody has an answer. AI agents or AI today is doing so much work that junior engineers used to do that a lot of people are not hiring them. But what's the next step?
Ben Stiefel (28:48)
Right. What's the
Zhenya Rozinskiy - Mirigos (28:49)
What are you gonna
do? How are you gonna grow your next senior engineer if you're not hiring a junior engineer? So I don't know. I think a lot of this will be figured out over the next few years.
Ben Stiefel (28:59)
Yeah. And anecdotally, I don't know what you've seen. There's been a significant shift over the last 10 years. You still have a lot of people who are going through computer science or computer engineering degrees, but you have had many, many people coming out of boot camps and other programs where, you know, they've done maybe six weeks of training and then they need two to three years of
of being a junior engineer to get leveled up and leveled up and leveled up versus someone who's had three to four years of college experience who will need a year or two as a junior engineer, but they can become a more senior engineer, a software engineer more quickly, but they'll still need just as many years of product experience and building in the real world rather than building projects.
Zhenya Rozinskiy - Mirigos (29:27)
Yeah.
Ben Stiefel (29:54)
So I think it's important for people to remember that no matter where somebody comes from, you still have to teach them a lot of something, whether that's computer fundamentals or product experience or whatever else, teamwork.
Zhenya Rozinskiy - Mirigos (30:07)
I
used to work for a company that was about 400 or 500 people company and we did a lot of college training straight out of college people and some were really smart, really good, but a common problem or the common objective that we had and it took
Ben Stiefel (30:17)
Mm-hmm.
Zhenya Rozinskiy - Mirigos (30:29)
I don't know, up to six months was to explain to this kid, forget everything you learned in school. Right? I mean, it's great that you have programming knowledge. It's great that you know how to use this language. That's awesome. Now forget how it's done. No, we don't work in a group of four where we have a deliverable at the of the week, you know, together. It just doesn't work that way. And so that was very difficult. And I do see a lot of those bootcamps and I've been seeing them for about 20 years.
And some people coming out of those are as good, if not better, than those that come out with college degrees because they don't rely on somebody spoon feeding them. They know they've got six or 12 weeks to go figure it out.
Ben Stiefel (31:10)
Right. That was what my first boss told me when he met me at the car wash. He said, I'm not looking for computer scientists who will spend 24 hours a day for five days to figure something out. Because it was a consulting company, so we bill by the hour. So he said, you have to get it done right, and you have to get it done on budget. So if you gain a reputation for constantly spending too many hours doing something, no one's going to hire you.
Zhenya Rozinskiy - Mirigos (31:26)
Hmm?
Ben Stiefel (31:37)
and you could build the greatest thing, but no one's gonna pay you for it. So that was the philosophy that he instilled in me very early on, was get it done right, get it done on time, and you'll be successful.
Zhenya Rozinskiy - Mirigos (31:52)
100%. Absolutely. Thank you so much. Thanks for joining us. This was a great conversation. Thank you.
Ben Stiefel (31:55)
Yeah.
Yeah, my pleasure.