Often we're focused on what are the good practices or best
practices? And what's the best way to do
things? Practices and principles are
obviously necessary and useful, but they should be informed by.
What are the constraints in the first place?
Constraints are usually things. We cannot really change.
So limits on cognitive load limits on trust between groups
of teams. Conway's law are things, we
cannot really change. So we need to acknowledge them
and then build and decide on practices and principles based
on that. Because if we don't, then we
might be be fighting this constraints rather than
understanding and leveraging them in our advantage.
Hey everyone. My name is Henry Surya be Robin.
And you're listening to the tekhelet Juno, the show will be
bringing you the greatest technical leaders practitioners
and thought leaders in the industry to discuss about their
Journey ideas and practices that we all can learn and apply to
build a highly performing technical team and to make an
impact in your personal work. So let's dive into our Journal.
Hello to all of you my listeners.
It's great to be back here again with another new episode of the
tackling Journal podcast. Thanks for spending your time
with me today, listening to this episode.
If you haven't, please subscribe to technology, you know on your
favorite podcast apps and also follow technology.
No social media channels on LinkedIn, Twitter and Instagram.
And you can also make some contribution to the show and
support the creation of this podcast by subscribing, as a
patron at package, you know, dot f / Patron.
And help me towards producing great content every week for
today's episode. I'm very happy to share my
conversation with manual Pysch manual is the co-author of the
team topologies book. A devops thought leader, and an
independent, it organizational consultant focusing on.
Team interactions delivery practices and accelerating flow
effective software. Teams are essential for any
organization to deliver value, continuously and sustainably.
But how do you actually build the best team Organization for
your specific goals culture, and needs in the book?
Team topologies manual and his co-author Matthew skeleton.
Share secrets of successful team patterns and interactions to
help it organizations choose and evolve the right team patterns
to ensure success making sure to keep the software healthy and to
optimize for Value streams. In this episode manual, shared
great insights from his book. Team topologies starting from
highlighting some constraints that organizations, typically,
face such as Conway's law and cognitive load manual, then
explain the four fundamental team topologies, and how they
can help to address those constraints.
He also shared about the team API concept, as well as the
three call interaction modes, which inform how teams should
interact with each other in order to improve the overall
flow within the business. Finally manual.
Shared some advice on how we can.
All start implementing these ideas within our organizations.
I personally really enjoyed this conversation and I hope you will
enjoy this episode to consider helping the show by living it.
The rating review or comment on your podcast app and social
media channels those reviews and comments are one of the best
ways to help me get this podcast to reach more listeners and
hopefully they can also benefit from all the contents in this
podcast. So let's get this episode
started right? After our sponsor message.
Are you looking for a new cool swag.
Technology, you know. Now offers you some swags that
you can purchase online. These wax are printed on demand
based on your preference and will be delivered safely to you
all over the world where shipping is available.
Check out all the cool swag is available by visiting
technology, you know, the dev slash shop and don't forget to
break yourself. Once you receive any of those
tracks. Hey, everyone.
Good to see you again. Today.
We have a new episode of the package.
You know, I have someone who I admired as the co-author of a
book that has a rave Review called team topologies
organizing Business and Technology teams for fast flow.
So if you have a heard about the book or maybe already read the
book, you know, what kind of things that I'm talking about.
This person is Manuel, piyush, is actually one of the calls.
The, and I'm really looking forward today to learn more
about teams, apologies, how we actually should structure a Or
maybe some of the anti patterns that we should avoid when
organizing team and also within a company.
So thanks again manual for agreeing to this conversation.
So looking forward to have a chat with you.
Thanks for having me. Great to be here.
Someone. Well before we start talking
about teams, apologies and all that may be for you to introduce
yourself. Maybe telling about your career
background and highlights and turning points.
Sure. So I have a background in
computer science. As does my co-author Matthew
skeleton. I've had a number of different
roles from Developers. To tester build engineer team
lead, keyway Etc. That kind of gave me a broader
perspective within the software delivery environment of
different roles, dependencies between different teams,
different skills that are needed.
Especially when devops and continuous delivery kind of came
about ten years ago or so. It struck a chord with me that
yes, this is very much what we need to think about the flow of
development of software as well as the production and the life
support. Port.
And we need better ways for teams to communicate to each
other. Understand dependencies between
them because before that was very much based on specializing
by skills and by competencies each team trying to be a
specialized as possible. We've seen that doesn't work,
especially if we don't think about the ecosystem of teams,
right? One of these teams, you know,
isolation cannot do the work. That is needed to get the actual
software product, or service available to customers.
So, basically, I embraced devops Good news delivery.
I became lead editor for info Q around devops as well.
It's been a great journey of meeting really amazing people
with great. Insights since 2015.
Then I started doing consulting. And so, working with different
clients around the world. Understanding, what are the
obstacles for them to basically accelerate being able to respond
faster to the customers? And also to changes in market
and adapting to new situations. Obviously, it's always that mix
of Technology people and processes.
These. But with team topologies in
particular, we're trying to both raise awareness of certain
constraints and certain kind of human focused aspects that are
important to understand, for organizations, to be able to
accelerate or become higher performing, as well as providing
some tools. And some ways of thinking that
can help guide this organizations to a better
operating model. If you like that is more team
focused. So, maybe let's go into that
topic itself out team topologies.
So, in the first place, You wrote this book, what exactly
the core message of principle or even the problems that you for.
Seeing during that time that lets you into writing this book.
We did a lot of Consulting around devops and continuous
delivery. Many clients wanted help with
some new tool set adopting some better practices and that's all
good and well and it helps to some extent.
But in many organizations, they're not looking at the
elephant in the room where teams are not communicating in an
effective way. Teams don't even know sometimes
who they have to ask for certain things.
You have that, what I mentioned, very strict separation of
concerns and responsibilities, which means you introduce a lot
of dependencies to get any sort of value to customers out.
The door means it has to go through many teams doing small
things. And so that's not conducive to
fast flow. You can have the best tool set
in the market and that's only going to help you to some
extent. When you have the combination of
do flow of work in the team's, it flows.
Well, Because the team has sufficient autonomy.
And they understand their dependencies.
We avoid that sort of blocking dependencies where one team has
to wait for another team to do something.
Once we achieve that sort of faster flow with more autonomy
than yes, the tools can then hyphen even more this sort of
fast flow, get better data, get better automation, Etc.
But if we just start with Automation and tooling, we
quickly run against challenges in terms of Team structures and
communication. So that's what we were saying,
recurrently with clients. We thought that some point.
We had seen enough patterns that work and patterns that didn't
work. Also a lot of learning from the
devops Enterprise Summit this conference.
That happens every year from the Publishers of the book as well.
It Revolution. So a lot of stories that were
being shared by different organizations on some of the
patterns that work and we didn't work.
So we sort of brought all that together into the book.
So I think, what I hear you say is that a lot of teams this day,
they will definitely start with tools and Technologies,
probably, right? Thing about how to implement
those, but actually, without looking necessarily to what the
team structure or even the rock structure at that point in time
within the company, you mentioned, interestingly in the
book. Actually.
The first problem is with the org charts itself.
Why do you think typically of chart is maybe the first
problem? We're all this may be a barrier
to fast flow. Maybe barrier into dependencies
blockage and things like that. So maybe you can explain a
little bit around that sure. So let me say the org chart is
not a problem per se. It's not that we shouldn't have
or shorts. They have important benefits in
terms of understanding how we are.
Organized special in large organizations.
It helps with reporting and hopefully also helps with kind
of top-down alignment of strategic goals for the
organization. So everyone understands, how are
we related and how does our work relates to the goals that the
organization is trying to achieve?
So that's all fine. The problem that tends to happen
is when in a way, we give too much importance to the org
chart. In the sense that People started
looking at it as specifying, all the decision, making lines and
specifying with home. Should we interact or not?
If this team is in another department and we shouldn't talk
to them directly. We need to go up to Yaar Ki and
then down the arrow key to get the team.
Those sort of things is where it starts to become a challenge to
fast flow because with the complexity of modern software
delivery and operations, you can do that, but you won't achieve
fast flow because there's too many steps and too much
redirection in a way through the They are key to get to the
actual work getting done. So we want to favor for fast
flow. You want to favor, local
decisions and having teams interact with the right things
at the right time. And so, when you introduce those
sort of blockers with the arrow key and decision-making, having
to be top down, then we're not allowing the people who are
doing the work and closer to the customer to, actually make the
best decisions. That's where really the org
chart can become a problem where people see it as imposing the
communication, lines and imposing Making lines between
teams. That's the key issue there where
it becomes an obstacle to fast flow.
If we misinterpret the org chart as dictating, all these things.
Unfortunately, in many organizations that tends to
happen. It also is coupled with the
problem that in some organizations.
The worth of the managers senior managers is linked to how many
people report to them and that kind of feeds into this
narrative that you need to go up the hierarchy for any kind of
decision making. So that we Can show proof that
the value of the senior managers?
Hopefully, with Team topologies. This sort of approach is being
replaced or move away from that to more.
How do we enable the people and the teams who are under our
year, key to actually be able to make better decisions, more
autonomously and not depend on the are key.
So if I get the sense that fast flow is actually of course, it's
like the main objective that we want to achieve.
But let's say, if we are currently working in a team or
in a company, how do we actually Identify whether we have a good
flow, fast flow, slow flow is any exercises?
Then guidance on how to actually find out where we are at this
point in time. Yeah.
So a couple of things. Well, first, there's a very
straightforward metric called flow efficiency, which is
essentially looking at how long it takes from the moment.
We have an idea for a new feature or new service until
it's actually available to the customer.
So the full kind of lead time from idea to production.
And from that overall, elapsed time how much have we actually
spent working on this feature service versus how much was wait
time? So it turns out that in many
organizations. The actual work time is about 15
percent or less. So that means out of 100 days,
maybe that it takes to get a feature out, 15 days, where
actually work days and 85 days were waiting for someone else or
another team to have availability or someone to
approve or make a decision. When you look at that metric,
which in a way, Very simple, then you can sort of, like,
starting to unfold the flow problems, right?
You can start looking at. Okay, if we spent all this
weight time, where exactly did we spend this?
Wait time? We spend maybe a week or two
weeks, waiting for some infrastructure to be available,
or we waited one week for some approval to start digging into
that. And you start seeing where are
the, wait times, that we want to reduce if we want to achieve
faster delivery. So that's one thing.
Also, the nice thing about that is you can then look at the
flow. Efficiency at different levels,
you can look within the cycle time since we start coding until
if we deploy or you can look at the broader picture of since we
started since we approve this idea until it's actually start
to be used by customers. So you can start wherever it
makes more sense. Sometimes teams don't have a
global view of all the steps in the process and they might want
to look at their own domain of responsibility and understand.
Where are we kind of slowing down, but obviously, at some
point you want to have a more systemvue.
Do you want to see? Because a lot of people say that
about agile some organizations have successfully sort of
adopted agile principles. They have accelerated the speed
of the agile teams, but when you look at the big picture, how
long it takes between an idea actually being approved and
going to production. Maybe there are a lot more teams
involved. Maybe you need financial
approval. You need product, team, product
owner, or product manager approval.
A lot of different steps. Might be required to actually
get until the agile team starts working on this.
So yeah, flow efficiency and then obviously also value stream
mapping. So that's the technique for
actually looking at the overall process and looking at
dependencies between teams, looking at where their cues were
work. Piles up for some teams.
That's more kind of visualizing this whole process, but in terms
of metric, then the flow efficiencies is quite helpful.
So I think also another anti pattern that normally I heard a
lot then it is mentioned a lot of times in the book as well,
which is about Conway's law. Maybe, can you explain a little
bit on that? What do you mean by Conway's law
for people who are not familiar with it?
Yeah, so I'd like to see it as a constraint, not necessarily
anti-pattern, just something that we should be aware.
Especially in software driven. Organizations is Conway's law.
That means is from a paper by Amell Conway, which was
published in 1968. So it's been around for a long
time, but it got more traction with the rise of micro services
and people started seeing in practice how this is actually
happening. Basically.
It says one of the corollaries in that paper that became known
as Conway's law. Says that the structures that
your organization has and the communication paths between
teams strongly influences, the system architecture that we can
achieve. So that means we might have
wonderful architecture that we've designed and that's what
we're trying to build for customers.
But then if the team structures are very different and we don't
have the necessary communication paths in place to achieve that
system architecture, either. We will end up with something.
In quite different on the system architecture or it's going to
cost us a lot more. There's going to be a lot more
challenges because of poor communication responsibilities
that are not aligned to the responsibilities that we expect
in different parts of the system and so on.
So we should see this as a constraint.
It has been validated across different Industries, Conway's
law. And like I said, with
microservices, people started to see these more because
unfortunately, in many places, they thought, well, yeah, this
is the right, architectures, going to lie.
Allow us to go faster, but then they forgot the alignment of the
team structures and communication paths.
And so they ended up with still needing any kind of non trivial
change or feature to require coordination between multiple
teams. The when with microservices the
expectation was that each team will be able to evolve more
independently. And so that's the idea of
Conway's law. So if we are aware of that we
can then make better decisions. We can apply what people call
reverse Conway, maneuver, where it means.
Okay, we can design Our kind of Ideal system architecture that
we think, is going to be a better fit for the requirements
of the customers, and also the non-functional requirements and
then let's look at our team structures and Communications
and maybe adapt them to be more aligned with the system
architecture. There's also a great quote from
Michael Nygaard, who wrote the book, release it, where he says,
when you ship a product, you're also shipping the organization
structures with it. So basically he's talking about
Conway's law and the fact that you get this mirroring effect in
the system of the actual structures you have in the
organization just to add to that, another corollary from
that paper from Canal. Conway was that if you have a
very rigid organization structure, and we go back to
your previous question about organization chart if that's
very static and regions, and it doesn't change easily even at
the team level, that means we're effectively constraining the
kind of solutions. We're able to find for our
systems. There might be a range of
solutions that we don't even think about just because of the
Teams are set up, especially if they're very rigid and it's hard
to change. So, one related, question that I
have does it necessarily have to start from the system
architecture, or the ideal architecture that we have
because in a company or business, there are so many
other departments, for example, from Finance from business, from
a bi-product. Does it always necessarily have
to start from product architecture?
Like maybe from technology point of view, or do you actually also
has a lineman with the product team first?
Like, okay, based on how the business do the business model?
Also aligned with the strategy with the technology team on it.
Then you come up with a team strategy, maybe a little bit
clarification here. Yeah.
That's a really good question. So, two things first.
Let me say there are many decisions being made in
organization outside it that actually, because of Conway's
law can end up having an influence on the system
architecture, if team composition and team structures
are decided, for example, by a jar, and there's no sort of
input from the technical side on, how does this impact to the
work? We're able to do on the system
and the software. Then it jarred some extent is
making decisions on that architecture because we're
limiting the possibilities that we can achieve because of
Conway's law. So that's definitely impact from
other parts of the organization in terms of what we can achieve.
Even if you think about now that we're in this remote or hybrid
world the way you set up your communication tools, your slack,
or Microsoft teams, or what have you, and might actually have
some influence in the way that teams communicate.
Because if any team that depends on another Team that's in
another slack. That I don't have easy way to
communicate with them. That's actually going to
restrict our capacity to decide together based on our
dependencies. The other thing I wanted to
mention. I think you're absolutely right
that this decisions doesn't start only at the system
architecture level. So especially if we want to have
teams that are more autonomous that can deliver and have more
ownership over a slice of a larger product, which tends to
be the case in many organizations that we have
larger products or services. Customs, have a limited number
of team members, then we need to break down this larger product
into smaller chunks. And that's another problem.
We've seen often is that even on the business model side, if you
like there is sometimes monolith organizations that grew over
time and because they were successful and they delivered
useful products and services, but things started to get a
little bit messy and we don't have Clarity anymore on.
What exactly are the different sort of business lines or the
different value that we provide to customers.
Is it becomes blurred and you get this software monolith?
Yes, but also model is on the business model side at the same
time because we just build on top of what we had before and
now it's very hard also to decouple the teams.
And so when we want to do that, we need to start with actually
the business model, understand. Okay, what are the different
value streams going back to that as well?
What are the business value streams?
What are the things that customers pay for or are
interested to that we provide so that we can then Have better
understanding what are the independent lines of business
that we can then align teams and have those teams deliver value
more independently. So yes, it basically starts.
They're speaking about monolith, since you mentioned about it,
many teams, probably currently work with the Monopoly system,
supporting multi lines of businesses and business models.
And of course, the biggest topic everyone wants to talk about is
how to break monolith into microservices.
Is there any good practice from the team topologies point of
view? How to actually conduct?
This exercise. Yeah, so we tend to recommend
that you take a step back before going into microservices.
It can be very helpful. But before we go to that sort of
level of granularity, if you look at the monolith, what we
talk about in the book are fracture planes.
Look at the ways that we can split the monolith that are
effective and that will allow teams to align to this different
smaller pieces. Microservices tend to be from a
more technical perspective. How do we split?
Listen to into different parts, but actually there are different
fracture planes. You can think about obviously
what we just discussed before about the business value
streams. That would be the main kind of
way that we would split the monolith in the language of
domain-driven design. This would be your sort of
bounded context that you understand, this more or less
independent from other contacts of business, but then, there are
other ways. So, we might even be splitting
monolith to some extent based on the location of teams on the
time zone. Owns of teams because if you
have two teams that almost have no overlap in terms of their
time zone or the working hours because of their time zone, then
it's probably a good idea that they're working on very
different parts of the same system.
So they're not working on things that might cause dependencies
between them because it will be very hard to communicate between
those two teams. And we talked about other ideas.
You might have some performance or regulatory requirements on
some parts of the system, which means it makes sense that this
is split from the rest. Stand the sign to one team or a
few teams to take care of. So usually you will need a
combination of fracture planes, especially the larger, the
monolith to actually make sense of that.
And so I think that's the sort of slightly higher level
perspective to start with. Then the microservices, you do,
this more coarse-grained split of the monolith and then you
might look into more fine-grained split with
microservices. I think the other aspect to
consider is the cognitive load on teams that we talk about in
the book. We also want to split and be
mindful of what is the capacity of a single team.
Do we need to split further some larger pieces of the system.
So that actually the smaller pieces fit the capacity of the
different teams, or does this look like it's reasonable size
for a single team to own and to end and we're still talking
about hopefully vertical slices of the original Monmouth.
So these cognitive load seems to be like a key concept within
team topologies. Maybe can you share a little
bit? What do you mean by?
Cognitive load and how do we actually measure whether the
current team really has a good enough?
Cognitive load capacity or is it like too much of it or maybe
even less than it? So maybe can you explain?
What is cognitive load in this sense?
Yeah. So cognitive load is another
sort of constraint on how much we can achieve and how can we
get teams to be high-performing? If we don't like Conway's law,
if we're not aware of the limits of cognitive load or cognitive
capacity on teams, then we're probably gonna not, Be able to
achieve high performance. So cognitive load theory is
actually based on individuals and it's how much of our working
memory is being used at the moment in time.
So that's four individual. So this comes from field of
psychology. This was coined by John sweller.
But what we did with him topology is actually understand
this applies at the team level as well.
It's not a scientifically defined term if you like the
actually research going on by John swallow and others on group
cognitive load, so, It's actually an emerging area.
What we identified is that there is a limit to the capacity of
the team. Again, if the team has too many
responsibilities or responsible for two large size of the system
that are not able to fully understand and grasp how this
code Works how this relates to other parts of the system,
because it's too much for our capacity or we have too many
responsibilities. And basically we're always
running around trying to just respond to requests in the sort
of firefighting mode and context switching.
All the time. That's not going to be conducive
to better performance, more autonomy and more ownership in
those teams. Then cognitive load also can be
split in different types. So we start to understand
better. Yes, the overall idea that teams
have a finite capacity of what they can understand and be
comfortable with. But also, there are different
types of cognitive load. The things we want to maximize
have to do with understanding the business and the standing,
the customers understanding, obviously the system, the code
itself, how it Listen how we improve it?
All those are more related to what is called the germane
cognitive load, everything related, to this solution to the
problem and the solution space. But there are other types of
cognitive load, like extraneous and intrinsic extraneous is
related to all the tasks that we need to do to deliver our work.
How do I deploy my application? How do I run the tests?
How do I access the test database?
All these things that need to happen, but are not directly
related to the problem and the value.
We're providing to the customers and So that's where we should
focus in terms of minimizing that cognitive load.
That's why we introduced the four types of teams and the
Three core interaction modes, which are meant to provide a
sort of ecosystem of teams where you have the teams focused on
the services, but we call streamline teams aligned to the
business value streams. How do we minimize their
cognitive load by providing useful services in a platform
for example abstractions that help these teams go faster and
deploy without worrying about all the details.
Or monitor our service without having to install all the
infrastructure and the tooling. If that can be provided by
platform services that are focused on the experience, on
minimizing the effort for the Streamline teams to understand
how to do these things. With good abstractions and good
developer experience. Then we help them minimize
cognitive load the extraneous kind.
So they have more sort of mental space to understand the business
as well as the code itself. So they can better evolve and
support it. So I think this is enough.
Oh, the good segue to actually describe.
What are the four fundamental team topologies?
You mentioned in the book. So you have mentioned like
streamline team and platform, maybe a brief description of all
the for for the audience here to listen.
So we start with streamline teams.
So this would be teams with end-to-end ownership.
Obviously. There are other terms that are
similar like product teams cross-functional teams.
We call them streamline teams because we thought the provided
a more specific definition, because sometimes you have
streams of work that are not necessarily.
Product or a part of a larger product.
So that's the starting point. So, ideally in organization you
have, mostly streamline teams that are providing value to
customers and have end-to-end ownership.
But because of cognitive load, that means this might introduce
a lot of Demand on this team because we're saying, well, you
need to understand the customer problems.
You need to understand then how to build a solution with
software. You need to understand how to
deploy, how to run the solution to minimize that sort of
cognitive load with an have platform that I mentioned
earlier. Layer where you have platform
teams that are focused on. Providing the Streamline teams
are their customers their focus on providing value to our
internal teams, but also in this product Focus way where we need
to understand our own internal customers and what do they
really need? So we don't go off and build
everything that we think they need but actually we talk to
them, we get quick prototypes, we get fast, validation of, is
this what's going to really help you?
And then we have two more types of teams supporting and helping
reduce cognitive load. One of them is enabling teams.
This teams don't usually build any service.
They are sort of experts in some domain.
What they do is help the Streamline teams in particular,
but maybe also platform teams, increase their awareness, and
their understanding around different domains.
Then this might be more technical understanding about
test automation. For example, monitoring or can
be more kind of product domains understanding more about user
experience. And understanding more about
regulations, perhaps in certain industries.
These teams are usually small team of experts in the enabling
team that are going and helping upskill the Streamline teams so
that they have the necessary knowledge to do their work more
autonomously. Not that we, we need everyone to
become an expert in these domains, but at least have a
sort of working knowledge that we can do the common tasks in
the lifecycle. And finally, we have complicated
subsystem teams, which are optional, we realize in some
cases you do need these teams again because of cognitive load.
So if you have a streamline team where Out of their service
includes. For example, face recognition
functionality nowadays. There are many sort of
solutions, but I actually worked on some systems like that about
10 years ago where they weren't. Well, the third party offerings
that exist today. It was actually you needed
someone with a PhD to understand the algorithm and the stand how
to make changes how to test in those cases.
It makes sense to have a complicated subsystem team where
you say, there's a part of a larger service that really
requires, very specialized knowledge.
PhD. Type of knowledge, usually, not
technology specialization, although in some particular
cases might be the case where this team exists because they
are helping reduce cognitive load on the Streamline team.
So you could have one complicated subsystem team that
only exists to help one streamline team.
Maybe that's the only customer of this complicated subsystem,
but it still makes sense because we reduce their cognitive load.
They wouldn't be able to have end-to-end ownership of a
service where there's one part that is super complicated, but
In general, we find this should only be needed in very
particular case. So most organizations probably
shouldn't have any complicated subsystem teams and in some
cases, they might need one or two maximum.
So you mentioned that the last one the complicated subsystem
team actually is an optional thing.
But how about the other three? The Streamline team, the
enabling team and the platform team, that's a company need to
have all of them because now these days the way I think of it
enabling team, probably a Consulting team can come in and
help too. Enable teams.
And also platform. We are talking about Cloud
platforms. And so many platform as a
service providers. That's the company need to
necessarily have these three teams that you mentioned in the
beginning. So it's not necessarily that you
need two teams. I would say any organization
will be in a better place if they have the thinking around
this types of teams. So platform thinking enabling
thinking. So what do I mean with that?
Well to some extreme because we get this question often.
If we're a small start-up we can't have all these different
teams. So if Start from that, sort of
extreme. And yes, you won't be able to
have stream teams platform team plus enabling, but you can have
the thinking's. So, the platform might be
something as simple as, okay. We use, let's say awas, and we
use some other sauce providers, but the platform, maybe it's
just a Wiki page, that helps teams.
Understand. How do we use that provide some
useful, kind of default some useful recommendations on use
serverless for this types of tasks.
And this is how you can get started or use other services.
Visas for other types of work. In a way, you can define a
platform as just a Wiki page, helping guide teams and
basically building in the shared knowledge of what works and what
doesn't even if we're a start-up and the same for enabling teams
understanding that. First of all, we know that
technology is always evolving and new practices are coming up
10 years ago was developed and five years ago.
I think. Was that sorry started.
That's not going to change that. Sort of evolution is going to
continue to be aware of. How do we help teams?
Evolve in a way that doesn't depend on their free time or
depend on people having the willingness to learn outside of
work. We shouldn't expect that from
people. We should find ways and enabling
teams or dignity. This enabling thinking is a way
of allowing teams to grow, and to gain new capabilities over
time, but you might not have a team, you might have a couple of
people, for example, in a start-up who have been there
longer, maybe are more senior. And so, maybe they dedicate part
of their time to facilitate knowledge to others.
Yes, or maybe even between more Senior Team and more junior
team. If the startup is growing, where
one team is helping facilitate the other, they're not fully
dedicated. But at least you start having
thus enabling thinking. And then at some sort of size.
It starts to make sense that you have platform teams because if
you have many streamline teams, you started want to have ways to
embed good practices in the platform while considering also
the specific needs of different teams.
So starts to make sense to have platform teams and perhaps,
Seems that depends also a lot on the domain.
Like I said, you might have some Consultants helping so we have
one example in the book. Exactly like that where an
enabling team was set up with some external Consultants that
brought sort of the knowledge around continuous delivery and
modern practices for software delivery.
And then you had some internal people who had the application,
the system knowledge. So these people together made
for a good enabling team that helped accelerate their delivery
setup, some good practices and then expired in a way that the
team cuz they had achieved their goals.
There are other domains where you might need a more long-term
enabling team, for example, P user experience or other areas
where there's a constant need to evolve the learning and the
skills of different teams. So it really depends.
But the thinking of why we need this type of approach is what
really matters at any scale. Thanks for that clarification.
So when we have these teams, for example, let's say we have a
streamline team and also platform team or even multiple
streamline teams. In the company, you can have
multiple products and business lines.
I think in the book, you mentioned this concept called
team API how the team should interact with each other.
I mean, a lot of software developers understands about
API, like software apis, but what about team API?
What is actually team API? So it's a bit of a techie term,
right? So apis, application programming
interface is defining the way that you interact with some
system or service through this API.
Basically, it's an interface. So what we're saying is the team
API is the interface to the Team the objective of the team apis
for a team to clarify two other teams.
How do we work? How do we like to communicate
and interact with other teams? What are the practices that we
follow? Also?
What is our sort of roadmap? What are we working on?
What's coming next? It's very much focused on what
other teams need to know about us.
What's going to be helpful for other teams to interact and
understand what we do. So it's bit different from, for
example. Team working agreement, that
tends to be internal to the team where Say okay.
This is how we work together inside the team.
This is how we follow scrum or we follow TD or what practices
do we do internally? And so there might be some
overlap but the intent is quite different.
So the team API is actually making it easier for others to
interface with us as a team. So that we have more clarity and
less ambiguity on how other teams should interact with us.
So maybe, can you share with us? What are some of the good
practices for team apis? Maybe for us to implement?
Until within our daily working life.
Yeah, it's really thinking about the other team's perspective.
So it's a little bit of having that empathy as well to
understand. If other teams might be
frustrated in terms of their interactions with us, or they
don't understand what we do. Okay, how can we make that
better? How can we clarify that through
the team API, perhaps what? I usually recommend two teams is
the team API, should not be a static artifact.
You should evolve it over time as you realize that Problems or
awkward interactions have happened with other teams.
So if for example, we often get slack messages from other teams
asking similar questions with this something that we could
actually make visible in the API.
Maybe there's some documentation that just people don't know how
to access it. So, with the team API, is a sort
of single entry point to our team.
That's where we should. Then make it clear?
This sort of questions. Look at this document and you'll
find the answer, probably in, if not contact us.
So we make that That sort of communication easier and we also
reduce the overload on our team on some things that maybe we
didn't expect to get questions because we have documentation,
but actually it's not visible. It's not easy to access.
You can't expect other teams to know where all of your
documentation is or we'll all of your practices are.
It's really providing this single entry point to help other
teams interact with us. And this is also related to the
tree interaction modes that you mentioned in the book, right?
So maybe you can share a little bit.
What are the Interaction modes that you mentioned.
Yes. So besides the four fundamental
types of teams we talked about, then we have the Three core
interaction modes, which helped these teams understand what are
some useful ways for us to interact.
What are the expected behaviors from us as a team when we're
doing this interaction, with other teams in many
organizations. There is this sort of naive
expectation that well. We just collaborate whenever we
need but that's very Loosely defined.
Find, right. What does that actually mean?
What is the purpose of this collaboration?
And so many teams, actually, when they're talking about
cooperation with other teams. It's actually more.
The relationship they have with other teams, the dependency they
have. They're not actually having
specific concrete ways of interacting specifically what we
described in the book that we found to be the three key
interactions our first collaboration but in a
well-defined way, so we're talking about two teams working
together for a period of time to achieve.
Of a specific outcome. So the more specific this
outcome is the better. We'll be able to identify if
we've achieved it or not. So maybe we're working together
to understand how we automate some deployment of some Services
if the outcome is. Well defined.
And once we have one automated deployment in the pipeline, then
we can say the collaboration is done.
Yes or no. Is the collaboration finished.
And we also set the expectation on how long we expect this to
last. So it's not an open-ended
collaboration. Ian which like I said can lead
to actually more of a relationship and the dependency
between teams where every time we need to deploy, we need to
ask this other team to help us. For example, that's not the
collaboration. We're talking about, that's a
dependency and it's actually a blocking dependency.
We cannot do anything unless this other team has the time to
help us. We want to move away from that
with kind of specific ways that teams should interact to help
them achieve a certain outcomes. So collaboration is one of them
then we have facilitating as another core interaction mode.
Specially for enabling teams. They are facilitating knowledge
to others. So you're typically not actually
building anything or working on some service where you're maybe
pairing or running some workshops or helping teams
understand improve their knowledge around.
Some aspects of either the business or the technical side
or practices that we use in the organization.
So that's the facilitating again should be framed in terms of
what's the expected duration. What do we want to achieve?
What should you know? After we've facilitated for this
period of time and finally, we have acts as a service.
So that's very much based on things like infrastructure as a
service or software as a service where especially for the
platform we're saying. At some point.
We want to have services in a platform that are mature enough
and stable and provide a good developer experience with the
right documentation, right? Level of reliability.
So that teams can consume without actual interaction.
So it's the lack of interaction. As we have this service in a way
that is easy enough to understand to consume
independently. So have one team, providing a
service and then one or more teams consuming the service,
very much. Like you consume AWS Services,
right? You don't expect to have to talk
to AWS Engineers to run their services.
They've done the work. Hopefully, there are degrees
around this where sometimes the service needs some improvements
and the documentation needs Improvement, but, in general,
they're at mature enough state, where other Ins consume them
independently, we did Three core interaction mode.
You can then help teams have more focused, interactions
understand when, and how they should interact with others,
instead of that kind of blurry, everyone.
Collaborates with everyone just to finalize.
We shouldn't expect this interaction, so long.
These three modes to always go perfectly and smoothly, there
will be issues and situations where we thought this was going
to take two weeks. It took two months.
Those are great opportunities to actually reflect on.
Why did it take so long? Was that something that wasn't
clear? Maybe we wanted to collaborate.
The one of the team's actually needs to be facilitated first to
improve their understanding of some domain.
Let's say about infrastructure as code.
They need to better understand it before they can collaborate
with another team that has more experience.
So that the actually makes sense to collaborate.
Otherwise the collaboration becomes a facilitating mode.
We're not saying that it's all going to go nice and smoothly,
but it provides a better framing to Actually learn.
And then understand when some interaction goes wrong or
awkward. How can we learn from that and
course, correct? So having all these knowledge
that we just discussed. I know that various teams are in
different stages. Some are more mature, some more
messy than the other so to speak.
So maybe one key takeaway from you among all these situation.
Of course, it's quite tough to Define.
What will be the key? Takeaway of key message that you
want to give to the listeners, hear?
What can they do in order to improve their team?
The Structural maybe the way of collaboration within their team
in order to become much better aligned to the team topologies.
Just one, I could be many up to you, looking back at our
conversation. I would say for engineering
managers, in general. Obviously, you have different
responsibilities and different organizations, but in general,
start by acknowledging this constraints that we talked about
like Conway's law, cognitive load.
Also trust boundaries that we didn't talk about, but the fact
that we are conditioned as Owens in certain ways and specifically
in software delivery. Also things like Conway's law.
So acknowledge that this constraints exist.
Often, we're focused on what are the good practices or best
practices? And what's the best way to do
things? Practices and principles are
obviously necessary and useful, but they should be informed by.
What are the constraints in the first place?
Constraints are usually things. We cannot really change.
So limits on cognitive load limits on trust between groups
of teams. Conway's law are things Cannot
really change. So we need to acknowledge them
and then build and decide on practices and principles based
on that. Because if we don't, then we
might be fighting these constraints rather than
understanding and leveraging them in our advantage.
So I would say that's the first thing, the other thing with Team
topologies. Hopefully, we're not just
clarifying the ways that teams can interact and their mission
of different types of teams. But also we're hopefully helping
teams become more motivated with feeling more autonomous that I
have more ownership of their service or the things they
provide and that they're becoming more competent.
So these are the key drivers of intrinsic motivation.
Daniel pink wrote about in his book drive.
So we think Tim topology is also helps teams, become more
autonomous have more ownership. And so the role of the
engineering manager, ideally starts to move away from
managing the team per se and and making decisions for the team to
actually making less decisions. Let the teams have more kind of
local decision-making and so if you're sort of getting Out of
the way of the teams, providing them what they need to become
more autonomous in terms of skills competences and support.
Then you can look more into how do we help even if we're a
manager of one team? How do we help this team?
Understand how to deal with other teams in a more productive
way? How we help this team.
Our team remove blocking dependencies on other teams.
That's not easy for a team that there's already quite busy with
their day-to-day work and their goals as a team.
It's I think we're managers can actually help a lot is start
helping address the blocking dependencies problem.
This is unfamiliar for many teams to deal with is, how do we
deal with this? We can apply the interaction
patterns. Let's have some collaboration so
that we don't depend on you anymore to do the deployments.
For example, how do we collaborate?
So we understand how to automate our own deployments.
For example, the managers can have a very strong I think input
on that helping team navigate their dependencies on others.
Can we actually Move or minimize blocking dependencies in
particular. And finally, one last thing.
Sorry, if it's too much, just one last thing is start.
Also thinking about alignment of purpose, between the team and
individuals with a fundamental types of teams.
We now have ability to be more clear on what is the mission of
this team of a streamline team is different from enabling team
or platform team. We have more clarity of.
Why does our team exists. What are we trying to achieve?
Who are customers, but then there's also the individual
All-purpose. Right.
Every person has their own individual goals and individual
motivation and often we don't consider the two together.
We think. Well, the team purpose and
everyone aligns to the team purpose again.
It's not really how things work people have their own goals and
what they want to achieve, we can Surface those conversations,
understand someone who is really focused on technical side and
the standing the technology and keeping up to date on that.
Maybe it's not a great fit for a streamline team where you want
more. He's shaped or more.
General is people that are actually more focused on
end-to-end delivery. So maybe that person is a better
fit for a platform or even perhaps enabling team.
And so helping understand what are the individual purpose and
how they align. Which types of teams often is a
mixed, where you need people to align their individual Purpose
with the team, but also be willing to learn and improve on
some areas that they don't have as much experience yet.
So even for platform, team, for example, you might have people
who are more focused on understanding the technology and
the technical side, but they still need to understand.
How do we deal with internal customers?
How do we get much better insights on what they need?
How our platform is helping or not getting metrics and getting
the right interactions with those teams in short, understand
your constraints, first. Get out of the way of teams as
much as possible. Let them make more decisions on
their own increase their autonomy and ownership help
teams deal with dependencies between them, especially
blocking the pain. Is help them navigate those and
hopefully minimize those so we can have faster flow and finally
help align individual purpose and in purpose.
Thanks for all the tips. So I know that we arrived to the
end of our conversation, but I have one last question that
normally I ask for all my guests which is called the tree
technical leadership wisdom. So maybe manual.
Can you share with the audience here?
What are your three technical leadership wisdom?
So it's basically what I just said, I think from a team
topologies perspective understanding In this
constraints that we have, then understanding that we'll be able
to achieve more productivity and more faster flow.
If we have teams with more autonomy.
And finally, if we help reduce dependencies between teams,
especially blocking dependencies, which again
involves a lot of the things we talked about understanding your
value streams. Understanding where is the wait
time, where are the dependencies the handovers of work between
teams that we might need to deal with.
And then how do we increase the skills of Our streamline teams
with enabling aspects and also reduce their cognitive load with
platform. So I would say those three
things, understand constraints, like Conway's law cognitive load
responder. He's looking for ways to improve
the autonomy and the ownership of the Streamline teams and
other types of teams. Help teams navigate sort of the
ecosystem and navigate and reduce blocking dependencies
between them. Thanks so much man.
Well, so for people who wants to follow you online.
Is there a place for them to follow you?
Yes, so there are two main places.
First. We have our website team
topologies.com. So in there, you can find new
industry examples and case studies that came out after the
book was published. The book was published late
2019. So since then, we've learned
also new patterns, and we have new examples.
So all of that is available at team topologies.com.
And then we have started an academy called team topologies
academy. So that's at academy.com
topologies.com., What we're trying to do is Have video based
on demand courses that help people learn about the key ideas
of topologies, sort of more condensed way.
So we have a first course called team topologies distilled and
then we'll be adding more courses where we bring our
latest insights around team topologies things that work.
Well, things that maybe in certain situations don't work as
well, and also new patterns that we find and new knowledge.
So that's all kind of come in the next months and years for
the Academy. So, thanks my love for you.
Time is really great to have a talk with you today, and thanks
for sharing your knowledge. Thank you very much.
Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please
share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It really, really helps me a lot in order to grow this podcast
better. You can also find the full show
notes of this conversation on the episode page at technology.
No, the death. Including the full transcript
interesting quotes, and links to the resources and mentions from
the conversation. And lastly make sure to
subscribe to the show's mailing list on pecola journal.
The deaf to get notified for any future episodes.
Stay tuned for the next technique Journal episode.
And until then. Goodbye.