Hi everyone, My name is Patrick Akio and if you're interested in effective software development teams, this episode is for you. We talk about restructures in big organizations and how to form teams that actually make sense from a product and tech perspective. Joining me today is Andre Borgenovo, Engineering Manager over at Good Habits, friend of the show and returning guest from over 3 1/2 years ago. So it's been a while. Enjoy the episode.
Like recently I had a refinement, I think it was about a week ago, a week and a half ago, where very early on, beginning of last year, a decision was made that the new team formed. They got kind of this product and a lot of people left and a lot of people newly onboarded. So they had opinions of what they kind of were responsible for nowadays and decisions were made, some logic of the front
end was removed to the back end. And now we want more back end driven with regards to data and also validity of data and kind of API design. And those changes now have impact still. It's kind of this ripple effect where new features that we pick up now someone said that they're actually more back end heavy and a lot of people in the team that kind of owned the back end and responsible for that also left. So now we have this kind of, I wouldn't say void because we
still deliver and fulfill. But then the question was, OK, since we now have a lot of capacity nowadays in the front end, do we make the change and do we do more logic on the front end or do we stick with that? Decision and. Now I'm doing product management. Like in the end it's not my decision. I think it's very interesting and I think we should uphold kind of the decision that we made. And also people from the front end are kind of dabbing their
feet in back end development. So we're moving to a full stack, which I fully support, and if people have that ambition then obviously we have the room to do so. So that's amazing. But I wonder. It's so, it's so funny how these resonate so much with different experiences I had as well, right. So you were, you were talking about a very common pattern, I think in companies, right? When you have different competencies within the company, like a more front end, there's
then back end. The software starts to evolve towards a certain direction where indeed, if there's no a deliberate decision about it, the logic or the business rules start to show up in the front end as well. Unless the team really upholds their own principles and finds a way to get the the best use of the people that are in the team, right? Because of course everybody wants to feel, you know, motivate and then with their purpose to deliver good things for the job that they are doing.
So you still want to do the, you know, to use the time people have to bring value to the business. And what's the what's the best way to do that considering the constraints, Right. So having more front end, there's the back end. There's and upholding to certain principles like having done front end, keeping all the business logic in the back end. That's that's a pattern I've
seen before, 100%, yeah. But I, I wonder if that's then OK, right, Because the, the team structure in your team set up the capabilities sometimes. And I fully agree with you, they can define what software you're, you have basically on a technical level where what logic gets implemented, but then teams change. Like I would love if a team can be the same team for a really long time. I think that's super good with regards to delivery, predictability, resilience, ownership and autonomy.
But that's just not reality. Like people switch in and out, and then if too many people switch in and out, does your architecture need to change for that new team setup or are they going to kind of uphold the conventions of a previous team and continue? Yeah, I don't know the trade-offs there. Yeah, I would love to see both scenarios play out, but that's just not possible. Yeah, that's the Conway's Law being applied in, in practice,
right. So my, my own perspective in that is we need to keep a general picture of the architect architecture that we intend, right? We, we know what business and capabilities we want to offer to our user and, and customers. And the team changes are indeed more fluid, right, Depending on competencies that you have people that are coming in and live in the company. So this is a much more fluid space, right?
So when you're thinking of software architecture in my point of view, and that's what I learned as well in my my different experiences, is you should focus on the architecture and the components you have in the application and really assign components to teams rather than defining components
based on the teams, right? So patterns that I have seen before, which I consider a little bit of anti patterns is when you start addressing aspects of your application like name spaces and things like that, based on your team's name, you're likely just, you know, opening a door for future failure anyway, because these schemes are things that the company and being an an agile company, actually it's it's healthy that they will continue to change the seems depending on
the growth of the company and the needs that the company have. But you when you attach that directly into the software level in terms of namespaces, in the way you structure the software itself, you get into this big risk of this not being a future proof definition, right? When it comes to team stability, I agree with you. You should have teams that are at least for one year, 2 years stable and being capable to respond to these changes of the company of the, of the market
sometimes is necessary, right? So you need to have this flexibility. Once you design your teams based on the architecture that you aim at, I think you can uphold to that, right? So you're thinking of like these are the features that Ioffer with my software. This is the road map I have for the next year. And of course that's not always 100% right. Rd. mapping is a bit of trying to predict the future and and up to a certain point you can be confident about the road map.
So if you can define your teams based on a bit of a long term picture of 123 years, maybe that will give you enough stability to keep that team set up stable regardless of the small changes of someone leaving the company or someone joining the company. And of course, you need to keep open to the signals again to adapt as you go. But I think it's that that's only base if you look a little bit in the long term, which is
not common. I think it's common that companies actually react to the road map changes, right? When they need something that they need to deliver and that becomes a project, boom, change everything, let's have a team to execute it and let's go. So I think it's up for the leadership team to uphold a little bit and say, hey, let's think a little bit, meet long term and think of, OK, we have this road map initiative coming in. How do we consider this road map initiative, right?
Do we want to assign that fully to one of the teams or do we consider this road map initiative that needs to be broken down into different parts of the application that will do different different aspects of this road map initiative, right? So there's a little bit of thought that needs to go in my point of view, in the management level, of course, with insights of the tech team for sure to see how to break down this road map initiative to make sure that the architecture remains healthy in
the long term, right? Being now responsible for product and also product road map and and product development, I think it's very difficult because maybe it's the maturity of the product that I'm responsible for. But looking ahead one year is kind of doable. And then already there, if I have a one year plan, let's say and a plan is very much like it's just an ordered list. Yeah, I already communicate that.
If we look at it now and probably in the next quarter, things are going to shuffle, things are going to change. We focus on the most important part, KPI deliverables that are like on board level, agreed. Those are always on top, most important and still ordered and then everything else that is
nice to have. The order can shuffle basically, which means if I have that already in one year and then looking at two or three years, it's very difficult with regards to like bigger chunks of work that we want to work on. Maybe it's like the autonomy that I have currently in in the assignments also at a bank. So more rigid, more people have
their hands and things. Yeah. But looking at a road map and then kind of plotting from a team perspective and looking at what a team needs to fulfill that I think is very challenging. 100%, I think things will change depend of the size of the company, right. So if we're thinking about a 30 people team mostly you can keep the overview of like how the software is developer across is
developed across the board. So you can look at the different teams, how they interact with each other and you can keep an overview of like the overall road map of that's being executed. When it you go, you know, to 301 thousand 2000 development teams, then it's a whole different game, right? So, so keeping an overview and thinking of the teams globally becomes much more challenging.
If you manage to find a road map that is clear for one year, that is one of the signals you should consider for your team formation. So I think it's relevant that you go through some exercises like domain mapping, right? So event storming is a very interesting tool for that to look into how, how did the user journey within your application
happens, right? So there's some certain handover moments or or milestones that happen in the user journey which show these interactions where these domains change, right? So a user logs in into the application and lands in the home page of your application. So this moment where the user is authenticated and lands in the home page is a milestone that you can consider for splitting these different domains on your
application, right? So one of the signals definitely is road map, but the others should not, it shouldn't not be the the unique point of focus, right? But rather, which are these places where the application can be well isolated in components that can be again, highly cohesive and loosely coupled, right. So when you're looking at teams and defining how the teams should be structured in a in a product and engineering environment, you should look at similar principles than software
architecture, right? So you want to have teams that can keep the complexity of the domain or the software component they are handling highly cohesive and within their own boundaries, let's say. So you can keep the overall system complexity much lower, right? So you keep the complexity local to the team and what they are
doing. And then the communication with other teams is either very clear with clear interactions and hopefully through AP is and AP is that are isolated to the needs that other teams have as well. So the principles there in software architecture and team formation are very similar to each other, right?
That's why if you get teams that are developing a software and they keep focusing like only on their internal needs in the sense of like, hey, I want to create this service and it's going to have a database and it's going to have these layers in, in the, in the software architecture. You, you, you incur the risk of them creating something that works beautifully from them for them.
So you, you keep it very simple, easy to use with a clear structure, but it doesn't help in lowering the overall system complexity, right? And, and, and what I mean by that is if you want to lower the overall system complexity, you need to limit the amount of information that you were exposed to other teams or other systems, right?
So you say if you want to place an order, for example, and then you have this order service, you want to place an order with just the minimal amount of information that you need to provide from the order service. And then that order service takes care of the complexity related to creating the order, maybe payments, maybe other things which do not need to be known by other teams or other services.
So the same principles apply there where you want to isolate the amount of information other system or services need to know, so you keep the complexity hidden out of them, meaning that you can evolve this complexity by yourself, right? Talking to a public manager and and and talking to the evolving requirements that that service can have. So the principle is the same, right?
Bringing the complexity and keeping it isolated, surrounded by a boundary and and keeping the overall system complexity lower in that way, right? So the overall system complexity lowers. The local needs to be a bit more complex in in naturally, right? I've been in teams where we had that kind of component focus or domain focus and I've also been in teams where that domain focus is what we aimed for. But in the end, we for speed of delivery, we ended up with a
technical split. So back end team, front end team. And also been in teams where you have a Gen. AI team that does more data science, different cadence. And I've also, and that was specifically in, in the current assignment was where teams were kind of mapped to a stakeholder landscape. And it wasn't necessarily looked at from a domain perspective because the team had kind of overlapping responsibilities.
If you have a team that is responsible for new data ingestion and a little bit of visualisation, and then team that is responsible for advanced visualisations, both teams have their own stakeholder landscape. But if you have a new data stream with advanced visualisations, you have to have both teams basically. So I, I don't know where kind of the nuances are. And I think in, in very much context, it depends. In the end, I became responsible
for both teams. And I said this from my surface level like it, it just didn't make sense. So then we merged the teams with regards to responsibilities. And then we just said this team does 2 stakeholder landscapes basically. And then it's up to product to manage expectations, manage milestones, delivery. And I learned a lot from there to a point where I basically said full focus in first half for this part of the organization and then second-half kind of that part.
And this part wasn't happy with that because yeah, that means kind of a one or two quarters, no delivery basically. Yeah. But from a team perspective and ownership that really helped because first of all, the team was new, as much knowledge sharing as possible with regards to the whole domain, like end to end user journeys instead of you're part of like 40% and then this team is like part of 60%.
So I really like that. But then when it comes to kind of previous experience that I've had as well when it came to speed of delivery and people being autonomous with regards to also capabilities and KPIs that were kind of, yeah, timeline wise hard to manage. That's why we then split up on the technical level. We can make decisions faster in isolation rather than having the whole team, let's say the wider team, in the same room to discuss specific technical
topics. So I still don't know what the best way forward is. And in the end, we would say, especially with that technical split back then, we recognized it might not be ideal and we can go into more domain layers later on. But we never did that because that speed of delivery was kind of, yeah, addictive as well. Yeah, I think you, you were talking about, it's interesting that your questions and experience go through the topics that I that I have in mind as well, which are.
So you talked, we started talking about Rd. mapping, right. Then we did go through how the domain or the functions that the that the system already have can, can be isolated. So complexity is local. Then the third topic is definitely stakeholders, right? It doesn't matter that you define the teams in whatever way you think it makes sense for the software architecture if the stakeholders are not on board with that, right? In a way, you also want to think of the company as a whole
system, right? So it's not only product and engineering teams that are fulfilling their, their, their products road map, let's say, but also you have stakeholders that will influence, right? Either stakeholders, you can call them domain experts or, or you know, business partners that will be on the business side requesting and asking you support for doing different things, right?
So mapping when, when you were going through this exercise of thinking how you want to set up teams or what is the most optimal way to do, definitely you should try in whatever attempts that you try to design The Sims, you should try to map them towards the stakeholders. And that's super interesting, right? So you can get situations where for a stakeholder is not clear to which team they should talk
to, to get something done. So right there you're, you're thinking from the team perspective, but think a little bit for from the stakeholder perspective. Sometimes they are like, Hey, I need this done to whom I talk to, right? And then you have, they have five teams to choose from. And that becomes also very cumbersome from from the stakeholder themselves. So you need to have this mapping and also think exactly what you
were pointing out. So if you have 2-3 different stakeholders that are all going and requesting things to the same team, it will definitely put some load in the project manager to align all of them in terms of like which priorities should come first. What I've seen playing out quite interestingly is a few things right on the on the business side. So if you have an internal stakeholder, which is big, for example, whole department, you
could put it like that. What was very interesting in my experience is defining a business partner that is responsible for the voice of that department towards product and engineering, right? So what happens then? It facilitates a lot of the conversation of a product manager or product owner talking to this department, collecting priorities and understanding what are the real needs and what should be in the road map for execution.
That means that the whole department then when they have needs and requests for the product engineering team, instead of going to the product manager, they would go to this business partner, have an internal conversation where they filter a little bit and think within their own terms and domain what should be their own priorities, right. So that helps a little bit on organizing the work. So things come in a little bit of more sensible manner towards
the product manager. I think when when you were talking about merging 2 teams that have two different stakeholders or keeping them apart, there are many things you have to take into consideration. And I agree with you, when you keep them together, then you have this question of, OK, how do I handle the road map, right? Because having one team that is tackling 2 road map initiatives at the same time, you end up having two teams internally anyway, right?
Now The thing is, it really the best decision that there can only be taken in context, right? So connecting, collecting the signals and especially with the binding of the team, that's the best way. So if you if, if during your experience, the idea of merging the two teams was the idea that made sense for everybody that was involved likely and the best thing to do at that moment is to merge the two teams and keep
evolving from there, right? So this agility of being capable of iterating is super important because then the team can fulfill. OK, we merged, we tried and and one of the outcomes could be, hey, it was amazing to have the whole team working together in the same business initiative.
We really could help each other. We felt like everybody was In Sync. In the daily meetings, if they have, for example, they are talking about the same topic and can help each other and give quick feedback and review between the things that they are doing and, and that could be the outcome, right? They, they have this feeling of like, OK, it really, it's really working for us. And then the stakeholders would come and say, hey, yeah, but you
can only execute once. And then, and then you need to have that conversation. You say, hey, for the amount of things we have to do, we are with the right size of a team to tackle these things. And if we want to tackle more things, we might need to grow the team or, or you come back to the team and maybe the outcome could be, well, we tried merging in the same team. But it remains that we are just working on different things anyway. So although we tried, I'm not seeing the benefit.
I keep saying things in the daily stand up that no one cares about or only the other person here cares about but the rest of the team doesn't. It's not working out for me. So it probably you need to think of, OK, what didn't work before? That mean that meant we had two different teams. What's not working out that we have a single team. How are you? You can go into a third mode.
And in many ways that might mean, you know, getting 2 product managers maybe to handle those two teams or getting more developers on board or just, and that can be a way having this kind of sub teams where you deliberately say we have one team because XY and Z and that could be a shared product manager or shared engineering manager. But we know that these two people were allocated to this focus. And these two people are
allocated to that focus. And you find it, you find mechanisms to keep this team In Sync in the way you think, right? So same thing as as a software architecture, right? So you're looking at the whole system and you can break that down into subsystems or domains. And then you can break that down into components and then you can break that down into classes. So the you can have different
levels of connection. The thing is, the more low level you go, the more you want to have these items very cohesive, right? So if two people are working on the same thing together as a sub team, it should be very cohesive and in one one way they create a certain isolation with the other two guys that might be working on something else. These are options that you can only experiment together with the team because the best decision there can only be made
in context, right? I don't think, I don't believe there is a certain formula that you can use, but the rather signals and aspects that you should consider to move forward
with these decisions. Yeah, the the signal of having a stand up and then listening to what people are working on and kind of the the collaboration and discussions, if people relate to and can help, I think that's incredibly valuable because now we're working on specifically in the current team, an initiative that hits a lot of technical capabilities. Maybe capabilities is not the right term, but like technical
size of ownership. I have data science, I have data engineering, I have back end and front end, like the full end to end chain. But when those two or when a few of those are kind of working in isolations, then you do see kind of this split within the team where people are working on
their own responsibilities. And then when we have something that is actually into integration and delivering that user value that we've been working towards in kind of a bigger milestone, then I see everyone collaborate. So then it's the question of should these be a recent question that I had and I asked myself, should these be like 2 separate isolated teams where they then come together for the integration work? Or is it fine as is? And I don't know the answer yet I think.
Yeah, I think, I think you can look back into how software developed have been developed in the past, right. So you can think of a whole engineering department, let's say, and think of, I don't know, let's let's say 30 people. And then you get you, you could have an, an infrastructure team,
right? That takes care of, you know, computing and, and storage and, and the cloud environment, for example, where they're concerned about the database, maybe pipelines, maybe the, the Kubernetes cluster that, that they host. And then you get into a back end team that that actually develops the APIs and the back end services and, and, and stores all the data in the database, maybe maintains the databases schema.
And then the front end team. And you could go up to, you know, UXUX design, UX research teams and then of course the product team taking care of that. So you have a split there on competency based teams. What are the pros of those teams, right. They can interact very closely with peers that work on exactly the same thing they do. So it's super powerful in that sense of OK, we can standardize how back end services are done
in our company, right. So that's the that's the benefit of it. If you get one person leaving the company, likely the other one already has the knowledge of, of what they have been working on because you know, they are going through the same code base. Everything is on their hands and it's easy in a way to share technical knowledge, standards and and principles. So that's, that's very powerful. That's, that's what I see you describing there. What are what, what is the con
of that? A lot of handover moments, right. So when you are trying to do a cross, a cross discipline kind of initiative that involves front and back end and infrastructure, there's so much coordination that you need to do between these different teams, which then you go into the very risky things of doing waterfall
projects, right? So you're planning everything in front and you tell, hey, I need this infrastructure resources, I need this back end services with this API and I need this kind of front end UI. And then you go and integrate all that. Likely you do that after you spend, I don't know, maybe weeks or months of development, you go in into integration and finally that lands in the, in the hands
of the of the customer. What is the risk The customer sees that and has, you know, lots of his feedback to give to them. And that's the, the, the risk of waterfall approaches, right? And, and we know in software development it is as as it is an organic and discipline, you need to have this quick feedback, right. The success of the projects that you execute are often related to how quick you can get feedback for from the end users and
customers you are serving. So these are the trade-offs that you have to handle, right? So of course in modern developments, what what people are doing is like these small teams where you have competencies together, right? So infrastructure, back end, front end and design all together thinking about a vertical of the application. But then internally you remain with the same challenges, right? So you have people that are focused in the back end, focus
in the front end. And what I, what I notice is so thinking a little bit of these other, other iterations, other ceremonies that that can happen if you use the scrum, for example, or, or other methodologies, you notice that sometimes you should you, you can consider taking, you know, refinement or technical design sessions with just a subgroup of those people and, and indeed, that will be the most valuable,
right? So if you were thinking of like, I want to have a session to design the database or or the internals of my service, right, how I'm going to structure the layers of an API? Is it really worth to have the front end team also collaborating? And then the question is, does that front end team will also become a little bit of full stack and touch that service as well? If that's the answer, yes, for
sure they should be involved. If that's not the the goal that they will remain pure front end focus, then likely it will feel for them a waste of time if they would join such a meeting. So as as a manager and maybe as a product manager as well, you should pay attention to those things. And again, listening to what people are feeling those during
those processes is important. And then you can go, you know, to this iteration, this retrospective moment where you can learn and feed and and adjust as you go. I think it's important that these adjustment happens as you go, right? So it's a matter of finding the way that works well for the team, right? I think there are a few basic principles that you want to keep, right? There's you.
You should never have one person that was solidly responsible for one thing in the in the system that that's just a basic practice. You want that that person to be able to go on holidays, to take their days off and if they get sick, you want to be able to keep up with the project that you're executing. But then and, and, and therefore you want to have, you know, not a single person only, but rather shared responsibility on, on a component.
And you have several practices that you can do to achieve that. So having aiming to have, for example, 2 back end developers, 2 front end developers, and maybe as you're pointing out, one or two data people in the team, that might be a few good principles for you to keep on. That's not always possible though, right? So I understand that sometimes you were going to have a team that has only one data engineer,
for example. And then you need to find out different ways to to share knowledge across across different teams, right? So imagine you have one team, that one has one data engineer here and team B that has another data engineer. What are the things that you can do to share knowledge between them, right.
So we Spotify has this model where they have the squads and the chapters and maybe the chapter is a place where people can keep sharing their knowledge so that things can there are no gaps when people need to have adjustments, right? Because during their personal life, they, you know, they might need leave the company or maybe they might need to go on a sick leave for, for unfortunate situations.
And there should be a way for the company to keep the knowledge in place so they can continue implementing the road map initiatives. Yeah, yeah. There's there's of course a place where this happens across teams and then there's a place where this happens within the team. So if there is one back end there that is interested in data engineering, that might be the second person on the data side, right.
If there is a front end developer that's more interested in the back end, that might be the place where it back end and front end, you know, you have more of a full stack developer that is peering together with the back end developer to share knowledge within the team, right. So I think that's usually preferred. So if you can keep that knowledge within the team, that's nice because they are very much involved in in into the daily job of their what they're executing.
If that is not possible, then you need to think of the connection across the teams. Yeah, interesting. I recently had a conversation with a colleague and he always advocates when it comes to personal development, kind of stepping away from this T shaped profile that you probably have heard of and moving more towards pie shaped profile when it comes to personal development. And he then focuses on back end as well as infrastructure is when it comes to then this multi
multidisciplinary team. If you have a team of pie shaped people, then that's like a force to be reckoned with because probably you have overlap. You don't need to have duplicates in people because people have kind of this depth in not just one topic, but two specific topics and probably not equally as deep as kind of your peers, but to a certain degree that you can have the confidence in a team basically to execute.
I think that's very powerful. Like looking at, OK, what do I like and what is kind of adjacent to it. Back in the front end seems like a good fit back in an infrastructure or data and infrastructure and then data and back end front end UX and research specifically in UI, like people are becoming more broader. And I think now, especially with AI and kind of this increased capability of gaining knowledge, you can definitely work towards
depth in, in a lot of fields. The problem is still tech is very wide and when it comes to product development, there's so much you can learn. You still would have to focus and specify and be like no, I want to contain myself to these verticals and then that's it. Correct. I think it's a matter of focus, right? So I, I, I, I have gone through companies that did this change of a person that is a back end developer into I, I have gone
through different things, right? So in the, in the past, everybody was a full stack developer. I have, I have that impression at least or or I should say like 20 years ago that that that was the, the landscape there was not clear split between front and the back end. I think later, later in, in time, we started having these specializations between back end and front end. And I noticed nowadays that people were moving towards more of a, a, a pie shaped kind of professional and, and I agree
with you. And I think finding again, the balance, right, having people to be full stack developers. So we're going from the design to front end to back end to infrastructure and, and down, down into networking and, and computing hardware that that's with, with the scope of the tech nowadays, it's quite rare to find professionals like that, right? So, and professionals would need to have years and years of experience to fulfill those
roles, right? On the other hand, having people only focus on one discipline creates these gaps, right, where you really need to have big teams so it can have all areas covered. So I really like what what you were saying. So having people that maintain focus on one discipline and they go, go a little bit across the board on the on the discipline adjacent to to what they do.
I think that's that's where you can find the nice balance between having the knowledge to maintain and do the things you were expert on and to support other areas so you can collaborate together with other teams, right? If you know a little bit of what the other team member is doing, that's also very valuable for feedback, right? People will do their best job in isolation, but it's often extremely important for you to get review feedback from other
team members. So if you are the unique back end developer in your team, you're at the big risk of of your own blind blind spots and biases, right? So you're developing your code. You can send a merger request to another colleague and he might say, yeah, from what I see, that's good. But if he has a little bit of more competency to do a critical review to give you feedback, you can reduce together a bunch of biases during the development as
well. It's similar to that old principle of like if you develop a feature, you you share that with someone else to test it, right? If you don't have a Kuwait team, right, you, you just like, you need to have another developer testing because when you're developing and testing your own software, you're directly at risk to go through your own biases and, and, and have very obvious mistakes done that will be quickly captured by the user.
One way to prevent that, give it to someone else and just let them test what you have done, right. So I, I, I really like this this idea and this approach of having the competence is a little bit shared between team members. Yeah. For me, it's also like a means to an end with regards to team size then, because if you don't have that, your team grows in people and with big teams you get like a lot of people problems. Yeah, coordination, right, Coordination, alignment
discussions. You mentioned that indeed you have teams within teams that then engage probably within their own circles, but there's not a lot of overlap. And then if you have a discussion, especially from a product sense, like I've been thinking about this, do I involved in the whole team or do I involve people that are interested? But I do think everyone needs to have kind of this broad knowledge of the domain, but not everyone needs to go deep. So then when do I involve them?
Is that very early on when things are like super vague or is that too early? Because I've also gotten feedback like, yeah, it wasn't really that valuable. So it's very difficult when team size grows when to involve the former product sense and then also when it comes to effectiveness like I don't know what the right team size would be then. Yeah, that's lovely. You're you're falling through the topics I had in mind by by naturally. So thanks for that again, road
map team domains, right. So application domains third stakeholders 4th team size, right. So if you are thinking of reshaping the teams in organization, there's, there's some research, right? There's the lovely book called Team Topologies that talks a lot about team settings and, and the ideal team size will sit between three people and nine people, right?
So 6 and 9 might, might be a bit of more sensible as team setting, but more than that, you go into a lot of coordination that you need to do and it becomes every meeting you have. It's very expensive, right? Because you'll get everybody in A room and and every meeting becomes really expensive in that way. So so you should be thinking
about those numbers right there. There's lovely reading that you can do during in team topologies, but they talk about 11 interesting fact is the Dunbar number, right? That talks about how much trust relationship you can keep between people in, in different levels, right? So, and, and the numbers tell around that you can keep trustworthy relationship, close relationship where you were really aligned with the person with around other five people.
So that's a general estimate of, of human interactions, right? So people that you can deeply trust and connect to like your family members and, and you know, your, your close relatives. Then there's another moment where like we're talking about 10 people where you can still trust not as deeply as these five people, but like you can still develop some quite trust relationship and connection with
these people. There's another moment where that breaks, which is around 50. So that goes into a different level. You can remember still the name of everybody, right? When you're talking about 50 people, you can reckon them by first name and say, Hey, I know
your name. I know where in which department when you work on and, and, and which team you work on and then you go to another number of 150 where you vaguely, you know, know names of people when you you vaguely remember where they work on, but you reckon them by face. I know this person works in my department or so you have different levels which play a role in in the way that you also
set up organizations, right. So if you want to create this deep connection where people can be high performance, can count on each other and it's easy to go through processing new requirements and changes in the software. Because you just share so much of your, you know, principles and values with this person that whatever the decision they made, they make are very much aligned to the decisions you would make
yourself. And you kind of just complement each other into the into the differences, different perspectives you have. That is the type of of way of working you want to get into these teams, right? So you want to keep the teams with that sizing right between, you know, 5 and 9, nine people size involving people at the right moment. I have heard that from so many
product managers, right? So, and, and from both sides, right, from product managers and developers, the developers after are either complaining that you involved me too early and that's completely out of my focus or complaining about it. It, why did it involve me early, earlier in the process, right? And I I I don't have a a specific formula for that, but I noticed that sometimes sharing different levels of information at different points is what is. The request the developers have,
right? So knowing that something is upcoming and that the general idea is this and that what is expected from them now is XY and Z. Maybe that's the type of information they want to have at the beginning, right? So hey, we are thinking in this direction at the moment. I don't expect you to do anything, but you think this direction doesn't make sense. Please let me know. Or if you have opinions or strong opinions about it, please let me know.
So when you have this type of communication at the beginning, people at least have this sense of being involved and have the chance to contribute if they feel like they should be contributing at that moment, right? As, as you evolve close to the project and then you go deep into, OK, we're getting ready to start developing that or thinking about it, the technical aspects, then people want to be
more involved, right? But I think the level information, the level of information that is shared at different moments is where I think product managers can do their, their, their beautiful game of presenting the information at the right time, right? Which is I can, I can honestly say super challenging, of course, because I think along together with other project
managers about that too. And, and what I observe is that when you have engineering managers and product managers that can work together, well, you see that happening right then they, they can, they can think together. So product manager comes to engineering manager, Hey, we're going to be working on this project. Do you think it's a good moment to involve the team? Boom, then the the engineering manager? Well, the team is focused on XY and Z and they are not really.
They're they're concerned about these other problems. So when there is this interaction, they can find out together and and talk with the team, right. And again, learning, learning, learning, right. So if in one moment you got to involve people too early and in the second moment you involve involve with them too late, I just write and try to find contracts together with the team. I think that's the power of having stable teams. You can learn and evolve
together as a group of people. Right. Yeah. What I do, what I used to do is mainly based on my own experience. I was like, I, I wanted to be involved early. So then when we would kind of kick off a new milestone with the rest of research and design, I would have everyone there, stakeholders and engineering team. And then I got feedback that for some engineers like it was too early. So then I decided also time wise, like involving everyone, like you mentioned, if you have
a big team, it's expensive. So did the opposite. Then I didn't really involve them very early on and I tried to kind of across that bridge by communication and kind of focusing on the why and outcomes and so on and so forth. But as an individual from a product sense, I noticed I'm becoming a bottleneck because first of all, I can't answer everything. Like still I don't have all the knowledge. So then I would have to go back and forth between tech and stakeholders, which is also not
ideal. And I also don't want to have people not feel like they have an option to kind of collaborate and contribute. So now I ask, I'm like, this is kind of the focus. This is why we do this, provide clarity on kind of the outcome we try and achieve and then we kick off. And I'm like, who wants to be involved? And people step up.
And I've noticed the same people step up, which is not a bad thing, but those people want to be involved rather than just the technical side, want to understand more of the domain. And I see it's paying dividends because in from conversation to conversation, they remember specific nuances probably related to the what they're responsible for on the tech side. And they challenge certain assumptions that they have or also solution directions.
And I really enjoy this kind of way of working Now. I think I'm going to stick with that well, where I'm just going to give people the option to contribute and to collaborate early on. And they can decide, OK, this is valuable for me or this is not really valuable for me and I can challenge, OK, do you want to be involved in everyone in every conversation or more on this side? And people actually take accountability and ownership of that as well, which I really enjoy.
Yeah, fantastic. I think it's interesting to observe how, when, when you get this involvement, at least in my experience, what I noticed is also inspire other developers as well, right? So you get these people that are wanting to be involved early on, but you can get other people that are actually inspired by that, right?
So they, they get really curious about what's going on on the business side and, and get more involved into what are the customer needs and the, and the user needs, right? We're talking about a certain setup and I'm just guessing now of of a very a setup of a very big company, right?
Where sometimes you have a few layers between your user and your end user and customers that go through, you know, stakeholders, project managers or product managers, I'm sorry, and then it lands into the developers. But I think the closer you can get to the end users and to the customers, the more you can help the team to develop a customer centric mindset, right? So what, what, what are the risks of of having so many layers?
And I think you might know well is that you in in, in incurring the many assumptions and translations that happen between what the customer is expecting or the end user expecting through these different layers. You might lose the feedback
loop, right? That you could have directly talking to the end user and experiencing and evolving such features together with the user and evolving the developers early on, I think for me means getting them closer to the user and to the customer needs, right? A few experimentations that can happen there and which which are very interesting with and and and I've been trying out recently is design thinking principles, right?
So trying to think from the customer shoes, really thinking of like what are the problems the customer faces in the in the daily life of what your business domain is right or your your solution space is right. So if you put yourself in the shoes of the customer and think of I want to, I, I have this challenge and I want to solve that. And you get a group of people that is multidisciplinary to think about that you create so much empathy, right?
And that empathy is powerful for people to for several reasons. One of them is to understand what customer needs they are fulfilling to to improve the quality of what the outcome will be and also to challenge each other, right. So if one of one of the people there say, hey, I think there's the solution for the problem. The other one saying, yeah, but I don't think this really solves the problem of the user. Those are really powerful conversations to to be had,
right? And I think the third aspect is quality in itself, right? You want to you see your user using what you deliver. You want to be proud of what they are, of what they're using and what you're delivering,
right? So having, I think the quality becomes just a natural aspect of what you want to deliver as a developer, as a product and engineering team, because you feel that what you were delivering has value for real people in the end that will be happy or not with the product they are using, that will have their problems solved or not, that will have an intuitive interface or not, that will be something to be proud of or not, right? It's such a fulfilling feeling, like that's the best, to be
honest. Exactly. You were discussing Dunbar's number and I was thinking back to kind of my previous experience with regards to teaming and re teaming. I my only experience has been very early on, like now as a consultant, I go in and out of teams, so I don't really have that much impact on organizational changes. But back then it was probably my first year as a developer more towards the the end of that.
And then management decided we're going to re team and I didn't really understand kind of what problem we're solving or what team we're going to. But especially if you have a bigger organization where indeed for 150 people, you don't really know the people like you don't have that, you don't have the capability to form those connections.
Then basically, yet you are responsible for organizational structure delivery with regards to productivity and fulfilment with regards to KPIs and, and the deadlines that we have or at least the delivery road map for the company. Because I even think people that make those decisions do it. Everyone does it with the best of the company's interest at
heart. That's a strong feeling that I have and it will stay that way until I feel otherwise by building a relationship with someone and learning that. But otherwise if everyone decides kind of with the best at heart, if you are responsible for that big number of people, you can't build those relationships.
So then you look at other aspects and if that buy in is not necessarily there, that's what I had in my experience, I just feel like a number or a responsibility from a technical side and then you get placed in a team as a an ex developer and then that's that. Like I feel like the buy in for teams to be actually owning what they have and fulfilling kind of that process of becoming a team is super important when a
reorganization happens that way. 100% yeah, it's AI think the most important aspect actually right. So because it it costs a lot to to do a team change like that, right. So you invest both management time to think about it, to guide people to communicate, to make sure this happens in a successful way.
You get people that might have already a stable relationship with their peers and are used to the domain they're working on lowering their performance and actually have there is a ramp up that should happen again after the team has changed it. So they will find their own way of working, get used to their own, you know, ceremonies or communication style and get used to each other. So definitely there is an
important 'cause there. So when you were doing such a team change, it's important that you get the binding of the team, of the team members, because then you get these these processes going through in a much healthier and quicker way, right? So change by itself is something that happens, right? You, you, I think accepting change is the best way. But then there is another thing
which is embracing change. If you can embrace the change, then you see the change from a positive aspect and you can take it as a learning opportunity, as an opportunity to get to know new people, to own a new domain, to take responsibility and to get things into a better shape, right? So that's why the buying is so important.
So when you were talking about the transformation of like such a big, a big structure, I think one of the challenging aspects is to really understand the technical aspect. So and, and, and often you have these, let's say this gap between what the management team knows and what the technical team knows about how the software state is, right. So if you can gather technical input from the team on like, hey, this is our software architecture right now.
So as is, and this is where we want to go in terms of dividing modules of our application or, or or cleaning up maybe technical depths of the past and making sure we have a nice clean solution that it can evolve into the needs that the business have. If you have that input together with the thinking on the team side, I think that's one of the one of the important aspects. By doing that, we also get the input from from the technical team, right?
And of course with 150 people, you cannot do this with everybody, right? But you need to go through with a few key people with it that have experience in different parts of the software that can give you input about that. I think the other aspect is being transparent, right? So being super transparent when communicating these changes on
why you were doing that. What are the things you have considered about it, helping people to elaborate on the consequences and also going through that on OK, once we have changed, what are the channels that they can keep inputting, you know, giving signals to their management team to so they can adjust on the small areas that might be blind spots in the way that we have defined the new teams, for example.
So those are things that you need to go through to, to, to in, in my point of view to get the buying of the team and especially transparency, right. So in one of the reorgs that we have gone through, I have actually written together with the with the leadership team A9 pages document saying, hey, we were here, we are coming from this situation of team structure. We are observing these problems.
This is the new structure that we are proposing because XY and Z and we are observing these consequences. So we expect to gain this and this and that benefit from this new team structure and we're going to do in this in that way.
So writing down a document or being very transparent to the team to say this is what we are aiming at and these are the problems we're trying to solve, I think automatically gets people to at least at the first level of awareness and understanding of what's happening in the teams. And then you need to continue moving on into helping them, elaborating the consequences and helping them, you know, feeling engaged into the process as well. And those, those are definitely big challenges.
I'm, I cannot make them less than what they are, you know? It's interesting how you described it made me think like you can see a team as kind of the the outcome of your product basically and how you communicate if you involve people early or if you involve them too late, like you might lose them in that aspect. And also with regards to how things are performing, then those metrics that you use as input to do another iteration of improvements, like it's very
much like a product. I would say you make a change, you don't know what's going to happen. I hope you can kind of do an experiment and fail fast as well and learn from that and then decide before you do a massive rollout. It's just the only thing that's different is these are people on that kind of their processes and way of working Like it's, it's way more nuanced.
That's it. If you if you involve people to whirling such a process, you might actually create too many rumours and fear actually, right. So if you're starting to think that we actually need to change teams and you just get to start talking to people, hey, what do you think we need? We should change teams or not. And you do that too early. You might actually just create people to to go into fear mode of like, OK, what's going on?
Is the company going through a big reorg or and that might actually be counterproductive, right? If you involve them too early, you get the feelings you just described before. I'm just a number people don't care about what do how do I feel in the organization or what is my contribution to what we are doing. So that's it's definitely similar in in that regards that you need to find the sweet spot there to get people involved.
One of the mistakes that I, looking back into my own experience, I think I, I can share as a learning opportunity for others that are listening is communication is not a one time thing. So I mentioned to you, I wrote this 8-9 page document explaining why and so on. And we had a second moment where we had a big meeting with the people to communicate what we were going through, why the changes, what's happening and so on.
But one thing I noticed is during the upcoming period, right, you know, a few weeks after that or maybe even a few two or three months after that, there were still questions from different stakeholders, from different team members to and say, hey, OK, I understand. I change it into a new team. What is the scope and responsibility? So I understand we take care of this and this part, but this component is actually a shared component that all teams need. Then how do we handle that, right?
Or maybe stakeholders, OK, I understand. But so before I used to go to this team to ask when there was a bug on this part of the software and did go to this team and now I need to go to that one. But then the other component that for me is very similar need to go to different team. What's going on? So the communication is not, I think should be seen not as a one time communication, but I'd rather something that you need
to repeat a lot. So it's not, it's not something that you can do and say, hey, there is a document that explains I have done my presentation and meeting people, ask questions, I'm done. Yeah, no, it's something that you need to, you know, elaborate together with people and, and, and go through the process together with them. So it is it really materializes this, this new vision that you create for your product or your teams, right?
I think that's that's a key learning lesson that that that we can take, that I can, that I could take out of my previous experience. Yeah, I, I see that from my own experience, like being on the receiving end of communication, you know, instantly when things are either not clear or when you want more communication, when you're the person that's like preparing everyone, kind of educating others and
communicating. It's very hard to see what everyone's kind of information diet is or what their needs are. Like patience as the person that is orchestrating and having that ability for empathy are like so crucial because if you don't have patience, someone comes up with a question, you're going to be like, well, I explained it five times or it's in a doc, you're going to lose it basically. Correct. You have to have patience to actually accommodate for people's feelings.
And it is kind of people management because in the end you're changing the processes, you're changing the habits. People don't really love change in general. So for them to be able to embrace change, there needs to be that person that is them educating whatever they need, whatever question they have, and they need to feel hurt basically. Correct. And I think the biggest challenge for for people that are in a leadership position is they have all all the
information, right? So you can go through this process of thinking about team changes with a leadership group for one month, two months, three months. So you have been talking about that for a long time. Yeah. So everything could be super clear on your head. And then suddenly you were dealing with 30, fifty, 150 people that are on board and in
that. And I think you often underestimate the amount of time it takes for people to really understand what is the new picture that you know you already have clear for three months on your head. So I think that's something that you need. You never should underestimate, right?
Going through that process together with people giving time, having many conversations about it so people can ask all kinds of questions and really get a clear picture of why this is happening and what is the new what is the new outcome? What are the consequences and where is their place to
influence that too? I think that's super important as well, where people feel like their voice can be heard and that that will be taken into consideration for whatever new adaptations that need to be done. Yeah, yeah. Yeah, I agree. I've really enjoyed this conversation on that. This was a real blast. I love hearing about your perspectives and kind of your experiences next to the theoretical knowledge that you have and bouncing off my own ideas and experience off of that.
I'm definitely going to relisten to this. I think there's. It's fun. Thank you very much for sharing that. I love that too. It was very natural, man. Thank you. Thank you. For people that don't know yet, Andre was actually on I think 3 1/2 years ago, very, very early. We talked about software architecture. So if you like this episode, go check that one out and otherwise we'll see you on the next one.