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:06)
Thank you so much for joining this edition of Build by Humans. It's a podcast that we started doing about six months ago where we talk about what it takes to build products from the human side of things. There are so many podcasts, so much information out there talking about technology, but we all know it takes people, it takes communication, it takes a lot more than just writing code to build a product, put it out there and make sure people enjoy it.
What we cover here is we talk a lot about communications, we talk a lot about how to make those different cultures work together, how to make people gel, even though this day and age, everybody is remote and everybody lives in a different part of the world. That's it today. We have our guest who's gonna introduce himself shortly and we'll talk about all the same topics.
Michel Baldin (00:54)
Hello?
Zhenya Rozinskiy - Mirigos (00:54)
It's all yours.
Michel Baldin (00:55)
Okay, well, my name is Michel Baldin. As we're talking a little bit earlier, French name born in southern Brazil, Italian descent with a French name living in the United States. It really doesn't get more confusing than that.
Zhenya Rozinskiy - Mirigos (01:11)
Talk about confusing and mixed.
Michel Baldin (01:13)
Yeah,
but ⁓ also, luckily, we live in a time where your name really doesn't define your gender anymore. Yeah, but yeah, grew up in southern Brazil. Actually, a very rural part of southern Brazil, which back then I never thought one day I would be talking about software development. Yeah, went to school in southern Brazil. Very agricultural.
Zhenya Rozinskiy - Mirigos (01:22)
Right, right, right.
Michel Baldin (01:37)
area. So I went to school for animal science out of all the things that could take me to software development. And then what really got me closer to software development was graduate school. I came to the United States many years ago for graduate school and then a lot of work with data, a little bit of mathematical modeling, which then led me to my first job out of
Zhenya Rozinskiy - Mirigos (01:41)
Wow.
Michel Baldin (02:02)
graduate school with a large corporate and I was a little bit of a product specialist with them working with a software development team which then allowed me to work with software developers. Some of them were domestic developers and others were overseas. And then in late 2018 I decided to quit my job with
corporate company and join a startup without checking what it would entail. But yeah, seven years now with a small size software development company here in California. So that's how we ran into each other. And that's how we're here today.
Zhenya Rozinskiy - Mirigos (02:46)
Yeah. So you actually have an interesting perspective, right? You come from Brazil, Latin America. We talk a lot about, so my company Mirigos, we focus on helping companies hire software developers. And we mostly do, so we focus on two regions. Latin America, we're probably about 75, 80 % of everybody we hire come from that region. When I say Latin America, I mean literally from, you know,
Mexico down south all the way to Argentina, Brazil, Chile. And we also do Europe, right? Eastern Europe, Europe, geography these days is very mixed. So I sort of try not to define the region by one word, but from that part of the world. And a lot of it is about culture. And a lot of it is about making sure the teams work. In fact, today I'm...
preparing, I'm going to be doing presentation at a conference and I'm talking about how remote development and how things changed. And so I came up with this thought and we just realized, originally outsourcing was sold to us as a cost saving. And everybody came in and said, we can outsource at that time was mostly Southeast Asia or Asia, cross Asia, and it's going to be cheap. And then it became not so cheap if you consider everything together.
And then it was twisted. Well, now you come there for talent, right? So you go there for amazing talent that you can hire here locally in the United States. And then that also sort of didn't work out. And so now other things are evolving. Before I get into too far in what I'm thinking, I want to ask you, in your opinion, what makes a team remote teamwork? And I know you work with outsourcing, like classical outsourcing model.
Michel Baldin (04:33)
Mm-hmm.
Zhenya Rozinskiy - Mirigos (04:33)
and
I know you work with other models, what do you think is the difference? What do you think makes one better than the other? And I don't even know which one is better in your case, but what makes them different?
Michel Baldin (04:41)
you
Yeah, for sure. So one point that I should have noted is, so my current role today is VP of products. like you mentioned, in addition to in-house engineers and in-house developers, we outsource with a team from South America, Uruguay in this case. And with that team, we have about
35 members, anything from UX, UI to Android, iOS, back-end, full stack. So that's my current exposure, that model, what you defined as a classical outsourcing model. And currently for us, it goes beyond extending our capability. It's almost a dedicated development team.
Now, prior to this experience with the corporate job, I was working with both teams, outsourcing teams in Southeast Asia and some employees that were software developers, but were hired in Eastern Europe to be part of the development team. So they came in almost like a... ⁓
peer of mine, we're both working for the same company and at the same time, we had the outsourced team. And the difference there was that most of the developers were in different time zones or different areas. So to your point, which one is better or worse? I would say both have pros and cons just like almost anything in life. Starting with...
what I'm exposed to the most currently, which is the classical outsourcing model. It comes with a lot of convenience. And some of those would be, we can expand and fluctuate or expand and contract the team as we need. So the hiring firing process is a lot easier because we mostly say our budget now only allows for 30 instead of 35 developers.
It also gives the outsourcing partner or the software partner a little bit of flexibility to structure their team the way they see fitment and alignment. On the pros, on the cons side or some of the challenges is at times it can be a very unleveled
playing field because the incentives are different. If you're paying people to accomplish story points and there is no distinguishment between building story or new features or fixing bugs, now you're paying someone who may not have the same, they don't have the same stake, right? So you're basically hourly paying someone to do a job ⁓ versus when on the other model now, the pros and cons, if you,
onboard someone and they are your peer and they're part of your development team and they have a stake or they have some ownership on the success of the product. That means if we have features that don't work or bugs that we need to now go back and address, then depending on how their placement in the team is structured, they may have a different incentive to be perhaps a little more
careful when building things. But then the cons obviously is now you onboarded someone, right? So it becomes a little more rigid. I would say the structure is a little more rigid there. And to onboard 30, 40 people and then expand contract, it just becomes a little more tricky. So hopefully that gives us, yeah.
Zhenya Rozinskiy - Mirigos (07:56)
Absolutely.
So interesting, you're
touching on a very heart of the problem, right? That I would say exists in outsourcing. I've done outsourcing for years as a client, not as a, I've never had an outsourcing company, but I was a client of outsourcing companies for many, many years. And it always didn't feel right. It didn't bore. I'll say it didn't bore, but it's not that, I mean, that's the end result, but it didn't feel right. And it didn't feel right exactly for the reason you just described, right? These people.
They're not boring. It's not their product. They work, it's like a contract, right? You're building a house. You put your heart into it, right? You wanna make sure that every nail is the right, the paint is right, everything. And then you hire a painter. They come in and they're like, okay, here's the wall, I'm just gonna go paint it. And it doesn't mean they're gonna do a good job. They will do a good job, but at the end of the day, to them, it's the wall number.
2027 this year, right? They don't know. And I think that's the big issue with classical outsourcing. So the whole idea of what we do, and again, not to get too deep into this, is where we combine, we bring together the best of both worlds, right? You can still hire very quickly, let go very quickly, you can still do all of this.
but these people are dedicated, they're your people, they really work for you. They work for us on paper, right? We do all the compliance, we do payroll, know, legal, we do everything to make sure it's done right. But when they wake up in the morning and if somebody asks them, who do you work for? They'll say they work for you. They don't say they work for us because that's, and they also know we don't move them project to project. That's not a key thing. We never move people project to project, which means they know that at the end of the day, they have to please you, not me.
So that's sort of the whole deal. But yeah, I I hear you. Outsourcing is great. I love our idea of outsourcing. When you have a defined project that has clear start and end, right? I need to build something and it's a one-off. And you can go and get an expert, like a true expert in doing this and they'll do a great job.
Michel Baldin (10:13)
Yeah, no, that's for sure. to add to some of the challenges. So I've been with the startup and not, perhaps not a startup anymore at this point, but with the same development team for a little over seven years now. And we've had a few lead developers who packed their stuff and left. And not to say that that wouldn't happen with
someone who is hired by your company or by our company because that also happened. had, right, so I would say another challenge with when you purely outsource is perhaps you have a little bit less touch on how someone is feeling about their job, how they, because in addition to good compensation, people also want to make sure they're feeling a value then they are part of something bigger.
Zhenya Rozinskiy - Mirigos (11:04)
Yeah.
Michel Baldin (11:05)
So we oftentimes try, even through the outsourcing model, we try to make sure that people on the other side are always taken care of, that they're feeling valued. We, back to your point of feeling like they are part of something bigger and having ownership, that's our primary goal. So instead of just pushing tickets in Jira or stories,
Zhenya Rozinskiy - Mirigos (11:23)
Bye. Good.
Michel Baldin (11:27)
We always try, myself as I was a former product manager here and then now VP of products. We try to have everybody internally and in the extended team understand what the mission is, understand what the vision is. Because hopefully that gives someone the feeling that they are part of this bigger thing. It's not someone checking stories and you know, every sprint.
Zhenya Rozinskiy - Mirigos (11:49)
Right.
Michel Baldin (11:53)
count how many points they accomplished. So we try to go there. We try to make sure that even though it's a traditional outsourcing model, we try to make sure that people feel like they have an ownership in the outcome of the company as, or the products and the company. We're obviously a for-profit company. So if we don't succeed, if the products don't succeed, then our contractors...
Zhenya Rozinskiy - Mirigos (12:13)
Of course.
Michel Baldin (12:17)
by extension are not succeeding as well.
Zhenya Rozinskiy - Mirigos (12:20)
Right. Interesting thing that I want to touch on and very specific to your role used to be a product manager, now VP of product. that's your thing. If you think of a typical software company where software is an internal product, I don't mean like it's an internal product, a relationship between a product manager
And an engineering lead, an engineering team is almost like a client and a service provider, right? The product manager is a client, right? They come in and say, hey, I'm going to buy this product from you, right? This is what I need you to do. And the engineering team says, yes, we're going to deliver this, hopefully. But it's a lot more than that. It's a partnership. I've been in that relationships many times, running engineering teams, right, for nearly 30 years.
And it's a true partnership, right? A product manager comes in and says, I need to do X, and Z. And you, as an engineering leader, go.
And that too, no, can't do this. But you don't want to say no. So you get into this negotiation mode, right? Hey, what if we do this? Now, because I was an inside person, meaning I work for a company, I know what's out there, right? I know what's available. I have the continuity of this product development. How do you manage that with outside engineering teams? They don't have that, right? Or they may not have.
Michel Baldin (13:40)
Yeah, now relevant to our discussion today, add on top of that language differences, cultural differences, time zone differences, style differences. Yeah, so I should do a lot of our day-to-day management of roadmaps, a little bit less of the...
Zhenya Rozinskiy - Mirigos (13:47)
Right.
Michel Baldin (13:58)
you know, started pushing and some of the more product manager related tasks. However, I do believe it all starts with the bigger picture. If you purely go up to someone, a developer, a lead engineer, or anybody really, and purely ask them for something without giving context, it's always going to be more challenging because that person...
will immediately become defensive and say, this is not going, like you said, not going to work or it doesn't fit with the current model. However, when, and this is what I've experienced with my progression as a product manager now, working with several product managers. If you always present the end goal and more importantly, start with the why. From a product standpoint,
This product needs to achieve something. So here is why we're pushing this feature or this change. But remember, the product is part of something bigger. It's part, in our case, and I forgot to mention that at the beginning, we're building ERP, an ERP platform. So our products are, by themselves, they have to succeed, but the ERP as a whole has to succeed. So there is product mission, platform mission, and then on top of that company mission,
Zhenya Rozinskiy - Mirigos (15:10)
company.
Michel Baldin (15:10)
So from a standpoint of I'm purely pushing this feature or request, it may not make sense if I just said that, but when I start with this fits within the product mission, which then fits within the platform mission, which then here's why the company is going that direction. And you give the other side an opportunity to be part of that construction. It's not prescribing. Early on, I was very prescriptive. I would come with a story defined as like, here, do this.
If you come with the angle of here's an idea and I need you to work with me for us to find the best path so that we can succeed towards again product strategy, company strategy. So that's my approach nowadays.
Zhenya Rozinskiy - Mirigos (15:52)
And that's perfect, right? That's exactly
sort of what I would expect and what I had and that's great. How do you make it work in outsourcing world and in a culturally different world?
Michel Baldin (16:03)
Right. Yeah. So again, having worked with developers from different parts of the world, you start to understand and being from South America myself, you start to understand a little bit of styles. You have those teams that always push back and they never find an excuse for anything, right? They've been raised under that culture, know, no excuses, pushback, very...
dry, then you've got the other teams are just, they're very yes, know, they're they're, they're story points that that's all they care, right? They measure success that way. And then you have perhaps, cultures that are a little more shy, more reserved, and they really appreciate the personal side of things where you truly need
to empower them and encourage them. I need you to ask questions. I need you to ask clarifying questions because not every story is going to be written perfectly. And if you just take things at face value and run with those, and then I'm only going to catch that at the very end when we're doing UAT, now we wasted maybe two weeks of resources because you assumed something. So we always, we fight against assumptions. So we try to...
encourage asking clarifying questions. If a product manager is pushing something and we have a leading developer or an Android developer with the outsourcing team in charge of taking that work requirement and go with it, if they're not 100 % aligned, they need to ask those clarifying questions. And that culture needs to be fostered and encouraged every day. Nowadays with
Zhenya Rozinskiy - Mirigos (17:39)
I'm Ryan, of course.
Michel Baldin (17:42)
instant messaging platforms and all kinds of platforms to collaborate. There is no reason really to not take the time to ask clarifying questions because in the long run that's so much cheaper. If a developer and a product manager spend five minutes, 10 minutes on a huddle to discuss something but that then just went.
versus developer takes the task, goes with it, and then at the very end when our team is doing UAT, turns out the feature was built incorrectly or it doesn't meet the acceptance criteria. Now from a company resource standpoint, we spend so much more because now we'll have to rework all of that all over again.
Zhenya Rozinskiy - Mirigos (18:03)
Mm-hmm.
That's right.
And I think you're touching, and this is where culture difference and culture building comes in. Latin America doesn't have that. South America doesn't have that. But some other regions do where asking a question is considered. Like, you know, people look at it, hey, if you ask questions, that means you don't understand it. That means you're stupid and they don't ask questions. And I've seen that many, many, many times over and over again where like, well, why didn't you ask?
Michel Baldin (18:39)
Yeah.
huh.
Zhenya Rozinskiy - Mirigos (18:48)
Why did you assume this and why didn't you ask? And then you understand over time, it's their culture prohibits asking or taking one step further. Sometimes, and I, you know, when I was running teams and now, you know, I run the company, all my employees know just because I said something doesn't mean it's right. It just means that's my opinion. And everybody's not only allowed, but encouraged and expected to argue with me and say, no, it's not going to work that
Michel Baldin (18:54)
Yeah.
Zhenya Rozinskiy - Mirigos (19:15)
And that same thing was when I was hired to, know, in engineering, know, CTO, VP of engineering, whatever it was, but in some cultures, yeah, good luck disagreeing with your boss and telling him he's wrong.
Michel Baldin (19:24)
you
Exactly. it takes, it's a continuous effort. It's not one of those things that you have one workshop and now everybody is a critical thinker. We try to foster that. So it starts with the product managers and the higher up, the higher up you go, everybody needs to be open-minded and say, if we're going to encourage
pushback and people asking clarifying questions and possibly presenting their opinions, then that needs to be well received as well. Right. So we we we try to to cultivate that environment of everybody's free and encouraged to speak openly about their perceptions as long as it's done professionally. And in obviously we struggle with, you know,
English is the common denominator. There is no other way around. So, and then you've got the stakeholders, the end users, and you've got an engineer here who has no idea what the, there's no domain knowledge, for example, right? We work, our ERP is primarily for farms in agriculture. So we have someone who went to school for computer science or some type of engineering degree, never stepped foot on a farm, right? So the distance,
Zhenya Rozinskiy - Mirigos (20:31)
Mm-hmm.
I've never seen one, probably.
Michel Baldin (20:41)
Exactly, exactly. The distance
between those two worlds is really large, which means how is this engineer now expected to ask clarifying questions? Or how is this product manager expected to ask clarifying questions about this stack that we use? So we try to bridge those gaps as much as we can, and that's why product managers, project managers play a really important role in
Zhenya Rozinskiy - Mirigos (20:56)
Mm-hmm.
Michel Baldin (21:06)
bridging that gap, not only from encouraging people to speak up and talk, but also translating a lot of translations because communications is more than volume. When it comes to communications, quality matters more than volume. And to have a team that respects the other team and communicates clearly, it really takes effort from everybody.
Zhenya Rozinskiy - Mirigos (21:15)
yeah.
Well, thank you so much. I really enjoyed it. I appreciate your time. And it looks like we are very much aligned in our view of how things work or should work. And it's a challenge. It's interesting.
Michel Baldin (21:40)
Yeah, well, thanks for having me. Hopefully, I was able to provide my two cents on how to work with people who are not in front of you every day. One thing that maybe I could share that I think has worked really well for us as a take home message is for anybody outsourcing or with remote employees, I think there is a sole value in in-person.
interactions. hold a once a year event where everybody comes together. There is not a lot of business that gets done, but there's a lot of personal relationships that get developed. So when you join a Zoom call or you are messaging someone, things are a lot easier when you know people at a personal level. So I think that has worked well for us.
Zhenya Rozinskiy - Mirigos (22:24)
Absolutely.
Definitely. Thank you so much. Thank you.
Michel Baldin (22:30)
Hey, thanks for having me.