Developing teams and getting them to work better

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are going through a bunch of excellent interviews. This episode, we are going into the second half of our interview with Phil Alves. We are going to talk about developers, about developing teams, and about, in particular, how to get your team to work better. We've touched on, in the last episode, we've touched on Scrum and Agile, and we are going to get more into that in this episode and talk through just some of the modern ways to do better as a team, to be better developers, not just individually, but as an organization or for whatever your team or group is. Let's get right back to our conversation with Phil. Another thing that, because you've been in this for a while, what are the trends you've seen in development itself, in software products and solutions and the services that people are coming to you to say, hey, we need you to build this, fix this, maintain that? Yeah, when we talk about trends, I think one thing that I really try to avoid is following the hottest new trend and make decisions based on the foundations of my beliefs. One thing that I saw in the last few years, for example, and I never got in that train, was the microservice boom. Everyone decided they needed a microservice. It didn't matter that they have four developers and they didn't have a huge team. They want to start with a microservice and they want to over and overcomplicate the architecture. Then there was a lot of money in the market, and then now you need a team of 50 developers to build a crud because people are overcomplicating and everything is separated too early. For the longest time, I was like, no, we don't do that. We want to build going zero to one. We're going to build products that have a simple architecture. People are like, no, you were outdated. That's what everyone is doing. That's what Netflix does and that's what Twitter did. I'm like, well, they didn't start there. Even if you look at Twitter nowadays, you can see they're really struggling. I think the company that's supposed to be running for its small team is harder to run if it's small team because they have too many complexities. What I see in tech and anywhere actually, things usually go full circle. We think we are developing, but we're usually just going around and around and around. Now it's kind of with less money on the market and it's cool again to be simple and it's cool again not to overcomplicate it. But I have been saying that for the last eight years and people have been calling me crazy. It is the thing with trends. Now everyone wants to be AI company. I'm like, yeah, AI is powerful, but are you sure you have to be AI company? Two years ago, everyone wants to be the Uber of X and most of them failed. Now everyone wants to be the AI of X. I think trends are usually a bad idea and you have to make decisions based on the foundations of your beliefs. Maybe a trend makes sense, but it has to be based on the foundation, not because everyone's doing. How do you handle it when you've got a customer that comes to you that has a goal? They're like, hey, this is where we want to go and you're looking at it saying this is not... They want to be the Uber of, I don't know, whatever salads or whatever it is that they pick. You're like, I don't think that's going to work. How do you have those conversations? Is it something where you just usually are going to say, hey, this is not a good fit? Or are you going to try to work with them to say, hey, maybe we can find a way to make your goals work? How do you do that, particularly now as we just talked about, that you can sort of be a little bit picky about who your customers are? Yeah. I'm going to have a conversation with them. I'm like, okay, look, if we're going to build a two-side marketplace, those are very expensive place. Have you look at how much those companies that build marketplaces have raised? What's your ability to raise that kind of money? Can you raise that kind of money? I think it starts a funding. How are you going to fund this and how are you going to sell this? I like to talk with people about go to marketing strategy and funding strategy. If you're going to build the Uber of X, you better be very good at raising money. If you don't have the connections, if you don't have the degree from the right university, they didn't work at the right company, it's going to be very hard. I have those conversations and I'll tell people that I don't think that would be a good fit to build that product because I don't believe in the product and I have to really believe that it's possible. Now, as I'm asking those questions, maybe the person, and it has happened before, look, I had this exit. I work at Facebook, I work at Google. I'm coming with this one person and he was a CEO of a public company and we have the money, we're going to fund it and you're going to do this, this and this. You know where you're getting yourself into. You understand the complexity and then you just go with them. Yeah, there's definitely been those where you question it, but also they've got a background and I think that's what investors look at that too, where they'll say, oh, this person, there's not a lot of people doing that, but this person knows it, they've done it before, so we're going to back these guys because they think they can do it again, so we're going to believe that they can do it again. Yeah, we have, we might consult a firm on this whole process called the Sprint Zero. In the Sprint Zero, we do the Canvas business model with them so we understand their business model and then we interview some of the potential customers, then we do a clickable prototype, we do some tests if they clickable prototype and then from there, we have some more validation and we can go and build the actual product or we can be like, hey, that's not validated or honestly can be like, hey, this is awesome, it's going to work, but I don't have the resources to build your product. Here's your validated idea, go find someone that can do that for you. So I'm gathering that you use, one of the things you do is you use Scrum on a fairly regular basis, sounds like you sort of have some agile teams because you're using sprints and things like that and you've talked about some of the rituals and that. One thing that just to get somebody that I think it sounds like has done that a bunch, if you've got that many teams is what are your thoughts on what makes a good Scrum Master? Because I know that's something people have all these different pictures in their mind, but I think that's something that if you've got that many teams, obviously you've tackled that question a couple of times. So what is it you're looking for? What have you seen that makes for a successful Scrum Master? Well, I think the Scrum Master alone, it's not going to be able to move the software in the right direction. They have to be partnered with a Scrum Cova product owner, but I prefer product manager because product manager is a career and a product manager is responsible to make sure that what we build is going to have impact on business and it's going to really move the needle. The Scrum Master is usually an engineer manager, is someone that's going to hold all the processes in place. How are we doing code review? How are we doing daily? How things are going? Are the codes small? So it's just a very process oriented person, but you can have the best process in the world and if you're building stuff that doesn't have impact, the output is not going to be what you want. So one addition that we do to Scrum teams is we want that product manager piece and then he works together with, he's a Scrum Master. We call them the engineer manager in our organization. We don't call them Scrum Master, but that's how we do it. Yeah, I guess that is one of those that the titles can be a little bit confusing to people. Product owner, like you said, in particular, that's something that once you get out of the Scrum world, that's usually a product manager and those are people that are, it's sort of interesting because they are the flashy front end because they're building the ones that are driving that product and you've got the developers that are creating it and you've sort of got this Scrum Master, the engineer in the middle that's just trying to make it all work and it's maybe not a glamorous job, but definitely one I find is very key to a lot of those teams. Yeah, I think there has to be three players involved in building products. The first is the lead engineer, the product person and the design person. Those three people have to really work together to move a product and each of them represent one important stakeholder. So the designer is representing the user, the product manager represents the user, BIOS represents the business and the engineer manager is deciding what's feasible, what's not representing the developers. And that's the trio that they have to work together to build high performing teams. It's very important that we don't have that one person that just go and it's like the face of the star. It is complex. One of my favorite books on the topic, it's called The Five Dysfunctions of a Team and it's not a technical book per se, but when we're starting our conversation, you're like, we have problems that could review, are those problems could be solved if you address the five dysfunctions of the team? Yeah, that's one I don't think I've mentioned very much, but Patrick Lincione there is, that writes a lot of good books that are on teamwork and becoming a high performing team. So I highly recommend, I'll put that link out in the show notes somewhere as well because that's one of those, it's a good read and it's one that I think you walk out of it going, okay, now we can look at problems and tackle them in a way that's actually tackling the problem as opposed to slapping a bandaid on it or something like that. Exactly. Now you mentioned that when you start out, again, so like me, you start out, you had to read a book to learn and it wasn't the same landscape at all for software development as it is today. What is, this is one that's just, I get that, I only ask this of people like yourself that have been doing this for a while, I say, what is maybe the one tool or thing that's, advancement that you've seen that has really made a huge difference in software development now versus software development years ago? My favorite tool is a framework called Laravel. I just find so amazing how quick a new developer can become productive using the framework because everything was put in a place where now they can just come in and build products. All those decisions that we had to make over and over and make a lot of mistakes now are made for us. It's like now I'm a junior developer, but I have an architect that made other decisions. This is how the queue system is going to work. This is how the email system is going to work. This is how the testing is going to work. It's just like, actually I have a very young brother, he's going to college and the teachers are like, hey, we need to learn the foundations and you need to learn C and everything because before you actually learn to build products, and I believe the opposite, I think that's why so many people drop out of school. It's because it takes so long for them to put the pieces together. Nowadays it's very possible for someone to kind of like to make an analogy, sit in the car and start driving before understanding how the car works. And that wasn't possible when we started. We had to really bring all the pieces together. And then it was a lot more like grind, I would say, because now the real world can come a lot quicker for someone to start in the career. Like a lot quicker you can be productive. And I even see that in other spaces in our tech, like designers with Figma now, how quick they are able to start to be productive and to get things done. And in my days, people use Photoshop to build stuff. It was not even a tool to build applications, and it was a complex. And then I remember receiving a PSD and I think we called, oh, that was a thing that we call when you're converting the PSD to HTML. I forgot the name now. So it is over the years, it became a lot easier and a lot more enjoyable to write software. That's basically what it is. Yeah, I agree. I think that's one of the things that as I look at it, that's probably the, when I look at the tools, it always is the outcome of being able to get to an application and use it or see it or put it in front of a customer sooner, as opposed to spending hours of writing codes and compilers running and all of that stuff that we used to have to go through in the past. Yeah. And it allows, for example, a lot of small B2B SaaS to be super competitive with a team of two, four developers, because how easy it is to build software nowadays. That's why I think big companies like Salesforce in the next 10 years, it's going to have a hard time because now you have CRM for everything. It's a CRM for car dealership, CRM for financial advisor, CRM for accountants. It's because it's just so much easier to build software and it's so cheap to create software. I believe where it is now, and even more and more, it's like, what is the real world problem that we're going to solve? And it's easy to write code for that. And it's getting easier and easier and easier. Now you can ask ChatGPT a question or AI or GitHub co-pilot. You start writing the code and it completes for you. So your job is just to solve problems. Yeah. And I think that's the dream that it's always been is getting to pointless because it's never been to, for at least most developers, it's not to write code, it's to solve problems. And so when you can more quickly get the computer to do the things it needs to do to solve the problem, then that speeds the whole process up. And then of course, that allows you, those things like Laravel is a good example. You have all of these common problems that are now solved for you. And so now you get the time to, instead of, you don't have to worry about those. All that time you would have spent dealing with those. You can spend working on more complex problems and solving things that are even more advanced so that the business now has more things you can offer them than just a spreadsheet or something like that. Now you've got these very complex solutions you can get to them. For sure. Now, as you built this team up, because you started as a developer and you obviously enjoyed it enough because that's where you wanted to go, how have you, I guess, how have you have adjusted as you've gone in? Because I'm assuming you're not writing code every day and stuff like that, once you've got all these teams that you're managing, how did you sort of progress through that and sort of grow from a, you know, I'd say very much a technician, you know, a coder into somebody that is, you know, leading coders and then, you know, now running a company full of coders? Yeah, again, I like to put the book that had the most, that was the most influential for me, that transition. It's a book called Emit, and it talks about the transition from the technical to the manager to the leader. And it is a very complex transition, to be honest. It takes time. Sometimes you want to go back and you want to just do it because it's quicker. I'm very lucky. I'm in a point today that I cannot code better than any of my developers. So, and it's kind of anything that I do is just took as a proof of concept. There's no code that I write that goes into production almost never, but it is a different kind of thing. And I enjoy, I kind of enjoy learning a lot about a lot of things. I love the 80-20 rule and that's kind of like what you have to apply, you know, like what is the 20% as an entrepreneur that I need to know about how to create a strong culture so I can create a strong culture in my firm? What is the 20% of market that I need to know? What's the 20% of product that I need to know? What's the 20% of development that I need to know? And that's, you become kind of like your range has to be a lot bigger when you go from being a technician to being an entrepreneur. And your strength might still be the one thing that you start as a technician, but as the years goes, that will go away too. You know, like maybe years ago, I was so close to the code and to building stuff and now I do a lot less often that everything that I do is just a proof of concept, you know. But I think it's making that transition from being an expert to being a jack of all trades. And it changed too, like, you know, this person may have to be from zero to 10 employees to 10 to 50, 50 to 100, it keeps changing. And that's why at some point companies being professional management because founders might not be able to keep changing at a pace that they have to change. And the main reason I did my software is because I want to go back and be more involved in the day to day of building software, less in the day to day of running our organization, a bigger organization with a hundred people. And so I was able to mix both with DevStats where I have a team of like five people and DevSquad where I have a team of like almost a hundred people. And I get to kind of like do both, but it is definitely a big transition and I don't know how to teach people, but the Emitbook, it's a book that helps a lot with that. Excellent. Yeah, that's because I think that's something that a lot of developers struggle with is where they go because there's that technical path of learning more languages, learning how to solve more complex problems, learning whatever the new framework is and stuff like that. But then there's that bigger growth and being able to scale out and how to transition into that. Now I want to be respectful of your time and thank you so much for coming on and a lot of great points you've made. So for those who are listening, what's the best way for them to get a hold of you and also to test out your products because I think both are to take a look at them because I think these are the kinds of things that developers, even if you haven't, even if you're coming, he's not using it, make it something good to know that these things are out there and these resources are available. Yeah, so especially people that are leading developers and they are maybe a senior engineer in a team and want to help their team grow, DevStats is a great place to start. They can go to devstats.com, they can make a trial, don't even ask for a credit card and they can use the software, see how it works and look at their benchmarks right away. So that's probably the easiest way. People can also find me on LinkedIn, fioavis.com, sorry fioavis on LinkedIn and fioavis.com is also my website. I have a newsletter. I don't write very often but I do write sometimes, maybe once or twice every quarter but it's a good place to go and stay in touch through my newsletter. Probably you're going to keep hearing from me from time to time. Excellent and obviously you've got a great background and a lot of stuff. You're get that finger on the pulse so I'm sure those are great articles and it's great to keep up with somebody like yourself that's maybe not on the bleeding edge but definitely the leading or the cutting edge and able to help us figure out where things are going. Yeah, for sure. All right, well thank you so much for your time. Thanks for coming out and I hope that everybody is heading your way and checks out your site and your products. Hey, thank you. Thank you very much for having me. And that surprisingly enough or not, we'll wrap it up. I want to thank Phil for his time, for spending some time with us talking through his background and what his organization does and how he got there because I do think it is very useful for us to see how someone that didn't go through the academic world of certifications and schooling and stuff like that that was specific to software development still comes out with some very key things that we hear about a lot and maybe this just reinforces that these are important things for us to do, that we should think about things like code reviews, that we should be working with the other developers in our team to help ourselves and them grow and to become a essentially a high functioning, high performing team of developers because we work as a team, not just in our little silos writing some code. Don't worry, we are not done with interviews. We will continue them next episode. We may change pace a little bit, but we'll leave that as a surprise so you can come back then. But while you're waiting with bated breath, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there and remember just a little bit of effort every day ends up adding into great momentum and great success. you