Logo

Software Developers Journey Podcast

#263 Phil Alves maker of product-developer teams

Resources

Highlights

[00:01 - 07:11] Discovering the Coding World

Phil Alves discovered coding at the age of 12 and it quickly became a passion for him. This self-taught experience taught him the importance of perseverance and curiosity, which were instrumental to his professional growth. This is an important lesson for junior developers as well, suggesting that self-learning can be a critical skill in the tech industry.

[07:12 - 12:30] Entrepreneurial Journey and Transition

Phil ventured into entrepreneurship and founded DevSquad, a company focused on building high-performing development teams. He also spoke about his transition from deep coding to taking on managerial tasks. He emphasized that embracing change and continuous learning were key to successful transitions. Junior developers should remember that their career path may not always be a linear one, and that adapting to changes is a crucial part of growth.

[12:31 - 23:05] Building a Strong Company Culture

Building a company came with its own challenges. One of the key aspects Phil highlighted was the importance of building a strong company culture. This includes setting clear expectations, maintaining open communication, and promoting a balance between productivity and preventing burnout. He strongly suggested that these values be incorporated into a team for achieving better results and a healthier work environment.

[23:06 - 30:02] The Role of Data in Team Performance

Phil introduced his other venture, DevStats, a product that provides real-time performance data for development teams. He emphasized the importance of data in enhancing team performance. He suggested that understanding data could provide valuable insights to improve efficiency, and also promote transparency in team management. This is a crucial learning point for junior developers who aspire to lead teams in the future.

[30:03 - 41:59] Importance of Product Mindset

One of the most insightful points in the interview was Phil's emphasis on the product mindset in developers. By asking candidates about their favorite products and how they would change them, he evaluates their holistic understanding of product development. This showcases the necessity for developers, not just to focus on their coding tasks, but also to understand the broader impact of their work.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Phil Alves 0:00
You want to make sure that you know, the technology and that you understand the framework. If there is things that you you have to learn the framework, we're going to teach to pair programming we're going to teach to, to code review. And then there's our part of that, like, they get like a body. When they get on board, they're going to get a mentor that's going to follow them for like the next four weeks. Teach them how we do stuff, how we do code review how we think about approaching the tasks, how we break down tasks, how we write tests for TDD in their mind.

Phil Alves 0:29
But the biggest thing that we are doing is around mindset is around helping them understand how we think and then pairing the product mindset.

Tim Bourguignon 0:38
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host team building. On this episode I receive a feel of this feels mission is to help underdog SAS founders to compete against big tech by giving them the tools their businesses need to thrive. Here's the CEO and principal principal consultant there dev squad, and he is the founder of DEV stats. He's also a fellow podcaster he hosts the SAS origin stories podcast, which sounds like music to my ears, because we love origin stories here. So, Phil, welcome veteran.

Phil Alves 1:21
Oh, thanks for having me.

Tim Bourguignon 1:23
Oh, it's my pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join the spine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So feels as you know, the show exists to help listeners understand what your story looked like and imagined how to shape their own future. So as is usual on the show, let's go back to your beginnings. Where would you place the start of your journey?

Phil Alves 2:14
The year was 2005.

Tim Bourguignon 2:19
Fantastic story.

Phil Alves 2:20
So I start by wanting to learn how to build websites. And back in the day, I used to use Dreamweaver, and flash. And so I was building stuff on flash. And we were not actually coding yet. On flash, I learned about action script, which was a programming language back in the day for flash. And that's when I started to learn a little bit about conditionings. And if and else and stuff. And then from there, I started learning PHP. So I bought a book. And I started teaching myself php. And PHP is still the language that I code to this day. I never change it from there. So yeah, that's kind of like how it started. I'm self taught. And I just taught myself how to code through books. And through websites, it wasn't as great as today today, we have videos and so much content. I remember like buying a book, bringing the book calm, trying to write the code, and it wouldn't work. Because the version of the PHP of whatever was different and whatever it is, isn't the book.

Phil Alves 3:32
Like what's going on? So it's it's a lot easier to learn to code nowadays, then it was 2005. But that's when I start.

Tim Bourguignon 3:40
It doesn't need it doesn't need, what did you try to do? What was the, the what you were searching for through these medium of first flash and ActionScript and then and then PHP, which which reach.

