#5 We Are Here To Create a Team of Leaders | On Leader Superpowers, Why You Need to Stop Coding, RFCs by Joao Alves, Engineering Manager at Adevinta

We are here to create a team of leaders. Everyone should be able to represent the team everywhere. I really believe that smart people, they do a better job when they have more confidence. You realize that if you keep coding, you will neglect your first and main job, which is make sure you are there for people and for their development. People management is truly exhausting. I encourage all people managers to take time to think, think about the career development of your people, think about what's going on in the business, think about what's going on in the team. Hi, welcome to the Agile State of Mind Podcast, where I deconstruct the role of engineering manager. Try to make sense of the role confusion and understand the challenges of the transition from a developer to a manager. You can find this interview both on YouTube and as a podcast, the links are in the description. And today I will chat with Roa Alvish. Please tell me if I managed. Oh, it's pretty good, man. I tried. I practiced when I was working with the Portuguese company, our systems. Roa is an engineering manager at Adavinta, formerly ship state, an ordeic Norwegian company, headquartered in Barcelona. Adavinta is a digital marketplace, connects buyers and sellers, helping people find jobs, cars, consumer goods. You probably know the pages if you buy something second hand usually, but you probably don't realize it's Adavinta. And recently, the company acquired eBay, right? Yeah, partially, right? The classified group of eBay. Okay, so that's like please something that everybody knows. And guess where we met? We met in free now, of course. I think I need to start doing interviews with people that are formerly from free now. And just to me, it seems like the best leaders I knew worked in free now. And at that time, when we worked together in free now, Roa used to be back in chapter, and apart from that, you can find Roa on Twitter at Roa Q Alves. I will add the links below because it's not straightforward. And you also have a blog, World Hey, Come, Roa Q Alves. And it was interesting because I learned that you write in four languages, basically in English, Spanish, Portuguese, and Catalan. And you are a true polyglot. You beat me by one language. Nothing unfair. Yeah, I object. And on your Twitter, I read that you are a software engineer by heart. Tell us more. Yeah, so I truly believe that a leader of something should be well versed on the subject. Maybe not the best software engineer in the world. Maybe not the most geek person in the world. But I think it helps a lot, bonding with the team and making sure they see you as more than a manager, as a peer. And to me, that was really key in the relationship I built during time with all the teams I worked with. So at the same time, I run some side projects myself. So I still feel some passion on building software. I don't do it every day at Aradinta, but I do it a bit at home. I try to balance a bit learning new things. So I don't get out of game. Yeah, that was my question because I know you. We work together. So I remember how passionate you are about the coding. And I would like to understand a little bit how do you feel? Because I do this podcast especially for developers that are thinking about changing to the role. And they are thinking like how much they love coding. And how much they might miss it when they move to the role. So how was it for you? I missed a lot in the beginning. Actually, one of the mistakes I made was to keep coding too much, I would say. And this is a classic mistake. And I also did it. Yet, after a while, depending on what's your desire for your progression, you realize that if you keep coding, you will neglect your first and main job, which is make sure you are there for people and for their development. Being a people manager is a full time job. And it's very difficult to do both things. Well, there are people like charity majors. She says, if you think you are doing both things well, you are probably wrong. It is a bit like when you talk in the classical understanding of a full stack developer, isn't that a bit similar? That if you are good at everything? I think it's a bit different. I think you can have a good enough understanding of the full stack and the work well on that regard. But people management is truly exhausting. If you take time to think, and I encourage all people managers to take time to think, think about the career development of your people, think about what's going on in the business, think about what's going on in the team. You realize that between that one-on-one, squareical work and making sure everything works together, you have a few times to do coding if any at all. So I think it's a bit different. When you are full, stock your primary job is to code. And of course, you may not be excellent at all levels, but you can have a good enough grasp of it. There's hope in them. Yeah, that's actually what I would like to understand first. And thank you for what you said. I think it's very important because I know a lot of developers that moved to the role of a manager and they are exhausted at the end of the day. Because you know, it's so much different. When you were a coder, you were like, okay, you could focus for a long stretch of time. And then you didn't have to have some social interactions, which you right now do, right? What would be a tip from your side to those people at the beginning, when they move and they suddenly are overwhelmed? Like, oh my god, nobody told me this is administration work. I didn't apply to be an admin. Yeah, good one. So my only tip I would say, control your calendar. Don't let your calendar control you. Right? So this is pretty typical to many people for developers, but also for managers, especially for first-time managers. Make sure that you are the one in control of your calendar. You said when you are going to go to meetings, when you are not. Distributes a meeting, especially one-on-one throughout the week. Make sure if you have 10-101-51 week, five of the other week, and something like that. Avoid one day fully of one-on-ones because that's truly, truly exhausting. And you don't have even time to think about the feedback you want to give to people, which then it shows, right? When people receive back feedback, they realize them immediately that you didn't think about it. So this would be my first and only tip. OK. And do you have, since we are on the one-on-ones, do you have like a template or something that you use? How do you do? Like do you make notes? Do people add notes? How do you do them? And what are the topics that you usually tackle there? Yeah, so I share a document with every person. It's a Google Docs, pretty collaborative. We both see what each other right there. I try to put topics that I want to talk about in the next one, when I want before the meeting. And I encourage people to do the same. So we can prepare a bit before. So I take notes of everything. And people also take notes of what they find relevant to track actions. And these actions and all the flow is visible by the both parties at any time. So it's a shared Google Docs. And for a template, usually I start with a bit of a cheat chat, but something, what happened in your life rather than going straight to work. But what happened in your life? How is your dog? If I know that person was getting their son or their daughter to the hospital, I ask, how is he or how is she? So trying to get a bit of bonding. So human interaction. Human interaction. Yeah, human interaction is really important. So it's not just a transactional work thingy, especially after the pandemic and after COVID. I realized that many interactions became transactional, only talking about work. And it's pretty important that people feel that you are interested in their lives. And you also share your thoughts. So I also tend to share a bit of what I do, what I'm up to, is kind of things. So we spend a couple of minutes depending on the topic and how winter is we are on the topic. It ranges from five to 15 minutes of the one and one. And this also allows me to make sure I understand people that. So if I see someone is single and they live with their dog, they are looking for social connections in the company. I already take these into consideration and make sure we create team lunches, we create opportunities for socializing and it's kind of things. It's not transactional yet. I take the time to reflect on this human interaction. And then the usual template is to ask different questions, how do you see the team, how do you see your personal growth. I try to change topics every one and one. Not everyone and one is the same, but I'm not always the same questions. And I also provoke thinking on people. Trying to ask the, sometimes it's the same question in two different weeks, but in different form. Right, so give me feedback. What is the thing that you are not doing and you'd like to do? What is the thing that you would expect me to do and I'm not doing these kind of things? So this is my template. I will pass through the link afterwards, but there's a GitHub repository with awesome questions that you can just pick and say, oh, I will ask this on the next one or not. And sometimes just changing and framing of a question will give you a lot more information that I produced a question that maybe it was too obvious or too transactional. Wow, that's great. Yeah, please. I will answer the links in the description because I think it's so great to have a one-on-one that's actually, like you know that somebody put thought in it and it's not just like, so how are you? Yeah, okay. And then you start talking about the sprint, basically, right? So then it's like, yeah, where how can I? But then I my question is, if you do you ever talk about like, okay, it's something happened and we need to talk about this? Or if you have one or once every week or every two weeks depending how much about the growth can you actually talk like you already know what the person wants, do you like review the progress or? Yeah, it's mainly about reviewing goals and pushing people to be a better version of themselves, right? Sometimes so the first realization is that people suck at putting goals. I suck putting goals for myself, right? So it's always helpful to have someone that pushes you and challenges you and say, look, how is this progressing? Let's put a deadline. So people hate the events, I hate the events, but they are really effective when it comes to make people action on their release. And also sometimes people they have a new, those way of defining what where they want to grow. The job then becomes giving them the right resources to open their minds on what are the possibilities. So sometimes people they don't know what are the possibilities for growth. It's not only management, it's not only tech leadership there are broad set of functions that people can develop. And it's not only just to pull the ladder, right? It's not just a clean ladder. It's about going broad on your skill set and making sure that people understand that it's not just about an expromo. It's about developing their own skills for their own good. It's not just about developing people for other inter. I would love people develop their skills inside of the internet. I push for that, but I'll be totally happy and totally find if people develop their skills set and they find something better somewhere else. Right? I'm attached to the people not exactly to where we are right now and where we are working right now. This is mainly the part at that part. So making sure people they follow up on their goals and making sure they reach them or we can change them. If people they are stuck because they can't do something, making sure you say to them, you have the time to do this. I support you doing this. You can do this inside your working hours because sometimes it's not clear that you should work on your personal developing during working hours. This is especially true for parents or for people that they have some activities outside the work. So this is mainly what we do. Right? So it's not just always talking about philosophical roles. We do that like one sort of I say here, but following up on on specific goals. Okay, that's very noble of you to let people develop themselves. This is where you actually inspire people and motivate them to work, right? Because they know it's not only about pushing them for results and the current delivery. It's about just feeling good and feeling that you are improving and learning all the time. Thank you for that. That was very interesting. And could you explain a little bit your role? Because I try to deconstruct the role here as well. And as you probably know, we have engineering managers, we have teamlies, we have tech lead and it's very confusing and there's no one definition for each of them. So I would like to understand first what you're doing right now, but also how this is different for what you are doing in three hours. You were the chapter. Interesting question. So right now, I consider myself the CEO of the team. If I'm allowed to do this analogy. I take care mainly of creating systems at work. What I mean for this is making sure we have the right talent, hiring and growing people, making sure we have the right budget. I'm responsible for the whole cloud budget of the team and making sure that we stay on budget, making sure we do this kind of non-sexist thing that makes things work. And then construct systems at work. I mean, making sure that the team works. We do ceremonies, whatever the team finds necessary for planning or hand-ups or retrospectives, empower the team to run these themselves. I'm not running startups, I'm not running retrospectives, I did, including by example, and then we found a way to create a system that doesn't need me, right? So this is the ultimate goal. The team should not need me to work well together. Then the relationship with stakeholders, both other teams inside the organization or in different departments making sure we are listening to their concerns. In this case, it's a need to give a bit of context because we are creating an internal product for engineers inside the Vinta. So it's pretty important that we listen to their concerns, that we have a clear product backlog, that we are constantly fitting with feedback from our users. So your customers are the other employees over at the Vinta that are in the same office and you can go and just ask them like, "Fut me?" Yes, it's a pretty interesting setup and also a challenging one. Whenever your users are engineers like you, they are pretty opinionated about how things should work. Yeah. So you are like a platform team that creates platform service. Indeed. I love how the analogy of being a CEO of the team. And what, how is that different from what you are doing as a chapter? Because for me, it's important to understand that there are still companies, I don't know how many of them, but there are still companies that have this kind of functional lead across, so like Cuckand or Frontend. Yeah, Gills or chapters or whatever you want to. The main difference for me is that inside a team, you have control end to end of the delivery. So you are also comfortable for the delivery of something. And while I was chapter lead, I was not really accountable of the delivery of anything because I couldn't be accountable for all the team. So when I was a chapter lead, it was more like a mix of staff/principle engineers, someone with the understanding of the technology and the understanding of these secretive systems and making sure we were onboarding people effectively into the technology so they were empowered to the livers things. And on the other side, the people management side was more again about the growth, but only are mostly sculpted on the technology itself. Right? I also find the chapter lead role was a necessary back then in print out because we were growing a lot from month to month. So onboarding people on specific technologies and aligning the whole Gills or the whole chapter was really, really important. So everyone was effective doing their jobs. Afterwards, we changed to these chapters to become engineering managers responsible for the delivery end to end. I spent a few months there with this model and then I joined at the end. But I find the engineering manager model more sustainable in the long run. So I think both they have a place, but if I was responsible to set up something like this right now, most likely I would set up a chapter lead with people management responsibility, making sure they were aligning the whole chapter and let the people management responsibilities be together with the delivery ones because I think this creates a good incentive for the manager, right? Because you become accountable for the delivery. Otherwise, you may optimize for something that is not the best for the company. Yeah, that's an interesting point, but what comes to my mind is especially in bigger companies where you have product teams because I I don't know how about if you have more teams in platform or just one team, but what I mean is that dependencies between the team. So if you have a team lead, let's call it to be clear, in each of the team, how do you make sure that then they somehow are aligned and they don't step on each other's toes, especially in those different like the front and guys don't recreate the will over and over because you don't know that other team already did this and the same for backend and the same for for other ones. How do you navigate if you don't have somebody who's like a croc all the teams? I think it's necessary to have people across the teams doing this kind of work. What I meant is that I don't think that these people should be people management, right? So I would separate here management from leadership. Yes, we need strong backend leadership, front and leadership that they work together as a group of leaders in specific areas, but there are individual contributors that they are focused and they are domain experts. So like tech leads now I learned that this is kind of a tech lead like Luis is working right now in Camillo, right? It could be. It could be a tech lead. I like what Will Larson is the city of calm and he was previously a VP of infrastructure at Uber. He refers to this position as a staff engineer, right? So people above senior that they have a more diffuse role across the organization and they one of the responsibilities is exactly this one making sure things are aligned across their discipline, but also with other domains like front and backend or systems and backend and it kind of thing. Okay, yeah, that's interesting. So yeah, so then you create quite a lot of leadership roles maybe, but in the end you need that because otherwise I worked with up to 30 teams in my previous company. We had RTEs. We had like crumb masters of scrumb masters kind of thing where we were people who were trying to help and facilitate the alignment and the dependency resolution and so on, but we didn't have this kind of role that would be very interesting to have. We had architects though, but the architects were just creating the solution like the diagram for the teams that they were then using. So yeah, why are you shaking your head? Yeah, so I truly believe on and fully empowered teams and why the world architect can be used in several ways, right? When I hear people doing diagramming, so other people implement these diagramming, and a bit on the fence, right? So I can tell you what our staff engineers do at the beginning to which I live. They do architecture, but architecture is part of the software engineers role, right? So every software engineers and of course they have the accountability of the architecture but they are not so responsive to the architecture. So I think this is the main distinction of how do you do that? Do you now we're going to like the RSC maybe? How do you collaboratively create architecture? Good question. Let's go back to what are the properties desired for our architecture. If we start from a point where we believe our engineers are capable of doing architecture and I believe that my engineers are capable of doing architecture then it becomes a matter of transparency and inclusiveness. How can I make sure our decision making is transparent and how can I make sure it's inclusive? So it's not just tackling it, talking with tackling it's in a meeting quickly but it is pervasive and ubiquitous across the computer. That's why I think writing becomes a super power. Why? Because writing scales really well if I share, if I write it once and I can share it like one thousand pounds and people can get exactly what I want to talk about. While if I do this through meetings I can be like three weeks talking with everyone to try to build a commitment across something and the result will not be as inclusive. So the request for comments that you were mentioning is a way to give transparency and inclusiveness to the organization and empowering people to say, "Okay, I'm interested in this part of the architecture. I will chime in here and I will put my comments and I will put a proposal. If I'm not interested in that other part that's fine that most likely someone else will be interested." So you create this, there's no decisions behind closed doors. All decisions are open. That doesn't mean that every decision is democratic or just going through pure consensus but there is a way for people to understand how all the sausage are made, right? How decisions are made. Instead of relying on some architects doing some diagrams in some room somewhere, right? Yeah. I like the part of inclusive that you include people in the whole thinking process and I love what you said that writing becomes a superpower. It really makes sense. But it's hard. I remember that when we were in free now you were the one to suggest to do RFC which is request for comments. So it's like a document where you create a proposal for some change and you are requesting comments from everybody or from some specific people that you would like to hear from. How did you manage to roll it out to the whole company? And that's I think at least to the Barcelona office, everybody started using it. How did you manage to do that? And as well, the next question will be, did you offer it in Ante Vinta or was it already there? Actually, the story is funny because the first time I saw RFC inside a company it was back in Shifter. I used to work back in Shifter, we started in free now. And what I realized back then is that it was a really inclusive way of doing things. So whenever I joined, right now I had this in the back of my mind and I realized that the company was growing a lot and many people were joining. There was a lot of decisions being made every day by really smart people. Yet some decisions impact other teams and there was no clear transparency on this whole process. When I realized that I also came across an article from Gagelioros. He was a Janie Manjard Uber. He also mentioned that RFCs were a thing that I proposed this to Tuneco. I bounced to my ideas with him. He was my manager back then. And he just encouraged me to do it. And the way I went about it was I saw a problem and I took the ownership of doing the first one or the first couple of RFCs myself. So I took the time. I wrote there, I explained it to people what it was. I had some conversations with other managers and other engineers. But by having this conversation that was I was able to see, okay, this person is really keen on this. So let's leverage that this person is like a support or a champion of this idea and making sure that this person starts putting comments and starts creating like a virtuous circle of so other people can say, okay, I see that this engineer is commenting. So why I'm not entitled to do it. I'm also entitled to do it. So making sure you find the champions that support your idea is important. Making sure you own the thing and you are leaving by example. It's not just throwing the idea in the air. It's also owning it. It's also leaving by example and explaining to people by doing how usually this kind of thing works. And then this is contagious like a virus. So people they see the value, they see the transparency, they see other people commenting, they start commenting and in one, two months, three months you start seeing people creating their own RFCs and you don't do it's only to anything else. Right. So the system you created the virtual look and now it works by itself. That's great. So then you need to first do it yourself and lead by example how it should be done and then you find champions, the people that believe in it and then you get them to comment and then to also start their own RFCs. Yeah. Good luck to me. And then you went back to Adir Vinta and they kept on doing that. I think it's a pretty different company now because when it was divided from ships, some teams were revealed from zero because most of people were working normally and then Norwegian offices, it still is part of ships. Yet inside the team I joined, there was this culture of design documents which are quite similar to RFCs. The team was already very transparent regarding architecture. They were really keen on the idea already. So I didn't have to do much work on that regard yet. Cross teams, we needed to improve on the transparency cross team and there's where we could leverage the example of the team I joined and extend it to the rest of the organization. Also at the product level, we work in a platform team. Yet we treat our platform as a product. Right. So we have a product backlog. We have product owners, we have stakeholders, we do demos, this kind of thing. The product people, which are engineers in this case, they also are keen on creating these requests for comments and making sure they align between themselves and making sure everyone can chip in and give their ideas. Coming back, it was really easy. Yet this is scope to this department. There are other people in other departments that they also do it, but it is not like a cross organizational thing at least yet. But I believe that in the future we will be able to roll it out to more market. Okay and one last question of this topic. So if you are your clients are actually the other developers, how do you roll it out so everybody can see it? Do you usually just do it within your own team or would you like to get the comments from their real users? Good question. Depends a bit on the team and on who write or who shepherds the galaxy. We are pushing towards including the users in this process because we believe it creates value to be transparent with them. Yet we don't always do it and I believe we suffer from this and we got feedback from that. So people sometimes feel that there's a client providing relationship with teams where we should be more like partners in crime and we should make sure we work more together and we are more inclusive. Sometimes for the user it feels like we're working a very waterfall way by gathering requirements, black box and then we present a solution. While we don't work in a waterfall we were quite a gentleman. We tried to deliver small chunks that give value to the users. They don't see this process from behind the scene. So we realized that including users is a month in this kind of design documents and we did that recently with one of them and people were really interested in understanding things and in the case of other things as we are quite a big company and there are many things happening. We need to go one step further. It was not enough to share these documents to comment synchronously. It was necessary in some cases to have some reading sessions with people and to have some kind of interviews with them. So there was a closer relationship I think. Again we learned this from the pandemic human connection matter lots of just knowing people from a Slack message or from a document. It matters to understand the context and it matters to have this more human connection. So I believe we are going that path where users see and comment and they are more engaged with Arab seeds and we realize that it's not enough. We need to create further communication. Okay. Yeah. This is one of the most difficult and complex things in the company, right? The black box that you mentioned and it happens so much in so many levels. Sometimes it's even the UXers like in the product team would feel that whatever developers though is a black box for them because they are not included in the team and it's even though you would like to share and you think this is collaboration. We need to collaborate. Creating those moments where you give people the opportunity is like sometimes they would get so overwhelmed that sometimes like you want to include me everywhere. I don't have time for this. I need to focus on my work. So this is right. It's like we want this but at the same time we don't have time for this and we don't have like mental capacity to do so many things at the same time. So yeah I imagine this must be not too easy. One question that comes to mind you mentioned you are a child. Do you have agile coaches? You didn't mention do you have agile coaches? Do you have any help from that part of the company? Yeah, we do have agile coaches. They are available for a pool model. So whenever we need help, especially some cross-stream retrospective or something more delicate, or we are seeing that somehow our daily kind of start not working or our practices on our time onboard are not ideal. We have this communication with them. They also survey us once a year to understand what's the state of a agile across the company. Before we had agile coaches more embedded into the team, yet with the merger with the BAC-25 group, there was a decision, this would not scale. Right, so we double the number of teams. We would need to double the number of agile coaches. And we also realized that some teams were more mature than others, so they were not really needing a full time agile coach. Yet, I really appreciate when I can bounce my ears with Jonathan, we were also in pre-rondtiana. Okay. So Jonathan is there. It's part of our organization and it can always help on difficult retrospectives cross-team or bouncing ideas on, okay, we implemented the data metrics to understand what are the pain points of the team. We do sometimes health checks to see, aside from the retrospect, is what are some things that are not working in the team. So every now and then, we work together to work on specific things, but they are not available for time. So because now I'm also thinking how many people we have right now in the team, because for example, when we were working in three now, we had like a typical scrum team. So there wouldn't be a leader of the team, but then you would have a scrum master who would sometimes it's very similar because you are not people manager, but you are also this kind of person that helps the process, helps the team and then your goal is not to be needed, which is like a very utopian goal sometimes. But now that you have, you know, you have probably a PM, like a PO, you have a CEO of the team and you have other roles. Like how many people you can have in the team that are kind of the leadership, right? Good one, good one. We have a ratio so far and people, I would say that three, they hold leadership role, or a formal leadership role, right? And his case is the product owner is the tech lead and it's me. I think one third of the team should be more or less, the ratio we use at least and it's quite effective. Yet there's something I always tell the team, which is we are here to create a team of leaders. In any presentation, in any conference, in any relationship with stakeholders, we shouldn't meet, we shouldn't need a tech lead, we shouldn't need the product owner. We try to empower people and how we do this, we do this by somehow putting them in a comfortable situation, presenting in public, making sure they collect requirements for users and they get first hand feedback. It's not just the product owner talking with users, people they do support, they do this kind of activities at then I really believe that smart people, they do a better job when they have more contacts and we strive to give this context to everyone and to expose people to different roles. And while they are not like a formal accountability or something, they are able to perform at this kind of job. So this is more or less the mindset that we try to create a team. - I love that. I really love this part of empowering the people because one of my biggest problems with the team leader all is that if not done in a agile empowering way, it's very easy to become bottleneck, to become the only one representative of the team. It's like you, this empowered the team so much on the company level, on the organizational level that when you want to talk to a team, you just mention a team leader. There's like the team doesn't even exist. And then whatever you do, you only do it with the team leader. So then it so much depends on the personality and skills of the team lead to waterfall down, everything that's happening in the organization. So the team knows about it and then empowering people to maybe, you don't have to go to every meeting with the stakeholders with everybody, maybe somebody can represent. As you say, maybe somebody can do a presentation and present and do the demo, not you or the PM or the PO. So yeah, this part for me, especially given that we were, when you have a scrum team and there's no leader, you just have to talk to many people and they are by nature empowered and they have to show what they did. It so much depends. I don't know if you had any experiences with this kind of different experience. I think I do on a different level, which is before I'm a distinction between management and leadership and individual contributors, they can be leaders. They can be leaders of the leadership, they can be architects that overseen a certain department, what I've yet, in many cases, people that are in the room, they are managers. If you have people that they are responsible and they are experts on something, why do you have managers in the room? Being a people manager is already a full time job. For me, this is difficult to come to consiles. So when I see these kind of situations, I always point out this. If we want to empower individual contributors to be leaders of something, they need to be in the room. They need to present to the CTO, they need to present to VP of engineering of something. I don't see this a lot of time. Whenever there's a project, most of the time, the people invited in the meeting calendar, they are the managers of the team. So I don't see yet this culture happening everywhere, but I think it's the job of the, if you notice it, you should also fix it. I have no value of for this meeting. I will invite this person, he is the expert, he will perfectly be able to present something or do something. And then what we should work on is also on defining expectation. If I'm not on the meeting, or if most of the team is not in the meeting, because we have a representative, maybe the product owner or a bit an engineer, we need to cascade this to the team. Right? Right, summary. We were in this meeting, we discussed about A, B, and C, and we decided to explain that. Again, it works by living by example, whenever you are in a meeting, management meeting, the people that are not managers, they don't attend. You do the summary, of course, if there's confidential information, you can put it, but most of the information is not confidential. You put it there, and people start again, going to this loop, okay, I go to the meeting, most of my colleagues are not here, but I will cascade this back to the team. And if in the next time, it's a different colleague going to that meeting, they already have the contact, what was spoken about. I still see a lot of places where these are going to happen. Again, I think we should be the ones that, if we see this, we should do something about it. - Okay, make sense. And what do you think about when you have, maybe you didn't have that problem, but I suppose you might. If you have a developer that considers that, well, you know, many times people are very introverted and they consider that, well, I devolved, I code, that's my job. And I don't know if it's because of the introvert part, or it's because they are shy, or they just, as you said at the beginning, it cost you so much to have all those social interactions and it's so mind-blowing. So what do you do to present this other view that, okay, it's not only about coding, you just, you have to go and put yourself out there and present and do all those other things that, when you think about the programmers role, they are not embedded so much at the first site. - Yes, so this happens a lot. I think the first step is to understand exactly what's the root of these. Is it because they find it bullshit? Is it because they are shy? Is it because there are some people that they talk a lot in meetings, so they feel like diminishing, but people somehow, so they don't feel, they have something to say because other people, they are already saying, "What's up stuff?" Depending on what it is, there are different ways of calibrating. In case of, we have a small team of two people, one of them is quite, speaks a lot, the other is a bit more shy. So what we did was to make sure we were transparent about this and we created a system where, depending on the meeting, one of them takes a more active role by default and leads the meeting and the other is like the companion and the other are around. So making sure everyone always can say some. - There are other cases where people, they are not interested in presenting or while, we should be mindful of inclusiveness in this case as well. Inclusiveness is not just about gender race and ideas. It's about different personnel. Some people, they are just different than they are your introvert and they are a space for them to, right? The important part is to, again, understand what are their motivations and see where are parts that they are more into work and maybe some people, they don't want to present in public, but they want to write blog posts or they want to write as a FC or some people they want to code and you can find a way for them to communicate with their programming or by giving them more like a support role and making sure they talk with users about code but they talk with users, right? So there are different ways, depending on people to do this. And finally, the last case which is people think that they can just progress in their careers by coding and then you need to have a really honest conversation with them. So it's important to have a standard or up to a level if people want to have impact across the company. In the industry, they need to go out of their comfort zone. They need to do something else and something else can be anything. This is an uncomfortable conversation with people because some people they feel entitled, "Oh, I just, I will just call my room from 8 a.m. to 8 p.m and I will earn 95% of the market money and no one needs to bother me with meetings or talking with users." And that's the-- part where I think the management needs to set the tone, right? And it's not a threat to anyone, but it's putting things like they are. If you really want to do this this way, if you don't want to broaden your skill set, it's likely that you will get stuck at some point in your career. I think there's no harm on having these kind of conversations because people, they need to understand what's going to happen and to avoid frustrations in the future. Why was I not considered for promotion? Right? So these are like different shades of gray. I think we've interviewed people or people that just want to call it. Interesting. Yeah, yeah. I recently spoke with Luis about this a lot, and we came to a conclusion that it is a bit too late that we introduced this soft skills. Hello, because you know, I think we are setting people for not for a great success. If when they are still junior, we don't mention, hey, I understand you are because we are in this kind of like, oh, you just code. I'm happy that you just code. Don't think about anything else. Just go to the essential meetings. But then they think when they will just code greatly, you know, like be really experienced and good at coding, that would be it. They will be successful. And then, you know, I think it's like going back to the education and even on the university or wherever you learn, like going to a bootcamp, whatever they should start explaining there that coding is not only about code, like, you know, the podcast of Luis, Nostolo Codigo. And do you think it would be better if we set this expectation way before and not when somebody's already considered themselves a senior? And then they are frustrated because like, why didn't what you just said? Why didn't you consider me? I am very good at what I do. Absolutely. I must say, no, that what I'm seeing from people coming out of the university right now, they are way better communicating than my generation was 10 years ago, but way better. And I also got this feedback from a director of engineering. He was my previous manager at Aradinta is hiring a lot of junior profiles from different universities in Spain and his partnership with the level of communication people come from the university. Last year, we had an early career, someone coming straight from the university, and the level of his communication is amazing. He's asking the right questions, giving a good summary of what happened. It's fantastic to see that the new generation, they are more keen on this. I'm not sure if it's because they have more people in YouTube, in Twitch, and they are used to this kind of communication, but for me, it is something that we should absolutely seek and we should set the tone. Again, as a manager, I think there's one big important part of the job, which is setting the tone. If people that join a team see that you not only praise good delivery or good code, but you praise what's called the glue word, people that communicate well and you say, look, this is exactly the kind of communication that makes our team go forward. At the end of the day, the culture is not what we have in the world. The culture is what you say to people and whatever you give a prize for, if people don't see people get promoted because they communicate well, instinctively, they will go towards what makes their promotion easier or whatever. So it's about setting the tone constantly making sure it becomes a cultural thing. Great, thanks so much for that. Yeah, this was, I will make a snapshot of what you just said and put it as a standalone video, I think, for all the managers. It's so important and yeah, and it's so hard to change it once, you know, you start getting used to just not participating in the meetings and you just do your coding. It's so hard to change later when when people get accustomed to this kind of work. So now that we are coming to the end, but I still want to talk about one big thing, the AC communication that you mentioned a little bit and also like the agile stuff, you know, now we need to talk a little bit about the agile stuff in my area. I read a little bit of the pragmatic engineer I can pronounce his name. Get away. So I was reading that most of the companies they go away from Scram or go away from Kanban and they just do something themselves. I would like to understand what you do. What is the framework that you follow in your team? So I think here the interesting part is not about the framework itself. It's about the culture, right? I think in a gel, it's the culture you promote in the team. Of course, there are many tools that it's great to have in your tool set like Scram, Kanban, retrospectives, they lift and that's whatever, right? Yes, I believe that's always something that we can present to the team as an option, right? And based on the problems we are seeing, we can decide exactly what fits better for themselves, right? So in in our case, we do some kind of Kanban adapted to our needs. We don't go to the Kanban book and see, "Oh, need to do this?" And isn't that no? It's not like that. Maybe it's not what I would do if I was the ultimate, maybe I would do it differently. But it's something that it works for a team. The team is delivering and the team is happy with the current things that we have. So it permits less about the framework and more about giving options, right? So we have this, we have that, there are people doing this in the industry, what could work for us and make sure that people they have access to these tools and they can decide what's better for the team, right? So in this case, we use Kanban as a framework if we want to do it, but because the team wanted to use it, nothing else, right? I don't have a strong preference on that. Regarding a synchronous communication, it is actually one of the interesting parts that I will relate to the previous one. We were seeing that our daily standards were taking like 30 minutes and it was like, kind of, a painable. And someone in the team said, "Look, what we do is a bit like reporting." Right? So we talk about what we did yesterday, what we are doing today, and it's kind of thanks. Why don't we focus on the blockers each day or on the things that we want to move to done? And if we want to say something else to the team because we get under the meeting at the moment, and there's a summary that's important, or we found something that's good that we share amongst us. Why don't we do an asynchronous update, whatever we feel is relevant? Anyone can read, anyone can come, it's fine. And it reduces the frustration with daily standards. Again, I was not the one proposing it. Someone in the team came up with his idea, and then we iterated this to a Slack channel where we just post this kind of update. So we don't clutter our usual channel with this. And it was pretty well. Right now, I have someone that is somewhat somehow shadowing me because they will get the management of the team while I'm away. They found this pretty interesting. Right? So they found themselves more informed about what's going on by reading what team members were working. And then we leveraged the standards to talking about these kind of discussions about blockers or something that some feedback that we got from the customer, it's really important from the task that we are doing. So I would say this. So for me, frameworks are less important. And I believe that agility is more like a state of mind like you say, you know, in your videos and in your podcast. So I try to live by my take on. Oh, great. It's so great you mentioned the name of my podcast. So just to understand and summarize what I understand. So you do daily in person like we assume or whatever, but you only talk about blockers and something interesting that happens. And then the typical updates of who are I work on that and this is almost finished on the night. So this goes to the separate channel and you posted when like by the end of the day in the beginning of the day. Usually in the beginning of the day, we have a bot that warns us to put the message there. It's also very useful because in some cases, again, there are some meetings that were just one of us attended. And it's useful to put that. Oh, by the way, this was what we discussed blah blah blah. And people can ask for their question like, oh, did you discuss exactly these or what's happening in that making it? Can you give me a bit more insights on that? So it's really working very well for me. Nice. I was asking about that. I wanted to really talk about the daily with you because what I recently see and I think this is like a post pandemic syndrome. It's like the yesterday, today, blocker style of daily is so dead. It's just I spoke with Yana, who was a scrum master in three hours, and we both thought like, yeah, we will just put fire to it. Like we will write it somewhere and like YTB, you know, that the abbreviation like put fire to it and like, please, let's forget that this ever existed and let's move on because it's the one thing that you just go and you are in the circle in front of the board in the office, which was, you know, two, three years ago, people did that. And then you just you see the people so you cannot really be doing something totally different even though it was it was a bit boring. But at least you saw the people, but right now that we are all remote and you even though you probably have a team that goes to the office, they will never be at the office at the same day. So you always have to do a remote daily. It just doesn't work and it's just so frustrating, like so sad to see, you know. Indeed. We found that, right? So we found no special value. There was some value from what people were telling us. But at the end of the day, if everyone is spending like three minutes talking about something, even if it's interesting, then you disconnect. Because it's like eight people doing the same. Yeah, yeah. And you see people suffer. You're like, why are you doing that? And they don't know. And then you ask them, why? And it's like, it's like on autopilot. We just did it forever. So we keep on doing it. And this is one of the subjects that I'm very passionate about. And I would like to just change totally the way we do daily stand-ups. And I'm with you, I think this should be that. Like I still see this great value of getting together. Because it's like the only part of the day that you like to start the day together or end the day, whatever. But you just see everyone and you can share something. But you don't have to do the format and like bore people to death. With your update. Indeed. So yeah, I'm glad and it's very interesting how you do it. It's good to have these other tips. How to do it just to avoid the boredom. And OK, now that we are almost at the end, that my two last questions I always ask. So first one would be, what would be like your tips for the first time and here's somebody that just moved from a developer? You mentioned at the beginning about the one-on-ones. But now I would like the overall general tip. Control your calendar. Make sure you have time to think. It's important to think about your teams, your team members' careers, this kind of thing. Read about what others are doing. It's not just to copy and paste what they are doing, but to inspire ourselves and to open our mind. And I recommend not only reading about software engineering. I recommend reading about management in general, because it gives a perspective on how people in other industries do thing. And then start reading a bit on the psychology part of things. So what motivates people? What drives people? It's not only money. It's not only coding. So how? You need to broaden your skills. And psychology is part of it, right? So control your calendar. Read about psychology. And talk once a little more. OK. So you need to be a earnest person to be a leader. And do you have any recommendations? So because I love to give a book that you read or a blog or some person that you think it's really worthwhile or reading what they write or watching the videos. I have a couple of them. I love the book "Turn the Ship around." A very hierarchical organization that was transformed with transformational leadership. I learned a lot. It was not about software. And I learned a lot about that. The same about Maverick. A Brazilian guy implementing a dialect called "A Jail in the 70th, Brazil." So he's like mind blowing, too. And then I like to follow a couple of people. charity majors. She was a former infrastructure engineer at Facebook. And she has a lot of good opinions on uncle team health and inclusiveness. Also, I follow the pragmatic engineer. I think the data presents more than his full opinion. I think opinions should be for the reader, and not taken from someone else. And we're larger. He was a repair-faceted instructor at Uber. And he has a lot of great insights about how to design organization. I think designing organization is one of the most typical parts of the manager's job. And doing it wrong has a huge consequence on the organization. So these are more or less the people that inspire me, both from the software industry and leaders that work in some things that are really disconnected from each other. OK, thanks so much. And please send me all the links. So I will include them in the description. And last but not least. So now that you actually have some sneak peek into the people, that's the new engineers that come from the university, which is the generation Z right now. How do you see what's the trend? What's the future of leadership given the new generation and also given the post-pandemic remodeling that I don't think we're going to get rid of that anytime soon? So what's the trend that's taking up? The trend is making sure these people are involved on the one. And they take projects on the one, and they are empowering the one to leave anything. They are very against top-down decision making. So you need to understand where they come from. They are excellent communicators, making sure you put use these communication skills they have, making sure that from the one you treat them as an adult and give them projects to leave. These would be my main tips to deal with Gen Z, if I make this one. OK. Yeah, that's interesting. So that's basically going back to what we said about the education that we want the wide variety of topics for people to take up as opposed to just like, OK, I do come here to just code. Thank you so much. I have some initiatives. I can't wait to share all of them with the wider world. So yeah, I hope that we will talk again, because I actually thought when we were speaking, that I have so many other topics that I would like to talk about, but there's no time. I want this to be under an hour so we don't overwhelm with information. But those are some great tips. Thank you so much. I hope you enjoyed it, too. Thank you so much, Maya, for inviting me. It was really great to talk about it, because you said you could be here like talking 30 hours in a row. Let's do it at any other time. And I close up my door to be here. Thank you. Bye-bye.