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.