Phil Alves 3:53
So first, I was just doing very basic websites for local business. And back in the day, it was a thing where people, they would open a site and they would want something spinning and some music and whatever. And so

Phil Alves 4:11
sites are so horrible. So that's where I started, but

Phil Alves 4:19
I went to PHP because some people came to me and they want to be like, a little bit more of a smarter application and like actually have a database and save data and manage their business. And instead of moving from like a spreadsheet to to actual software, and I didn't know what to do but I remember the person come and they're like, hey could with this to me and I gave them a price CDs and then I was like okay, how do I build dynamic websites?

Phil Alves 4:52
With the loop bookstore, bought a book and then it went from there. So that's how I started.

Tim Bourguignon 4:58
That is awesome. I I don't want to date you, but don't seem too old. How old? were you when you started? building websites for businesses? This sounds like your business.

Phil Alves 5:09
Yeah. 1617 Ouch.

Tim Bourguignon 5:14
You always have this, this this intrapreneurial vibe of creating business and really, really making an exchange like this with people.

Phil Alves 5:23
Yes, yes. My dad was an entrepreneur. And I learned from him so. So I only had one job in my whole life. So when I moved to United States, and I didn't speak English, well enough to be business yet, I still, I still knew how to code. So I ended up finding myself a job as a developer and I had that job for a few years. But that was the only actual job that I ever had. All the time in Brazil, I was running my own business. And then after that job, I start dev squad. So I only had one job ever. And I love my job. I love my boss. When people complain about their jobs, I'm like, I don't know, the one I had was great.

Tim Bourguignon 6:06
I love it. The possibility to say the one that had. Now you have to choose to live up to that and never ever take a job to be able to say the one ad. That's cool. So you said you said you came from Brazil? So how long did you say did you stay in Brazil? And when When did you move and why? Maybe? Yeah, so

Phil Alves 6:31
I stay in Brazil until I was 22. That I start, I kept developing products. And I was actually I stumbled upon a SaaS product by totally by accident. I didn't know what I was doing. But I was learning to code. And then I was posting in different websites, everything that I was learning, okay, this is how this work. This is how you, you can do whatever in the programming language. And I Oh, those will point back to my site. So I didn't know what I was doing. I was doing link building. And then someone hired me to build a software to pay commission, and manage the direct sales for their company. So I build this software. And I post on my blog, and I put, I put the title of the blog post direct sales or commission management software or something along those lines. And then that ranked first in Google for that keyword. And then oh, yeah, and then people started coming to me, and they and they want that product. And I was so clueless. So what I started doing it was for every single customer, I set up a new server with an instance of their softer and after did that to 10 customers, I realized I had created a nightmare because there was a bug that I had to fix templates, just

Phil Alves 7:52
a feature I have to put in the end of the press is not to say that version control was old, old file new drove to it with all the sophistication that was still able to grow that company to 10 employees

Phil Alves 8:15
and, and really get that the software going actually not hiring some actual professional developers, they came in to help me they taught me about subversion at the time was not even gate yet. So so they told me about Subversion and then they told me about SQL injection I honestly didn't know what that was it took them 30 minutes to hack my thing that I was thinking commission which

Phil Alves 8:41
I did understood what

Phil Alves 8:42
that was but so I ended up anyways end up selling that company and that was enough money for for me to not work for a couple years and for apply for a student visa because were to get a student visa to come to the US you have to prove that you have enough money to pay for school and our work for a couple years. And so that's what I did. So I use this the money from that company to move here then I went to school here and then life kept going from there

Tim Bourguignon 9:11
what did you choose to choose for school? What do you do here

Phil Alves 9:19
so so first I had the bad idea of going to computer science and then there was too much math and too much low level stuff so then I changed to information system which was my thing you know, it's still cold with there's a lot of more businesses stuff and you don't do very complex shit.

Phil Alves 9:36
So that was my kind of like my area where I feel like I could be at 20 of like, learning to build products deeper and stuff. So I ended up doing information system. That's what I study.

Tim Bourguignon 9:51
Okay, so yeah, what were the the puzzling or missing the putting the puzzle pieces together is more the complexity than Then the inherent complexity of really building the software. Yeah, finding the right places and like pieces. And

