Menu
We've seen in the last few years rapid organizational changes from an initial COVID scale down to then scaling up as a digital economy boomed to now a market contraction driving painful layoffs.
How can we as engineering leaders be ever-flexible for this and other important changes such as the move toward remote and asynchronous work?
We'll talk about the elements of structure that are within most leaders' control, including strategies to:
And for more senior leaders with a broader scope of responsibility for the engineering organization, we'll also briefly cover how to:
About the speaker
Vitor Oliveira is a 3x technical founder, a hands-on CTO and leader with a strong focus on mobile, desktop, and web development and 16 years of experience. He’s an EdTech entrepreneur building Napice, an education & community platform for software engineers to grow as leaders. Vitor is passionate about mentoring junior developers as he loves to see people succeeding in the development world!
See below for:
You can view the slides from the talk here - and see below for the full recording
Transcribed by software, please forgive minor errors.
James Dong 0:05
I'll let you take it away. And you can also start sharing now if you'd like. Yeah.
Vitor Oliveira 0:20
Oh man Yeah, that should work. Yep. There we go. Can you see the chrome? Yep. Okay, great. So
Vitor Oliveira 0:48
today we're going to talk a little bit about information and how to build software engineering team flexible software engineering team these days. It's been, I wouldn't say it's hasn't been like very difficult to find software engineer. Because of the layoffs, it used to be much more difficult. What I've been seeing is that when we open up, job post, a lot of applications are coming, which is different than maybe five years ago, we'll be discussing like different moments of a company different, different aspects that would drive us to make decisions when we are building a team. As James said, my name is Vitor, and I am a co founder of Napice. I am also a technical professional. I've been working with software engineering for 17 years. And I started in 2004, building web applications. I worked with so many different technologies in my career, I spent 12 years as an IC, as a web developer, and web engineer, mobile engineer, also DevOps engineer. And then I switched to engineering management role, I became a manager, I became a startup CTO, I also add a team of 40 people, as a VP engineering in Canada. I'm originally from Brazil, but I live in Canada. I live in Vancouver nowadays. I wrote, could you please introduce yourself in the chat, I know that James already asked you to do that. So if you are new, if you have just joined the call, if you want introduce yourself in the chat, feel free to do it. So just a few guidelines. Yeah, so just stay on mute. On last, I will invite you to the call to talk to me. And there will be some moments for collaboration during the call. If you want to turn on your camera, if possible with denials, just for more engagement, and there will be some breakout rooms today. And I will try to make these live session as much interactive as possible. So I promised that this is not going to be a college class where I will be speaking 90% of the time, I will try to like, speak 50% of the time, and you guys will also be talking to me and engaging with some of the questions that are brought. So I want to start with the first question that James asked me when we discussed the live session, which was how should we balance the number of senior and junior software engineers on a team to ensure that we are able to deliver good software today, and also good software in the future? And I think it's really depends on the manufacturers. Right? When you are thinking about dividing a team. First, it depends in your depends on your current team, like the teams that you have in your company. It depends on the budget, it depends on the work that you need to do. It also depends on the product that you want to build. What if whether it is just one product or multiple products, and it depends on the face of the company as well, whether you're a startup like let's say, You are God the first MVP or you are ready achieving product market fit, we will discuss these aspects and see how and we will discuss and see how teams can evolve over time. So the first aspect is this one. The first I would say use case that I brought. And this is very standard, right? So we when we think about building a team, we think about having a more diverse team with once it may be one senior one intermediate developer and one junior developer, for example, or like 20% of one category of 40% of the other one and 40% of the odd one. So we build this paradigm. And then it's easy to build the mentorship flow that comes usually from the senior Developers, more experienced developers to the more junior to the less experienced developers. This is really good for collaboration. So you can foster collaboration that team, you can allow developers to grow like in their careers, and start already practising some of the soft skills, some of the leadership skills. So I would say this first use case, is very common in competence. And it is pretty good. So and the second one is when you have a team, and you make a decision to hire seniors, and intermediate developers, and youth, this regard the possibility of having juniors in your team. And this could happen for many reasons, maybe this software that you want to build maybe the architecture that you want to build, it's very difficult, the challenge is difficult. So you don't have a lot of space for junior developers. And then mentorship would probably flow from the senior to the intermediate in this case. And this is also a possibility. So again, depends on the characteristic there is no, there is not a very specific role, in my opinion. And then you have, you have teams, if you could have a team that is more composed by junior developers and incriminated developers. As an example, there is a company that I've been working as a fractional CTO since the beginning of this year. And the majority of the company is juniors and intermediate developers, they only had one senior developer. And that happened, because the first engineers of the company, they weren't senior developers, so they didn't have the capability to hire more experienced developers than themselves. And nowadays, they are redesigning the whole structure to be able to add more seniority. So it wasn't nobody's fault. It was just the the initial team that and they were able to deliver that result. And there is also the possibility to after only having a seniority. So I've seen that I've spoken to a few companies in the past that only hire a senior staff, Principal, software engineers, and they don't really hire junior developers. And that can be a strategical decision. It's probably coming from the CTOs mind for from the VPS mind. And it is obviously possible, and I think depends on manufacturers that we're going to be discussing now. So the first factor that I think it's very important is, what are you building? So what problem do you have today, you have a technological problem. So as an example, we have this very standard, monolithic application. You could, for example, have everything together in a container, like full stack front end back end together. Or you could even split the app and have a React js application, and maybe a Node js and another container. So for these kinds of applications, you don't need a very senior team, it's good to have a senior contribute the modular system, right, a very well designed system. And having seniority is important just to help to guide the less experienced developers to execute the work. So be able to write the design docs, to be able to structure and lead these things. But when you come to this kind of architecture, you start having more complexity, and you start needing to have more people. So while here, you might need two or four developers to build an MVP, or to do the new product. Here, you will need maybe the double, or maybe six or seven developers, right. And here you might need people that already have experience with microservices, people that have experience with no SQL with SQL, and with different types are things that you need to have to be able to execute this technological strategy. And then you could also have different types of architecture, you could have serverless, and that are other types of architecture that you could put in the system. And that would basically increase the complexity of your engineering team. So it wouldn't, it wouldn't become more difficult to hire and just to get you need more senior people in my opinion.
So there is the architectural phase by the stack that you are choosing. And there is also the business phase that you have. So what where is your business? So you could be in the customer discovery phase, and also in the MVP phase. And let's say that the monthly recurring revenue at this moment is zero because you were just building an entity and you have received funding from a fund in San Francisco for example, they signed the check of 300 have $1,000. And then you cannot have a lot of developers in your team. So maybe in this moment, you want to make sure that you are hiring the most experienced people that you can find, because you don't want to make. Yeah, you don't want to make the technology very complex, because you were probably just coming up with a proof of concept. And you don't want to only have gingers at this moment, because you want to be able to execute. So this is not the moment to learn, in my opinion, like when you are building the MVP, or even when you pass through the NDP, and now you're getting the initial customers or a new product, you want to make sure that you are doing the right things that you are making the right decisions. Right. So in this case, I would prefer to have less developers, but more experienced people just to avoid, I wouldn't, it's impossible to avoid tech debt, because we always have that. But to avoid like an avalanche of books to avoid problems that you don't want to have, you want to have, the problem that you want to focus on is the customers problem and this morning, right. So it's not really about the technological problem in the early days of a company, and and then you pass through this phase, and now you're able already to generate $50,000 a month. And now you just sign it, two checks with two funds in Seattle, and now you have 1.5 million in the account. And now you can build and bring more developers to the team. So maybe, now you're going to be bringing in marketing people. Now you're you might be also thinking about launching new products in the company. So now maybe instead of just having one squad of developers, you are going to have two different squads or three different spots, because you want to create new products. And eventually the architecture is then evolved. And maybe that's going to be the time to rethink about how your teams and how your paradigm is going to look like. And then what you have product market fit, and you have stay stable growth. And now you can make many decisions. Now you can have the opportunity to have more junior developers to have less experienced developers and you can create the mentorship cycle much better, because now you have the time to do that. Right? If you were in the entity phase, I'm not saying that you cannot do mentorship with the juniors. But it's important to understand that the focus is to solve the customers problem. It's not really to teach junior developers all the time, you are not building a textbook, when you are building a product. For example, multitudes is building a product. Now it's the moment to execute. So we need to hire the best people that we can find that is going to be able to execute as fast as possible so that we can prove the hypothesis that we have. So it depends on the stage of the company. And I would say that, what I've been seeing, what I've seen is that we always have the opportunity to re design engineering teams in different moments of the company. And when the company starts growing, we can create a plan to drive alignment, we can create a plan to set expectations. So when maybe we are we already have a product and we are scaling that team, when we raise it, they're more capital, then we are able to create a career ladder. This is an example and a template of competence skills matrix. And we can literally create good day skills that are based on the stack that we have in the company. And we can categorise how our developers are in the skills and we can create a career plan for them. And we can treat the levels like the junior developer, intermediate developer, senior developers, app developer, some companies call it Li, l one, l two, and up to L six, right. So it really depends on the size of the teams that you have. But to be able to stack these expectations, to be able to drag this alignment, you need to be solving a customer problem. You need to be able to be really in the market and to have funding to be able to create the structure to allow mentorship internally. And then I would like to ask you now how do you balance the number of senior engineers and software engineers on a team to ensure good engineering delivery both now and in the future? And you can raise your hands. I can give three minutes and they will put here in the timer. Maybe haze or raise your hands if you want to speak in the mic. It's fine. We can just start a discussion. I can also you can also drop in the chat. Like whether you agree with what I just said. and how different it looks like
James Dong 15:14
I saw some discussion in the chat earlier. But Walter also as you just raise your hand, so go ahead.
Speaker 3 15:20
I was just gonna say there's probably maybe not quite stunned silence, but it's funny like you, I was just writing some notes saying, what you're saying is even about the architecture is really obvious. But it's really obvious in a very implicit way. And I'm sort of thinking about maybe where I work and how, you know, I kind of done the long story even sort of before I was there, how the sort of funding probably influenced who they are able to hire. And the technology choices probably weren't, weren't appropriate, given those constraints. So so it was super interesting.
Vitor Oliveira 16:09
depends exactly. I think, also, like, it's funny when we talk about levels. So why is a senior developer for my company, and what is a senior developer for the market? Sometimes, we interview people that are senior developers in the resume, but we don't consider them senior. So they levels in my opinion, it's something very relevant, right? It really depends on the problem, like a senior developer for Google and for Amazon might be a principal developer for us. So it might not even be a good fit, because maybe your team is so small that they will want to over engineer all the solutions. And it's not simply going to work. So it's a very difficult discussion. And it's, it's hard when you don't have a lot of budget. So do this equilibrium of developers. And we need to work with what we can find with the best people that we can hire.
Sara said, even though I have reasonable sized team juries, resistance to bring in juniors, since we are a mature startup, and there's a lot of pressure to build out the final features with so before we bring juniors in, so I only have one Junior. Yeah. I understand that. And I don't have any problems with generous if they have the growth mindset. And if they have the capability to grow with the team. It's amazing. But sometimes it's difficult they can they can just observe right the energy. Great. So let's go to the next question. The next question is about outsourcing teams. Oh, my gosh, I received so much phone ink at the end these days, like, Hey, are you looking for to reduce the price of your tech teams? So how can we leverage outsourced teams or contractors to improve flexibility in our teams? Another discussion that it is difficult some engineered engineering leaders are, I would say, resistant without swords, outsourcing companies. But in my opinion, it really depends on the problem that you have. Sometimes it's okay to delegate these companies. So let's take a look at some of the advantages of having outsourcing teams. The first advantage, in my opinion is that it might be the cost savings. So maybe you were in the warehouse. And maybe you can contract a company that is based in a country where the Koreans is much less valuable than the dollar. So you might be able to save some money and eliminate some of the space equipment, recruitment costs, benefits, and min odd records costs that we would have. And with with the right outsourcing company, you can definitely scale, scale up your team and also scale down your team very fast. So it's, yeah, you need to build a relationship with a few good outsourcing companies to be able to really take advantage on that. And I would say I receive a lot of messages from the wrong ones most of the times on LinkedIn. I think it's also possible to increase flexibility and scalability of the teams as I was saying. So during layoffs, this time difficult times that we're facing, if you need to reduce your team, it's much easier to reduce developers from an outsourcing company. And for example, I worked in a company two, three years ago and I was VP engineering there and like 50% of the company was outsourced. And we had some problems of course, especially to integrate those things in the culture. It wasn't easy but for the company was good, because the core competencies of the company was backend. So all the internal team was back end. And we would invest heavily in this team in knowledge transfer in specific training. And the outsourcing companies would handle the front end, like the React js applications, they would handle the mobile development as well. So caught me Swift, and the demand of the outsourcing companies would vary from the banks, because we wouldn't be a FinTech consulting firm that would build credit cards for banks. And the bank sometimes would want to build features, additional features, and they will just invoice this this company. And then we would scale up the team for three months or maybe six months, and we wouldn't be able to bring the developers and after that period, we would be able to reduce the team. So in that occasion was perfect, and it would work well. And we would also be able to work with that those developers we will be we were able to select really well, those developers. So I would say like, maybe for each core developers that we would hire, we would choose only two like the best ones and the other two, we will just replace, and we will just entering this loop, where we would be just working with them watching them for a few weeks. And if they would be able to generate good results, we would stay with them. So I don't think it's really bad decision. It depends. And the disadvantages are obviously, communication challenge. Depending as we as I was saying, you may want to hire people, that is the text, because the currency is different, different, it is much better to work with them, you're gonna save money, but there are language barriers, I hope my language barrier is not that bad. At the moment, it improved a lot over the past two years. So misunderstandings, like delays. So quality control and coordination, I would say it's a very big problem. So with this team, the mobile team and also the front end team, we would need to make all the architectural decisions, we would need to do a lot of QA and a lot of coordination, a lot of management with these companies. So there is this bad aspect. And obviously the dependence on these external providers is really bad. So do the knowledge transfer with them, you end up losing a lot of knowledge when you decide to work with them. There is the the other aspects, which is the security and the confidentiality risks that you end up having. So you if for example, in my case, I was a FinTech consulting firms. So we wouldn't have a lot of sensitive information about things. And it was very important for us to establish security measures, to have the agreements in place to have the data protection protocols just to mitigate those potentials data breaks that we could have, I would say that transition and integration costs, they were also a pain for us. And also the lack of alignment with the company culture and values. Oh my god, this was terrible. Like, it's really difficult to bring someone that is managed by another engineering manager or buy another CTO to join a company that has a different view that maybe is not going to buy the vision of the company. They're just there as a resource, right? In most of the times. There are obviously exceptions, we cannot generalise everyone. But you, at least based on my experience, that's what I got most of the times. And I was also part of an outsourcing company a long time ago. So I'm from Brazil, I worked for three years for us based companies as a senior software engineer. And I was treated as a resource that was treated as, hey, this guy is thrown his vendor, and he's not really part of the company. So I wouldn't be in audit meetings. And they would feel that I wasn't part of those of those clients. And, and I started to behave and behaving like that. I think in North America, it happens a lot. In this company that I worked, they would also have this mindset and I was able to help them to improve. So now it's my time to ask how do you leverage outsourcing teams and contractors to improve flexibility in your teams. And they will give you three minutes if you want to see feel free to go to the mic. If you want to drop a message just saying like I outsource 50% of my team and it's horrible or it's really good
Unknown Speaker 24:51
we outsource probably about a third of our resources
Speaker 4 24:55
timezone is our biggest challenge because they're in the filler beans in Sri Lanka. So that has definitely contributed to the challenge timezone wise because our a lot of our staff also based in the states are trying to connect the states and with us. But it gives us a lot more flexibility to be able to kind of, you know, expand as we need, and obviously condensed when we need as well. And we also have at the moment, to New Zealand squats, which are actually with the contractor so that the outsource partners, they are actually embedded in our squats. So they work with our staff, they're treated like staff, they have full access to our systems. And they attend all of the sort of rituals and meetings other than sort of the company, all hands where we talk about financials, that's the only thing they are a part of, we're the third parties, they're in first six months just to, you know, they're isolated squads just get these help get these features out the door, they'll go and then not that nowhere near as embedded in our organisation. So like we allow learning and development for our outsource partners where they're embedded in our squats. And we pay for that because we really treat them like employees.
Vitor Oliveira 26:11
Amazing, very good experience. I know a lot of people that have void and I'm really in the chat like I avoid outsourcing from TRACE had a bad experience, we get AIDS ago. And for many reasons, I understand you even for this company that I was the head of engineering. There was a moment that we were working with three outsourcing companies, and we had bad experience with two of them. And we decided to stay just with one.
Speaker 5 26:38
And they it was challenging, because of many reasons. So yeah, I see that
Vitor Oliveira 26:44
there are people who are like positive about outsourcing. And there are people that are not really friendly with open source wave outsourcing. And I would say that's natural. We will be discussing a little bit more about that in the exercise that we're going to be proposing. So thanks for sharing your experience Sarah.
Unknown Speaker 27:10
And then, and then now,
Vitor Oliveira 27:14
the final question for me. How can you work for us actually, how can we allocate the members across work that better accommodates big scale ups or downs, hopefully avoiding pain, painful layouts?
Unknown Speaker 27:28
In your opinion?
Vitor Oliveira 27:31
What is your strategy for that? Like? Have you recently had to layoff part of your team? And what did you do to accommodate that change?
James Dong 27:48
I saw some conversation about this in the chats with anyone wants to talk about some recent developments. One thing that I'm actually really curious to ask if anyone wants to chime in or if he's where you have insight on this is how this how often could you do this? Because it seems especially now, many teams are going through multiple changes a year, and then that there's a whole process of you know, re going through the whole What is it storming, norming forming cycle with a new team, and that saps productivity? So that's one thing that I'm curious about, is how often are people doing this? And how is that felt?
Speaker 6 28:32
Hey, everyone, yeah, look, I think James, that's the right question. Right, I see it happening very often too often right now. So by the time you get to performing, if you ever get there, the team is already changing. I mean, nowadays it's very common also to hear that you ask someone for how long they've been in the team or the company and they go like off a year. Like that's a long time right. So I I spent a lot of 10 years in my previous company and so I guess that that's one of the challenges to really manage your former team that will perform in the long run which which gets you in this position where you need to be flexible and look scale up scale downs, I think that the most in my experience, the best way is to have a good outsourcing model for that. So you keep your core and you keep the knowledge in house and you know so you have your your perms you know very senior and you know like for the long run and you're going to scale up and down with with good with other companies. But if you cannot afford that I get this is having cross Skilling and having full stack engineering, this is your best shot. Because the thing that many times happens yeah, you have one point of failure. And that's why you don't want to be
Vitor Oliveira 29:56
amazing, amazing, totally every one of my points is exactly like cross functional training, like cross skilling. And if I'm looking to hire new people now, I would prefer generalists. So I wouldn't go for technology, I wouldn't go for frameworks, I would just go for like, I wouldn't say only fundamentals. But I would try to understand whether people know well, technology, whether they can use technology instead of using technology, in my opinion. And there are many ways of analysing that. And if you have a strong team, like that, and if you if any, if you don't have that you can provide cross skilling cross functional training. So flexibility in contracts and work arrangements, I think it's important, just like to, just to prevent, like to think about the future. So whenever now, we know that these kinds of occasions can happen because of a global recession, we should be more flexible with contracts and communicate with the teams that this kind of things can happen. And also, I would think about building a network of freelancers or a network of contractors, if, in the case that we need to scale down or scale up. And so imagine that now, we need to manage a team that we have just, we you were hired at the moment, you are the CTO or the engineering leader, and you arrived in steam, and many of the technical decisions were raised, then how can we manage the stem? Anywhere? Okay, now, imagine that you have some problems with outsource companies. And you need to come up with some solutions, what will be the first steps? Have we ever experienced these kinds of things? Have you ever had to restructure an engineering team? Why did you do that
Unknown Speaker 31:52
it was successful.
Speaker 6 32:08
I can go again, while people are typing. Well, I recently joined a team that was already very quite established. And I guess the process you follow is quite quite straightforward one or trivial one, you first identify if you have any, any fires that you need to, to attend to, if anything is very critical. If not, probably the next thing is you start looking for things that are not working well. And you start identifying right, but you need to take your time. So I think that's, that's the most important thing, hopefully, jumping into a team that is already set, they will give you some time to sit up and identify what are the areas you want to work on. And then you start trying to draft a strategy towards towards that. But I would say that, in my experience, the most important thing is what I tried to do is don't try to change everything in the first few weeks. Because you're probably gonna shake it too much. And rock the you don't want to rock the boat too much. So take time. And yeah, identify what's what's the priority?
Unknown Speaker 33:23
Yeah, I totally agree.
Vitor Oliveira 33:23
I really like what Trey said, build trust, listen and learn about the people and the culture, identify strengths, weaknesses, then make a plan. Yeah, so I wouldn't make all the changes in the first week. So otherwise, it would be okay to the hurt motivation. It could be premature, right? So you need to observe and analyse for some time before making the decision, what changes needs to
Unknown Speaker 33:49
be made, of course.
Vitor Oliveira 34:02
So Sarah said that it was her first secure role. And she had to understand the challenge to be able to support them.
Unknown Speaker 34:10
And it is also important
Vitor Oliveira 34:15
to understand what degree of autonomy, you might have coming into any role,
Speaker 5 34:20
or whatever. So observe the few first marks. Totally. Great.
Vitor Oliveira 34:29
So in this next step of the session, I would like you to work on a small framework that I built. Can you guys see this mural file
Unknown Speaker 34:39
that I held? Can you see it James? Yes, great.
Vitor Oliveira 34:45
So I'm going to share with you a mirror link. And the mirror file basically has six building blocks. And in the first building block, I've put my name and I mean basically introduce myself so my name is Victor. I'm CEO CTO of naughty stacking seven In years, I've experienced New Zealand Canadian who loves travelling exploring this amazing planet. Then I talk about my engineering team structure. So I have five full stack developers three front end to back end, one QA, doing a lot of tests, one DevOps to flutter developers. Then I talk about the structure of this team. 20% of these people are outsourced. 20% of them are freelancers. And the rest of the team are internal. I talk about the challenge. So we have a low software development cycle. We are lacking discipline, we need a structure a better structure, our hiring process is broken. I also talk about the stack, like the skills that we need to have in the team to be able to build new products. So we have front end with React js, TypeScript databases, or a Mongo Aurora. Back end in Ruby, Python, Go Node js, and we host applications in AWS and Hiroko. Some of the engineering processes that we run are the QA processes, the design docs, agile and daily scrum, we obviously do retrospective, and all those other ceremonies and we do a 300 degree feedback. Sometimes the mentorship trust as my team is based basically formed by subscriptions that we pay. So we use blade HQ for engineering managers, we buy courses on Udemy, navan and also in cloud guru. So I will give you this link. And I will give you 10 minutes to complete this framework. And then after that we will break out rooms so that you can explain to your team members or to your colleagues, what are some of the challenges that you have, and what is the structure that you currently have in your teams. And you're basically going to be receiving some feedback from them. And they will also be waiting for you to provide feedback. So I gave you the mural file, we have more building blocks here, as you can see, and so I created, I think 20 or 25. And you can go there, and you can just play a little bit. So this is going to be a collaborative session, you will basically describe your current company, your current challenge, you will present that to your friends, I would say everybody here is kind of professional friends. And we will just learn with each other.
Unknown Speaker 37:26
And they will give you a tenant.
James Dong 37:30
Hey, heater, just for time sake, I might suggest if it's possible, could we do like seven minutes for this? And then yes, I can. Okay, great. Thank
Unknown Speaker 37:40
you. Yeah, I can keep track of that time.
Vitor Oliveira 37:45
Yeah, I think it's gonna be relatively faster. I don't need 15 minutes as I put here. Seven minutes might be good. And then more seven, two. You can put the time. I think it's gonna work. Maybe we can break out rooms with people. And then it will be shorter. Yeah, totally. Yeah. With five for you. Okay.
James Dong 38:10
I'll just check in again when we have a minute left. Yeah. Is everyone accessing the mirror? Okay. Yeah, okay, great. Please feel free to drop me a note if you can't access something and I'll help you.
Vitor Oliveira 38:25
So question from from Tracy skills needed not skills existing. I think you could put both. We can talk about both.
Unknown Speaker 38:33
It wouldn't be great.
James Dong 41:06
doing time check folks we have about three minutes left?
Alright folks about another minute please go ahead and start wrapping up
Unknown Speaker 43:11
I love that
James Dong 43:12
someone had written for challenges and pain point New Zealand
Unknown Speaker 43:52
Okay great. Let's start wrapping up please.
Unknown Speaker 44:08
Maybe so you wanted to direct people to the next part? Yeah, yeah, sure. Yeah, so the
Vitor Oliveira 44:18
next part would be basically we're going to break out drones and you have like one to three minutes to talk about your framework to talk about your current situation. And you will receive feedback. You can reconnect with your partner after the call just to brainstorm more and to get more insights. And that's basically the idea. So I will let James Bree culturals.
James Dong 44:42
So I'm gonna start assigning the breakout rooms and then we'll again have about seven minutes for discussion here.
Speaker 5 44:51
Okay, great. And off we go.
Unknown Speaker 45:12
Should I Stay or Should I Go?
James Dong 45:14
You should go. You can go to one I put you in one with
Unknown Speaker 45:17
Julian and Sarah. Yeah. I'll say it here. YEAH.
Unknown Speaker 50:13
Hey folks, welcome back. We
James Dong 50:14
just wait another few seconds for everyone else to join us as well.
Speaker 3 50:39
To save somebody seconds terrible, right? Because then there's only two people. It's like
Unknown Speaker 50:47
Hey folks, welcome back. Well,
James Dong 50:56
these are any last thoughts.
Vitor Oliveira 50:59
Yeah. So good luck to thank you for joining me today, I would be really happy to connect with you only then I will be reviewing your building blocks, I would love to just brainstorm ideas on how to improve the team structure, exchanging knowledge, share ideas, I'm always open for that. Thank you so much. Hope you enjoy it. And I really wish we had a little bit more time to talk a little bit more, and they will make sure to reserve more time for this last exercise. Thank you so much.
James Dong 51:28
I'm going to share my screen real quick if you don't mind staying around for two quick things. I just want to again thank you to Vitor, these were also has a Slack community for an a piece that he'll I think Vitor, if you drop it in the slack in the chats, people can talk about that, I just want to call attention real quick. Our next tech leader chat in June will be about succeeding as a new manager. And then we have one after that on building a fulfilling career path for your engineers. That's in June and July, please go to our meetup group to sign up for that. And then of course, we would love to hear your feedback, I'm gonna go ahead and drop these links into the slack. And if you want to continue discussion, we also have a tech leader chats, Slack group as well. So let me just drop these two both in would really appreciate feedback so that we can continue to plan events that really worked for folks. Alright, so I'll drop it there and then I will feel free. I will hang around for a little bit if folks have any other last questions, or if anyone wants to complete the survey. But otherwise, thank you so much to everyone for coming today. And we look forward to seeing you at the next one. I will stop the recording now.
Unknown Speaker 52:39
Thanks. I'll see ya.
Unknown Speaker 52:41
Thanks bye. Think you're
Transcribed by https://otter.ai