Phil Alves 10:08
we don't care how the computer work, or what is a memory allocation, just wants to connect the

Tim Bourguignon 10:14
dots and do the product.

Phil Alves 10:19
Who cares how this things work?

Tim Bourguignon 10:26
Back in my days, I'm basing myself now coding in C on firmware. And we're discussing the meaning of one bit. I can tell you it's not my very first

Phil Alves 10:45
couple of C classes, and then they start talking about pointers in memory this and I was like, oh, man, PHP is so much easier

Tim Bourguignon 10:56
in some of the ways that it's different. Yes. So are you graduated with the with a degree in Information Systems? And then took this one job, I assume? Or? Yeah, I took the job

Phil Alves 11:09
when I was still going to college. Oh, okay. Yeah. So, still going to college. I mean, I already I already got here knowing how to code. So I went and I got a job and working on a Magento website, I hate the framework with all my heart. But anyways.

Phil Alves 11:29
It's building zand. And it was horrible. But anyway, so that's the

Phil Alves 11:33
that's the job I got. And I worked there for a couple couple years and ended up playing that hiring developers and that like leading those developers to the growth of the store, but actually never graduated, my I was doing my business on the side, I ended up getting married along the lines, which means I got a green card, so I didn't need to go to school anymore. For the visa, I could just go if I really wanted to. But my my side businesses start to take off. And so because I started kind of like this quad on the side doing consulting with firms, and, and also bringing development teams, to those firms. And so I ended up like quitting school and quitting my job and going full time on the app squat.

Tim Bourguignon 12:19
Okay, how did did you start this? Was it at first you doing some consulting and at some point realizing, oh, I need somebody else, and hiring somebody and someone and being the two of you. And then three and four? Yes, yeah, I

Phil Alves 12:33
started, it was just me doing the work on the side, like, I'll get just some small projects here and there. And I'll basically I'll go to my work nine to five, and then I would work more in the evening and do stuff in weekends. And then I got bigger projects. And it was like, okay, I can hire someone to do the front end for me and other just the back end. And then, but I was just too like heavily involved in actually creating. And then as I kept going, I was like, Okay, now maybe I can hire this one person to this other part because it's a bigger project. And that's how we grew.

Tim Bourguignon 13:07
Did you always have this idea of growing into a big company and making air quotes, or growing into a really large company, not just not just for people with really, always it's, no, I'm having fun, I'm doing some fun projects, I need some help on the side, because I kind of do it all on my own. But the idea is more to have fun projects.

Phil Alves 13:26
So I didn't want to stay a freelancer, I wanted to be like a small, consulting firm, but I didn't plan to be this big. So my idea was, we can be very small, like just one perfect squad, I ended up moving more into the technical product manager role. And then I had like other developers, and then we'll be like this one team, they'll do for a while. And then like, if you made a video say that we are small, and we stay small, and delete the video, the internet, so and so like her as well, like just under 10. And then I thought we'd be like a 1012 people company forever. But I realized that the the structure of the squad that we built was was so powerful. And you could do so much about like building new products, we start calling ourselves, product developers instead of software developers, we start to understand the difference between building software and building product. And like the whole mentality of how we, we went about, we were talking before there's a star mindset, though we were able to build around the development team was super powerful. And I assure you that could be scale and it could provide that to other companies and we could teach other people to think how we fought. And that's when I went and I paid a bunch of money for the domain dev squad because they didn't start dev squad. It was a different name was supposed to be his mouth. You know, it was like SFC dive shop Salt Lake City dive shop because I just wanted to serve the local market. So we were pretty much Whenever the domain and then that's when, like the whole concept of like we're gonna scale many squads that specialize in building SAS products and understand product that has a product mindset above or above our else. And that's kind of like how it is that we started.

Tim Bourguignon 15:17
That is fascinating. I always love how things evolve organically and how your initial ideas sometimes come through and sometimes stay, and sometimes just get blown out by, by what happens. You made a distinction between product development and software development. Would you mind coming back to this and explaining what distinction you make in this regard?

Phil Alves 15:40
Yeah, I think that what you call yourself is gonna really influence you how you think about your day and how you act. Right? So when you're building the first version of a product, it's more important that you think about, can the user go from A to B? are we solving a real problem? How will the user see this this product? And think about that as like your main goal? When you think of yourself as a software engineer, you might think, Okay, can I how can I make this query the fastest as possible? How can I optimize this, like to a very, very level optimization, and I believe companies like huge like Google, they need a bunch of like crafty engineers, optimizing little things, because they're gonna make a bunch of money of those authorizations. Now, when you're a small company, you need people that can think big picture, and they can understand your user, they can have like a business mindset a little bit and understand like, Okay, this is what people are going to do. And this is how we get to profitability or like, let this is how we're going to retain people. So you think a little bit more big picture, even if you maybe are not very, very good. Like one super specific thing? Does that make sense?

Tim Bourguignon 16:51
It does, definitely, I was thinking, would you, I want to say Allow, but that's maybe not the right word. I like to use it anyway. But would you allow your product developers to use no code tools to solve the problem?

Phil Alves 17:03
Yeah, without a problem? Well, if there's the right solution to over someone, why not, you know, but with the stack that we work, which is, most people think is a variable or stack we work with Laravel is just give us so much like, we don't have to think so much. We're like thinking about the product, because all the architecture decisions, they were made by Taylor Otwell. This is how the jobs work. This is how we do validation. This is how we do testing. This is this is how we're going to send notifications. So are those decisions were made. And those are, like I would say heavily soft engineered decisions for us to understand the business and use the framework to understand the business. So I believe like a tool like Laravel is more powerful than no code, and already took everything out of the way for you to really just think about the business and then write business logics and write things that's going to really add value quickly to your product. Now, the all depends, there's no, like we were talking offline, there's not one single truth like this is like my workspace where building SAS products, that's gonna go from zero to 50 million, maybe they're not gonna be ridiculous, huge, but like measuring the b2b space. But like, where I play, this is just the best technology that we found. Because how the hard technology has already made, we are thinking about the business.

Tim Bourguignon 18:29
That very smart move, were you tempted by some customers to go with different technologies. So when coming in saying, hey, I really want you but you have to use Ruby and Rails, for instance.

Phil Alves 18:41
Yes, that happens all the time. And answer it is, look, Ruby on Rails is great. But you want to hire a team to understand a stack very well, in any I feel like any consulting firm or workers out is not going to do whatever you say they're going to be, he's going to specialize in one thing, and they're going to work on what what are their experts in and if we conclude that what we know in our experts in other best cannot solve your problem, then you go find someone that can write in the in their programming language, they can write in Ruby on Rails, or whatever it is that we're going to use. But yeah, we we really, we only stick with PHP and JavaScript. So we still also do things like no then react and view. But this is the only two things and if the clients they're not okay with that, then we cannot work with them.

Tim Bourguignon 19:32
Okay, I've I admire the mindsets. And I've seen this quite a few times. But when the rubber hits the road, when when you have to pay salaries at some point and somebody said, Hey, can you can do some Ruby? And that's where you start questioning? Am I following the values and then what I really think we should be doing or should I try doing something else and that's when it becomes hard. So I really, really liked that you're staying sticking to your guns and saying no, that's what we know. And here are the Yeah, the reasons why we think it's the right answer. And let's try to stick to that.

Phil Alves 20:04
And unfortunately, the reason why we stick to that now is because we learned that that doesn't work when we try to do that, you know, so like, we have done the mistake of like, big public company come to us, and they're like, We want you to write Java. Really, Java, Java. Like, sure, we're gonna write Java for you. And then like, after a few months, it's just not working well, in relationship is not great. So after like being burned a couple times and understanding you that that doesn't work. And also, now we can just trust that the right customer is going to come to the door. I feel like it's very hard in the early days, when you just have to pay the salaries. But when you build a brand and like, and you have constant leads coming in, it's a little bit easier to to be firm.

Tim Bourguignon 20:55
Did I understand that? Right? So you have squads that kind of stick together for a longer time period and get really to know each other gel, and really work well together? And try just to keep them as is, is that correct? Yes. That is awesome. How many people do you have on the squad? What What kind of skills? And in? Does this evolve from project to project? How do you keep it to keep it as a tight closed system when projects change below them?

Phil Alves 21:23
Yeah, so the squads have like four to eight people. And we're gonna have every squad is full stack developers. So we want to when you have a team, that's more the developers, they need to be able to navigate from the front to the back. And then we have a QA engineer, and a product product manager. So that's always the setup of every single squad, they might have less developers or more developers. Depending on the project, we are still making some technology choices on the front end, most of the time. So do we have to go with view? Do we have to go with React because you're gonna have an app you're going to do directive native to. And so we have two people that have like different skills, but also there's opportunity for people to learn. So we just had some people that they join a squad to write react, and I had wrote react before, but they were very good developers, and then they, they learned that they acknowledge, so like, when you go on Glassdoor. I love going into stores, looking at the reviews from the people that work for us, they there's many reviews that say that we have the perfect balance between staying off time with your team. So you learn but also moving people around, so they can have new challenge and learn from new people. And that's all we try to do. Because there's always going to be new clients coming in is going to be clients leaving, we keep the team together, we never move out once you try not to make breaking changes, while you're while we are moving pieces. And we are letting people work with other people. As we are moving those squatters around.

Tim Bourguignon 22:49
Now that's a very smart move. How do you handle the relation to the customers? I assume they don't drop a requirement document on your on your lap and saying oh, go do this. But are you the other extreme would be very tightly coupled agile process where you each rate with the customer every week, for instance? Where do you lay on that spectrum? How do you handle this

Phil Alves 23:15
so I like to say they're very flexible like to do we like to do 90 days plans losing OKRs so this is how we're going to track our successes are hoping to go every 90 days. We actually like to do the 90 days planning person to I'll ask clients to fly to Utah and I'll fly the developers to Utah to because I have all developers in Brazil and then we all meet we think about what we discuss in the seminar room about the next 90 days how are we going to do and then from there we do two weeks of spreads and we always doing a dual track agile. So we are doing the discovery sprint where we are like okay, figuring out what we're going to do next and and how we're going to do and you're designing stuff and we have the delivery sprint we're actually building stuff which makes me remember that I forgot there was one person in the squad two which is the product designer. So because it discovers sprint the product designing the product manager working very closely together designing doing user interviews and doing whatever we need to do to prepare that that work that's going to be down the backlog because what do we mean that three months planning we don't like go deep into everything we do usually. Now next later is there science, we talk about the ideas we whiteboard, but from there we have to let go deeper and plan in shape that work that has to be done.

Tim Bourguignon 24:32
Okay, so you do this this three month cycle, then you produce a first version of what was agreed with with the customer. And then they say hey, awesome, good enough or yeah, really cool. Now let's do another three months and course correct in this and this and that and do this on top? Is that how it works?

Phil Alves 24:51
Yes. So that's exactly how it works. On average people gonna stay with us 18 To 24 months. And there's gonna be people are gonna say three to six months. Only one on every trip we study for 18 to 24 months. And then we usually help them with the migration to like the we call the knowledge transfer. One of the biggest things that I like to say here, the onboarding experience has to be amazingly, the off boarding has to be memorable, because I want people to really remember us when they leave us like the easiest company to, to part ways with because unfortunately, in this space, about source development, there's a lot of shady and bad actors, people that hold code hostage, and there's all kinds of problems, especially when they work with people. They're not super technical. So we we try to, to be super transparent and to be very good in the off board.

Tim Bourguignon 25:45
Part of the process. So it has to be memorable in a good way. Yes. Because you remember the bad ones as well. Just dropped the software and

Phil Alves 25:59
I wouldn't name names but even worse, sorry. We Oh, you're cool. Go through the over again.

Tim Bourguignon 26:09
That's that's sometimes hard. So when I hear is that we're you're mostly doing greenfield projects or taking an idea and building up from scratch? Is that correct?

Phil Alves 26:23
Yeah. Or what do we do practices are not Greenfield, they come to us, because the technologies that we specialize for them, we work with some of the biggest companies in the world, which I can not say the name because of NDAs. Because they work with Laravel. So they came to us, and they're like, we start this product killer. Well, can you take it from here, or, or we have this big product. And our team is over load. But there's this three other features that we have to build. Can we take over those because like we give them the full squad, but there's, we can have a split like their team, their in house team is taking care of x and y, our team is taking care of z. And that's also something that sometimes works in but we only take those customers if they are in the perfect framework, the perfect setup for us to work with them.

Tim Bourguignon 27:14
Is there a potential clash between this helping those big customers and insert yourself in their world basically, and acting as a as a product team, as you said, so really thinking end to end when you don't really have control on the end to end thinking in the users when you do not necessarily have the users at hand? Because you have some kind of of company in the in the middle? You see what I mean?

Phil Alves 27:40
Yes, yes. So there's definitely sometimes there's a problem. And also there's a people don't understand the difference between hire a consulting firm, and hire an HR firm, like, I stopped thinking mentation, you know, so sometimes they think, Oh, we just need some extra developers. I'm like, great. If you just need extra developers, that's not us. If you need developers who started shrinking designers, QA is someone that can really take a they can only project then that's us. So there's the crash when sometimes the the team doesn't understand why they're owning this, or why they're asking to speak with the customers, why they want to do job to be done interviews, because that's what we do. We are here to view your product. We are not here to write code. Let's write code. That's not us. You know, so and that happens many times because maybe the person that hire us, they really bought in what we offer, why he forgot to sell everyone else around him. Like what the hell is

Tim Bourguignon 28:46
nothing heavenly. You cannot see it, but I'm another Yes. How big is that squad? Were about 100 people. Wow, did you still have time to go?

Phil Alves 28:59
Yes, but not for clients. I have my own product. And I and I got things on the weekends. And yeah, honestly, I'm not a very good developer anymore, but I still do stuff.

Tim Bourguignon 29:13
Use of short. What was it for you to graduate or transition from being a hands on everyday developer to not doing that anymore? Was it natural? Or did you fight against it?

Phil Alves 29:31
With a little bit of both, I want to do more of developing but my personality. I have ADHD. So I always want to be doing a bunch of stuff. And I have a very easy time simplifying complex topics. But I also get bored super easy. And so I think was a natural progression for me because now I'm that person that has the technical knowledge but but also has the business knowledge so So was it right transition But I had a hard time letting you go because I want to be more there writing code. But then when I start write 20 Pull requests and my developers like, What the hell is this? And so, for me, what was was the great move, like so I, I code now just for fun and for joy. And when I'm like, I, it's kind of like watching Netflix, for me coding at this point. Sometimes I'm sitting in my sofa, and I'm like, Oh, I'm gonna write this, whatever. Or I watch a video like Lara quiet like casts, like the Laravel website where you learn, and then I tried to do it. Okay, I want to do exactly what I just learned. So this is what it became for me. Like the development part, you know, like, or, I might do a POC, like, Oh, let me try this, like, let me go force postman here. Let me see how this API work. Let me see if this is possible to do before, before we go and build this. Like on my own SAS product, I do a lot of that. A lot of POCs in but there's not any code very, very little code that I wrote in production, even on my own SAS product. So yeah, one way to, to answer codes vary.

Tim Bourguignon 31:17
I'm asking because I fought against it so much, I remember I fought for years, and I quit jobs to to continue coding, and not do the other thing. At some point, I embraced it. And now it's history. But really, for four, five or six years, I was fighting against it big time. And so I'm always interested in how people manage

Phil Alves 31:36
it probably were very good developers, because like, I have seen that in my own company. As I'm getting people going up the ladder, and the very good developers, they will have a harder time because like, when you start dealing with people and things that variable, it's a lot harder things into how you want to go back to your, your, like, IDE, and you can write whatever you want, and always works like you like how whatever you want. So like, because I was like always like, kind of like average, I was kind of happy to, to move on. And

Tim Bourguignon 32:11
you mentioned you mentioned a couple of times your your, your assess project, is that def stands or that's, that's, that's okay. So that's the second company you you created on the side, because you had too much free time, right?

Phil Alves 32:30
Well, the thing is like, the more that they have squat grew, the further I was from the real work I like to call real work. And I was like more invasion, so I'm not seeing the stuff happening anymore. And I want to actually be there creating product building products. And the way that I found to do that, that wouldn't like hinder that squat scalability, because it can depend on me, the founder, was to start the SAS product. Because on my SAS product I have, I have my own squad, I play more of the Techo product row division, I can test this stuff, and then tell the whole company like Hey, guys, this is how I did that I can do trainings. And we can do different stuff, apply things and buy a product that can be applied for the whole company. But the whole idea was to because I wasn't enjoying my job so much anymore, as I was too far from real work Alexei, so I was not doing much deep work anymore. Like the bigger the company gets, the less and less like the CEO and the founder has the opportunity to do deep work, you're running from meetings to meetings like and then like things just come to you when some shit hit the fan. And they're like, Oh, this isn't wrong. And so it's not so fun anymore.

Tim Bourguignon 33:50
Unless you like putting out fires.

Phil Alves 33:57
So so that was the whole idea. And also

Phil Alves 34:01
my whole goal for four years, like building development teams, and was to build high performing development teams. And the whole thing behind that starts it's to, to help teams become high performing, and at the same time not getting burnout. So how can we make sure that the developer experience it's amazing work and build a culture of safety and transparency, help developers be more efficient. And then I read the research of Daraa metric. And more recently, there's a space framework with search and based on those research, I had an idea me and 20 other people to build a software to track out information and to help teams be more productive.

Tim Bourguignon 34:46
So I pictured this was a chosen set of metrics that are not too intrusive going going on their on their codebase going on, maybe some tools to use and gathering some some balanced metrics. To see the health of the team, if they're going fast, but not too fast if they are producing them to the right, Kevin's but not not creating a mess in the background if they have some some, some some trouble article that said some issues sometimes in production, but if they recover fast, so you don't want too much issues, but you want to less issues as well. It has to be a balanced amount correct with assuming of this?

Phil Alves 35:26
Yes, exactly. So so you're tracking like cycle time? Like how long does it take from when we start test when we finish it that can work in tracking working progress? If we have too much work in progress, something's wrong, we're probably overly overloading the developers, we are tracking how is the code review being done? Like, is there enough communication is the code review is low enough? Because we have learned over the years that code review is the best place to grow developers, like when you have a culture of code review is a culture where everyone loves it, because they're getting better they're learning with more senior peers. So you're looking at like, how is the code review being done? And then you're benchmarking against like the normal things? Like, what's our change and failure rate? Like, what's the percent of times if things break in production? How are planning accuracy, we say we would do this, how much have we done, if you're always doing 100% of what we planned, something's wrong, people are afraid of taking risks, right, so and so like the benchmark, you want to be between 80 and 90%. But like, sometimes you're gonna have worse, worse spreads. And, but the whole idea is to give data that the team can look together and can figure out how they can get better. I think that data alone is not going to make a team high performing. And I am a firm believer that starts with the right culture. The coaches the foundation for high performance development team that I'm trying to move, I'm just trying to build the software to support a strong culture so they can keep growing. And they have the data to to know that they're getting better, you know, so the OKRs are getting better and stuff

Phil Alves 36:59
like that.

Tim Bourguignon 37:01
They're very helpful, very helpful. Do you see yourself continuing with Dev squad? And that's, that's for the years to come? Is it's in your plans? Not revealing too much, obviously. But

Phil Alves 37:14
yeah, so I think, I think so

Phil Alves 37:16
I think I'm really enjoying both, I think, to be honest, is that was quite keep growing, they, that was called probably will need a professional, real CEO. And then I may move into more of a divisor row as the company grow a little bit more. But that's, that's in the very early beginning. So I see my, myself doing a lot of the founder and lead role for a long time. You know, like, there's a big difference between a founder and a CEO founders take risks, they love to create new stuff. But then when we start to get a company that's a little bit bigger, they go, it becomes to not to die. So that's why we see, like so many companies is the group, the CEO is not the same anymore. Because you have to keep changing, if you're willing to keep changing, that's okay. So I believe that Scott's gonna keep growing. And I'm probably have a couple more years as the as the helmet adapt squad, and then I probably will have someone that is better than me at their job. But for live stats, I think I still have many, many years to go.

Tim Bourguignon 38:22
They're very, very helpful. And that's very true. Very true. It's appealing, appalling to see sometimes companies and you see, the founders were so much the energy bringers. And they put everything in motion, but they just cannot let go. And you see the company starting to flatten out and I this is not running smoothly anymore. And at some point it starts. It's not going down. So yeah,

Phil Alves 38:46
yeah, I believe that if I wanted I was quite to accomplish the mission that I set up the company to accomplish. I has to be bigger than me. And I have to get out of the way at some point. That's just the reality. I love like that squad generates a lot of jobs back in Brazil or originally from and it's really helping a lot of people and it's creating an impact for our customers. But I think it to keep growing and keep making an impact. At some point. It's going to be bigger than me, and I have to get out the way.

Tim Bourguignon 39:17
I see. I see. i There is an advice that is trying to form in my mind right now. But I'm not sure it's going to come out right? Well, let's see. When when a new developer comes into your teams, I assume you're going to tell them okay, now you have to go deep now you have to understand Laravel and the stack we're using really well to be able to become performance in the in the stack we have chosen but at the same time you're probably asking them to go a little bit broad and understand why we're doing this and how it compares to other technologies right and left and what why we do we do it this way. How do you advise newcomers in your company to handle this and start learning robes but still managing right and left. I'm not sure it's really understandable whatever, in my mind either.

Phil Alves 40:13
No, no problem, what we do, when we're hiring developers, we make sure they know Laravel. Before for, so we use hacker Hank, and we do their own proprietary test. And we have different level of tests for different places where we spec the developers to be. For our business model, we like to have developers or mid level and senior, so they can come and they can contribute it and senior on our stack, because that that word can be used in many different ways. But they know the technology very well. And so from there, we are interviewing your trainee for mindset for the way that we think, well, the tech knowledge, or your oil, kinda like wanted to be out of the way. So you want to make sure that you know, the technology and that you understand the framework. And if there is things that you have to learn the framework, we're going to teach you to pair programming we're going to teach to, to code review. And then there's our part of that, like, they get like a body, when they get on board, they're going to get a mentor that's gonna follow them for like, the next four weeks, teach them how we do stuff, how we do code, review how we think about approaching the tasks, how we break down tasks, how we write tests, and then like, what they did in their mind. But today, the biggest thing that we are doing is around mindset is around helping them understand how we think. And having the product mindset because that's something that they probably not gonna have until they start here. So for the interviewer just checking if they, if they can get that.

Tim Bourguignon 41:48
How do you change that?

Phil Alves 41:52
How do I change it?

Tim Bourguignon 41:53
Now? How do you how do you check that, during an interview, if somebody has the right product mindset,

Phil Alves 41:59
we asked them about products they like, we asked them about how they were they would change and we asked them about the products they work before what they will have to do. And so that's kind of like how we check.

Tim Bourguignon 42:12
Okay, so seeing, seeing if they, if they went away from the code, where where they were and thought about the bigger picture and what's what's on after my code, what comes next? And how does it feel to the whole picture? That? Yes, that's correct. I see. I see. Awesome. Okay, so, so having some kind of plan of things you want people to, to match toward? And then kind of iterating Okay, do you have these do not have this? Where can we, we accelerate you and, and slowly covering the whole spectrum of skills you want them to have? I see. Yep. Awesome. Awesome. This sounds like a fantastic business you hear? Most of the times I assume it's not it's not things everyday. Joe, thank you so much for for showing us this part of your life and showing us how you built that squad and, and talking about that that little bit. And that's was really fantastic. Thank you so much.

Phil Alves 43:17
No problem. Thanks for having me. Oh, it

Tim Bourguignon 43:20
was it was my pleasure. Where can people find you online and see what you do? And maybe contact you and good use discussion? Yeah, so

Phil Alves 43:27
you can go to a few offers that are calm, pH ILLV s.com. That's going to be my newsletter, and you're going to see everything in there. My link for dev squad, the link for that starts the link to my podcast. It's all on my site to always calm. And you can also go to dev stats and sign up for the free trial. It's the E V S, T A. T s.com. I think that's it kind of

Tim Bourguignon 43:54
sounds about right. Just get it right.

Phil Alves 43:59
stats.com and sign up for the free trial. There's no credit card required or anything and see if you can maybe use that in your own team and help you guys to be high performing.

Tim Bourguignon 44:10
Awesome. Phil, thank you so much. Thank you. And this has been another episode of Devil's journey. I will see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Would you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m OTHEP. corporate email info at Dev journey dot info talk to you soon