Real World Serverless with theburningmonk

#66: Understanding team topologies with Nick Tune and Kacper Gunia

August 24, 2022 Yan Cui Season 1 Episode 66
Real World Serverless with theburningmonk
#66: Understanding team topologies with Nick Tune and Kacper Gunia
Show Notes Transcript

In this episode, I spoke with Nick Tune and Kacper Gunia to talk about Team Topologies, i.e. how to structure businesses and teams so that you can get stuff done faster. Companies often struggle to adopt modern software development practices and technologies because their team structures are misaligned with the practices they're trying to adopt. In this conversation, we will discuss what is team topologies, having the right incentives and funding models for teams, common anti-patterns, the problems with scrum and so much more! 

Links from the episode:

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

Want to step up your AWS game and learn how to build production-ready serverless applications? Check out my upcoming workshops and I will teach you everything I know.


Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Yan Cui: 00:12  

Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real world practitioners and get their stories from the trenches. Today, I'm joined by Kacper Gunia and Nick Tune. Hey guys, welcome to the show. 


Nick Tune: 00:26  

Hey, 


Kacper Gunia: 00:27  

Hello. 


Yan Cui: 00:28  

So today we're going to talk about something slightly differen. I guess a bit of tangent to what we normally focus on, which is serverless. But I think one of the things that I've seen a lot in the field is that a lot of clients try to adopt serverless but they struggle because they don't have the right team structure in place or the way of working in place. And this is something that Nick and Kacper has been working on for a while now around the team topology. So before we get into it, let's hear from Nick and the Kacper about who they are, what they do. 


Nick Tune: 00:57  

Hi Kacper, you want to go first?


Kacper Gunia: 00:58  

Sure. Thanks, Nick. Hello. So I mean, my name is Kacper. I'm an independent consultant for seven years now. And I focused and decided to, you know, orient my career around domain-driven design, which is a topic that's very close to my heart, so close that I even started domain-driven design meetup back in the day when I met Nick actually. He decided to present it in one of the first sessions we had. So that was a very lucky encounter from my perspective. And the reason I am here today is because I believe domain-driven design can help us to figure out how to structure our software so that it's more aligned with our development team. So we can actually achieve this fast flow that the team topology is talking about. And this is what I'm doing with my clients on daily basis. So we'll be more than happy to share my experience.


Nick Tune: 01:40  

All right. So I'm Nick Tune. I've got a background in software engineering. And two of the big influences for me and the start of my career, thanks to the people I worked with, were domain-driven design. So how to map out your business, how to design your software and architecture aligned to your business, and also continuous delivery and all the things that touches on. I just found it amazing when I worked with a company called 7Digital back in 2012, deploying to production on my first day with a single button click doing that every day. And everyone else is working in that way too. So I've always been really fascinated on I think the organizational aspects that enable that to happen. It's just not just about having CI/CD pipelines, whatever that phrase means these days. It's about having the practices like testing as well, testing, creating quality code, and also with domain-driven design, having the architecture set up in the right way. So that's kind of what led me to team topologies. I think that was the kind of missing thing before. We were always talking about how to set up your teams with domain-driven design and team topologies to achieve continuous delivery and deliver things faster. There wasn't really anything you could call that. We started using the word sociotechnical architecture, but then team topologies came along and kind of okay, that that fits the gap that was missing before, and adds a lot of new stuff as well that we weren't talking about. So I got into consulting about five years ago. I do a mixture of stuff nowadays, some longer-term stuff with one company and some shorter-term stuff like a series of workshOps here and there. So yeah, quite varied these days.


Yan Cui: 03:11  

Oh, 7Digital. So I've actually met quite a few people in my career from 7Digital. It was a really good place where you had a lot of good engineers coming from at least a .Net background worked at Just Eat. And I think a few of the really good engineers there were from 7Digital back in the day. So you know, good pedigree there, Nick.


Nick Tune: 03:29  

Yeah, for sure. It took me a while to get employed there actually. When I first tried to work there, they said, we don't think you're a good fit, but maybe in the future. So I just kept hassling because I knew the pedigree of people working there would be a good investment in my career. And it definitely was, yeah, working with those people just passionate about and the thing I learned there mostly is to be as passionate about the way you work as the work itself. So people love the products, but also how can we improve how we work a lot of learning during working time. And that was really just coming down from management. Everyone believed in that. That's just continuously improving everything about how we work.


Yan Cui: 04:04  

Yeah, I think the way we work is so important. I've met so many good engineers who failed at their jobs, they failed probably is the the wrong word, but they didn't achieve the level of success or outcome that they should have done because of the way the company has been set up does not allow them to succeed easily. There's so many forces that you have to push back against in order to do the right things that is going to help you and the team succeed. I guess it's where maybe you guys can start introduce us the idea of team topologies. And give us some concrete examples from the work that you've done.


Nick Tune: 04:37  

Okay, sure. I guess I'll go first this time then. And then Kacper, you can go next. So I guess firstly, on the theoretical side, team topologies. It kind of brings together a lot of those ideas that companies like 7Digital were doing before anyway, around having autonomous teams, small teams, like five to nine people owning areas of the business. The fast flow of work is something core to team topologies. And again, at 7Digital talking about deploying to production everyday, concept like you build it you run it, where the team owns the software, they have to deal with issues in production. And that improves reliability. So yeah, all of those things around a lot of the DevOps stuff, a lot of the continuous delivery stuff, a lot of the you build it you run it stuff. Team topologies puts all of that together. But it brings new concepts as well, like the concept of cognitive load, for example, introduces specific team types like streamline teams, platform teams, and also talks about interaction modes like x as a service, collaboration, facilitating, which we could get into later. I think it's a mixture of things that have been working for a while, plus, they bought some new concepts as well as I was talking about. And so in practice, I think from a consultants perspective, talking about those ideas before you should have smaller teams, you should allow teams to be you build it, you run, it should think about their cognitive load, not overloading them with too much work and too many responsibilities. Talking about those things before it was hard sometimes for like business people and leadership to understand those concepts, I would say. But nowadays, because team topologies is so popular, it's much easier to talk about those best practices and in terms of how we organize teams. So nowadays, if you go to an organization, and they've got big teams, for example, and they're working in a project-based way, you can talk about product-aligned, domain-aligned teams, smaller five to nine people, and straight away they're like, Oh, yeah, we read that in team topologies. That makes sense to us. So a lot of the things that took a long time before, a lot of the common basic, simple best practices before that took a long time to introduce into a company that's much easier now because team topologies has made those ideas mainstream.


Kacper Gunia: 06:43  

There is one thing that team topologies don't talk about. And that's a very crucial thing to making it work from my perspective is they give you all the principles and guidelines how to set up the teams, but they don't tell you how to align those things to your domains. All they say, okay, they should be aligned with the development value streams, but there is nothing there. And it's, it's fair, because it's outside of scope outside of the scope of the book to… because it's a massive topic. So this is basically where I feel like domain-driven design can contribute a lot. Because in domain-driven design, we talk about domains being aligned with the business with the development teams, with the software underlying underneath. So there is a lot of things that you need to do on top of team topologies just to be successful as well, from my perspective, and I think that's one of the challenges that organizations are seeing nowadays because it's easy enough to say, Okay, let's set up 20 five to nine people teams, and everything will be fine. But that's not the case unfortunately.


Yan Cui: 07:35  

I guess that's very similar to the discussion people had with microservices, right, that, we know, is the best good practice to have small services that can be can be written and quickly. But then how do you define where those boundaries lie, and you know how big a service could be become before you need to be split into smaller services, you have a very similar kind of problem in terms of aligning those technical functions with your business functions. And I guess I'm quite interested to hear some of the maybe anti-patterns that you guys have seen in terms of how companies started with this the right idea of using team topologies, buts maybe didn't quite get it right, and what are some of the things to look out for as a technical leader in the organization in terms of where can I maybe improve things? Where should I maybe step in to say, Okay, guys, this is not working, let's do something else instead?


Nick Tune: 08:28  

Yeah, there's a couple of anti-patterns I've seen around team topologies. And I think it's the same kind of anti-patterns you get with most concepts where people want to keep doing what they've done before and just put a new label on it. So the thing with one of the clients I worked with, they were keen on team topologies, there were various people in the organization, and there was some different perspectives on it. But the key thing about team topologies is, and this is what we talked about before we started working together. So I thought it was clear. It's that addressing the whole aspect of how your teams work, we're looking at you build it, you run it, we're looking at cognitive load to make sure teams aren't overloaded. We're looking at how teams are incentivized to make sure they're encouraged to work together and not as a bunch of individuals who have their own individual targets. We're looking at things like do teams have time to reflect on how they're working and improve it. So all of those aspects of a good healthy team needs to be addressed. But what happened with one of the clients is I'm not going to say which person in the organization it was, but it was someone senior who pulled a lot of the levers and they read the team's policies book, and it went from let's try and apply team topologies in one or two places. Let's try and do it properly in one or two teams and get make sure it fits for our organization and then spread it. That was the original idea, which I think is generally a good approach when you start with something new. Try and do its small area properly, and then scale that out. It turned into Can you just tell us how to organise our teams and we're going to do a big reorg after that. So that's one of the common anti-patterns trying to turn it into a big real or a very top down approach. And the problem with that is if you've got some organizational dysfunctions around how teams are incentivized if you're not addressing technical debt, and the architecture is not architected in a way that supports autonomous teams by doing a real, you probably going to make those things worse. If teams currently aren't collaborating effectively and if the current architecture is blocking teams from getting work done quickly, big reorg is going to exacerbate those problems. Team topology is about addressing all of those aspects of a team whereas a top down reorg is really just changing the structure and ignoring the humane and social aspects which team topology really focuses on. So I think that approach misses the key point of team topologies.


Yan Cui: 10:41  

So it's interesting that you mentioned incentives a couple of times there. And one of my all-time favorite quotes is from Charlie Munger, who was famously said that show me the incentives, and I'll show the outcome. Now I think starting from incentives is a really good way to arrive at the outcome that you want, in a similar way that people talk, I guess the last couple of years, people have been talking about the Inverse Conway Manoeuvre. And they're thinking about what type of software you want to build, and then structure your organization the way so that you can arrive at that outcome. And I guess so where is maybe perhaps missing in my head is, what are some of the good examples of building into the organization incentives that can encourage a better team building and team communication?


Kacper Gunia: 11:27  

I guess one of the things that we need to start with is really the funding model of the teams, right, because if the teams are funded in a way that they are getting patches for specific CRs to get them built and deployed, and so on, instead of continuously developing and improving the product that they're working on. That's the very crucial thing from my perspective because you if you have an incentive to continue to make something better, and you if you're rewarded for, I don't know, improving the north star metric, because you have them defined and whatnot, that's what the team can focus on. And at the end of the day, it really doesn't matter what type of software they build, as long as they achieve the business goals that are that the business set out for the team, where if it's opposite, and they need to, the team needs to ask every time okay, we would like to improve this aspect of the service, I don't know we want to improve the performance of this specific page query, whatever it is, doesn't really matter if they need to ask for permission to get things better. So I think is fundamentally broken from my perspective. So getting teams set up in a way that we have a stable, not static, but stable team, which means that team can benefit can perform and have say a constant throughput. And it can you know, sustainably work for a longer period of time that is founded. So we are getting the budget for the whole team and the team can decide on its own what’s the next best thing they can do to deliver on the business outcomes is the ideal scenario from my perspective. And that's what I'm pushing for, with my clients whenever we were working together, and any like, you know, micromanaging and accounting of every single feature is a big red flag for me.


Nick Tune: 12:53  

Yeah, I would say two things came to my mind, as you were talking there Kacper, funding model, definitely agree on that one. One of the clients I worked with, we're building an internal platform. And there were three verticals that would be using a platform, but the platform team didn't have their own budget. They would only get money to build exactly what the vertical teams would want it to build. So that team didn't have the budget to invest in fixing legacy, designing for the future, shaping their own roadmap. They could only build exactly what they were asked for, they would only get the budget to do that. So they had no autonomy there. And the second thing that came to my mind is when the incentives are encouraging teams to go in different directions, but there's a dependency between them. So the worst example I've got of this was a German company back in 2018. So we had a workshop to map out their domain and identify their domains and subdomains and how the teams can be organised around that. And then on the second day, we looked at, well, let's look at where you are now and how you're going to get there. And basically, they wanted to have all these independent autonomous teams with their own backlogs. And then we started looking at the existing system. And it was a 10 to 15 year old monolith with 10,000 business rules. And it's like you can never have 10 teams all working in there with their own roadmap because everything is so tightly coupled both the code and the infrastructure that whenever any team tries to implement a feature or deploy, it's going to have impact on other teams. So I think going back to the incentives, you can't incentivize teams to work independently towards their own goals when there's a lot of coupling in the software that makes it hard to do that. So I think in that situation, it's about incentivizing decoupling of the architecture and fixing that over long term. But also it's about incentivizing cooperation, where if it's not going to be possible for multiple teams all to have their own targets and work for their own backlog, company has to prioritize which is the most important. And for some teams, their job will be supporting other teams rather than achieving their own particular targets. And that needs to be incentivized. Yeah. And so just to finish off, I would say that the anti-pattern there is when you've got a lot of coupling and management just think every team is independent and can have their own priorities and the coupling is ignored.


Kacper Gunia: 15:02  

A fantastic example we’ve seen recently on Twitter was Stripe, I believe, where they set up a developer experience team that their sole incentive was to make other developers live better, where they actually had time and space to work on issues that no one else otherwise would, right? Because in the reality there is always competing priorities from the business and whatnot. And they called, I think, this term called paper cuts where whenever something was going not suboptimal for developers, they were just able to quickly send a single note, send notification about this so someone can look at that. I think that's, you know, a perfect way of, you know, setting, setting up a team that's facilitating team that helps other team to become productive and actually achieve this team topology setup that we are talking about. 


Nick Tune: 15:49  

Yeah. And just to add one thing to that, that's really a core concept in team topologies. There's the concept of a platform team. The goal of the platform team is to support streamline teams who use that platform. So from a team topologies perspective, a platform team has to be incentivized to support the needs of its internal customers. Very often what happens is the platform is basically the old operations team rebranded and so a good example of following good incentives is that the streamline team, they can use a platform in a self-service way. Whereas when the incentives aren't really aligned around the needs of those vertical teams, it just becomes the old way rebranded, so you create a ticket for the SysOps team, they'll go away and work on it. And then at some point, they'll get back to you. So yeah, in team topologies, when you've got a platform, a key incentive there is to incentivize the platform team to improve the developer experience of the streamline teams as much as possible, very often that self-service. I worked in one organization, and Matthew Skelton from team topologies came in. And he explained his concepts. And the head of IT operations said that will never work here, the operations people will not see the developers as these people who they're here to please. The operations people have always locked down the system to have the keys to production and treating the developers like children. To change that mindset, it's not going to work here.


Yan Cui: 17:06  

Yeah, that sadly a very familiar story of gatekeeping. And unfortunately, that often ended in the heartbreak and failure for the whole company. And I think this talk of incentives, but also payment models, I guess that for these different teams, also brings up a very interesting question, because, or maybe observation is that I've seen a lot of these platform teams, their budget, how they measure the success of this department is how many tickets they process, whereas based on what you said, they should be rewarded for fewer tickets created because developers are not having to create tickets because they have run into problems because everything hopefully should just be self-service so that everyone is happy, whereas if you incentivize for, you know, rewarding people for doing more work, because they're processing more tickets, then you're incentivizing creating friction that causes developers to create tickets to complain about something. That's a really interesting thing that I've seen in the past where companies that says, Okay, this is work that needs to be done, so if you do more work so we reward you for doing more work. Actually they got the wrong way around.


Nick Tune: 18:08  

Yeah, for sure. I've had this conversation with a couple of IT Ops leaders a few times. And the question always comes back to why aren't you rewarding people to solve less tickets. And it's just a case of, I can't get them to do that. I wish they would do more of it, but I can't get them to do that. And it's just the whole mindset of that should be the most important thing, like not an extra, just really living that idea of Yeah, how can we make the tickets go away. But people still have that old mindset, you know, I'm talking about companies where the operations team is measured on number of tickets. And the test is measured on number of tests, that kind of mindset, where how can we… the developers weren't measured on lines of code, it wasn't that bad. But for the testers in the Ops people, yes, still very, very bizarre way of measuring productivity.


Kacper Gunia: 18:52  

And have a good example here of how we managed to, you know, step back from this mentality with one of the clients. So there was an existing ticketing system through which the support was provided to the to the business people. What we said as a team at the time is that we're not going to use it at all, we just, we're just not going to use it. And whenever there is an issue, we just asked these people that have issues to send a message on a shared team's channel where everyone can see it, and everyone can support it. And there was, of course, a person that was responsible for support, but all of a sudden, the whole dynamic changed, right? It wasn't a ticket sent somewhere and that was going into a void and was lost for two weeks. And it wasn't being worked on. Suddenly it became a conversation where one person was looking at it and the other Oh, I have something to contribute here. Let's work on this quickly. Or they maybe are already working on that. But the person on support didn't know that, and so on. So it already shifted, you know, the mindset and actually showed our customers that okay, we do care, we can we can solve those things. And you know, it's not not that, you know, they can, they can send those tickets and they will never be worked on or they will see some result in two weeks. Things started to be to be solved and I don't know, an hour, two hours, three hours and so on.


Yan Cui: 20:00  

Yeah, it's funny how a small thing like this can help you to humanise the other side if you like. I remember like back in the day when I was doing a lot of on call stuff. And one of the things that I feel my CTO at a time told me was, it's really important for us not to send those pager duty messages or alert emails out from like someone's personal email, it shouldn’t show someone's name because otherwise it kind of demonizes that person as the person who's always paging me at 3 am when something goes wrong, you know, why is he always paging me and calling me? Whereas if it comes from more of a system, email system, phone number, then they kind of help protect the human that's setting up those systems and sending out those alerts to people to tell them, hey, something's wrong. Please take a look, even though it's 3 am in the morning.


Nick Tune: 20:48  

Yeah, I've got an example. One of those organizations I mentioned where the Devs and the Ops didn't have a great relationship, just having joint retrospectives. The team was transitioning to a platform team that didn't really see the developers as their customers yet, the developers were getting really annoyed with the Ops team, the platform team. It wasn't a healthy relationship. We had a couple of teams who were building the first services on the new platform, and serverless services. And we just decided, why don't we run a joint retrospective across the development teams and the Ops team, see how that worked. And it worked really well. And we also had mobbing sessions, where the development team would call in the Ops team, and they would all be together on a zoom call fixing stuff, figuring out stuff. So yeah, that definitely has a big impact, I would say on the social aspect.


Yan Cui: 21:30  

And would you say that, in some ways, is very similar to Google's SRE model, where instead of having a separate decoupled Ops team, they have Ops team, well, SRE team essentially is a pool of resources that can be embedded into application or development teams to help them both upskill but also understand their software from the operational perspective and not just, you know, writing clean code and putting out there, but also thinking actively thinking about what are the things that could go wrong, and what sort of process we should put in place in order to fix those issues when they do come up.


Nick Tune: 22:07  

I've seen the SRE as an enabling team in team topologies concepts, which is effectively their coaches where they move around and help other teams to improve their Ops and their SRE practices. I think, in general, it can be a good idea, obviously, will depend a lot on the company and the individual people involved. You know, I often think that is mostly about the people involved, rather than the actual approach you're taking. I think good people will figure out the right way to work together, whether you call it DevOps, SRE. But obviously, those things do have specific ways of working that have an impact on the pattern. But I think with that approach as well, sometimes because those teams don't have authority, it can be hard for them sometimes to get those practices across, like the SRE team is trying to work with these teams, but they're not really open to what they're saying.


Yan Cui: 22:52  

Okay, so I guess here's an interesting question then. So if the key is having the right people in place, but at the same time, I've seen good people failing in organizations, because the structure doesn't allow them to do what they need to do. So would you say that it's a good argument for someone like, say, a CTO in a company to just get out of the way and have process to hire the right people in and just let them figure out how to do things because when I read about recently, I think was from the Gergely who been running the programmatic engineering newsletter, one of the things he talked about recently is how those big tech companies, they don't use Scrum. They don't have any fixed methodology. They just let individual teams figure out how to work. And obviously it took lots of effort into hiring the right people in the first place. But then they kind of just feels like, Oh, we're just gonna step out, we're gonna step away and let you guys figure it out how you like to work, and different teams will adopt different methodologies based on how they like to work.


Nick Tune: 23:47  

Yeah, well, I'll just say one thing, and then I'll hand over to Kacper just to finish, to go back on that. I would say you're right, having the right people is key. But if they don't have the autonomy to make changes, and change how we work, then the bad system will beat the good people. 


Kacper Gunia: 24:04  

Yeah, I think, yeah, what you said really hits home from my perspective, I've seen countless number of times where projects or products or whatever new initiatives get are being kicked off in a way that first who are we going to hire first, oh, we are going to hire a manager and manager comes in imposes a process. And there isn't even a team to implement the software, but there's already a process that is going to be followed, right? And that's, that's really wrong from my perspective. So really, the best teams I've seen in my life, figured out the process on their own, and were really guided by the outcomes and the value provided for their business. And their VP of product that I'm working for at the moment, shared with me a story when he went to Microsoft to Redmond, I think 20 years ago or so, to… I think that was a business trip. It doesn't really matter. But he’ve seen how they worked in Microsoft back in the day and basically he told me, you know, there were two types of roles in the organization, developers and everyone else was trying to make sure developers are productive and happy, right? That's how they worked. Like if they needed the machines, someone was ordering new machines. If they needed, I don't know, snacks or needed to go for lunch break or whatever. Somone just figured it out. And the team was just focused on doing the work that managing some safe processes as we see it nowadays, you know, to reflect on that, I know, we're lucky at the moment because I work with him with that person. And he understands that and he just gets out of the way. And that's amazing.


Yan Cui: 25:27  

And this actually reminds me of a conversation that's been showing up recently. I was watching at Dave Farley’s conversation with Allen Holub who famously said that you know, don't do estimate, I mean, like just at all. He’s he's obviously come out very strongly against a lot of the things that we call agile today because when agile first came out, it was just Agile Manifesto. It was a couple of very small high-level principles that doesn't really matter how you implement it. It’s about improving those human communications. But as time has went by these have been replaced with scrums, replaced with Kanban, several pretty fixed and rigid ideas in terms of what is agile to the point that I think Allen was saying how a lot of people just decided to sidestep this whole agile name altogether, even the original signature for the Agile Manifesto. And one of the things that you mentioned earlier, Nick, was about how do you make sure people are not overloaded cognitively. And one of the things you see a lot with teams that practice Scrum is this whole idea of Okay, now we have a number of points and we trying to estimate effort based on points. And then as you improve teams show improvement because you can take on more points, then you kind of get to the point that you're optimising for maximum use your people's time, rather than keeping them at least maybe twenty, thirty percent of free time, so that they can actually handle any issues they didn't foresee at the start of a sprint. Problem come up, that's going to take someone's attention. And that's going to take them away from doing whatever work that you plan for a Sprint. What are some of the ways that you find the organizations being able to do this better so that they're not overloading the developers and, well, the whole team cognitively?


Nick Tune: 27:08  

I would say, going all the way back to when I worked at 7Digital, it was just a case of the team pulling the amount of work they could handle pretty much on a daily basis, you turn up in the morning, you've got your Kanban board, you've got a whip limit of like two or three items. And if there's if a piece of work moves into the next column, you can put one into this column. So the system's got a built-in buffer of how much work the team can handle and how much cognitive load the team can handle. So it's pretty much up to the team. And I think it's really a bigger conversation around trust. If you know your team's working in a good way, then whatever they get done is the maximum they could have gotten done anyway. So you don't need to measure them or control them. So I think a lot of those measures are really, in organizations that don't trust teams, where I was at 7Digital, and managers would come around, they would see the teams pairing deploying to production every day. And they knew they were getting maximum productivity out of these people. So they didn't need to put in controls or measurements to check how well they were working.


Kacper Gunia: 28:05  

On the overloading, I one thing that I would like to add is also whenever a team commits to something from my perspective is a team commitment, not individual commitment. And I think that's, that's a big part of, you know, having great incentives in place, and making sure that people are there to help each other. Because if we committed to deliver something as a team, it's everyone's job to do that. And it's not like if a person is struggling with A and I’m working with B I cannot help them because I committee to something else, right? It doesn't just doesn't exist as an incentive to you know, just deliver as individual. So I think that's also very important to make sure that you just don't have a work group and individuals that are, you know, delivering on their own, they're delivering as a team and each team that delivers our team that fails because that also can happen, right? But what makes sense is, you know, reducing the work in progress and making sure that you're working on the most valuable next thing is key. But that requires a lot of trust from the organization. And I also think that's why these big reorg is fail, because you know, starting small, setting up those teams, building this trust takes time. And it's not like you can just tell people, okay, this is the new org chart from tomorrow, you work using these principles, and everything will be fine.


Yan Cui: 29:14  

Yeah, I think this whole…well like you said, a lot of it's down to trust. And I'd also have got this thing up against this tendency or this obsession to measure productivity, because productivity doesn't mean outcome, when you can be very busy, very productive, but still not move the needle a tiny bit for your business. And the worst thing is that when you've got different teams, you often see that one team will have far more impact for the company as a whole positive impact. But they depend on other teams who's incentivized to do their thing, even if whatever they're doing is far less important and far less beneficial for the company. But they've got their sprint targets and the other team have to wait four weeks to get a tiny small change in the config so that they can do their bit even though their bid is going to generate far more revenue and far more users and far more impressions or whatever for a company. I think this is something that's really difficult to sort of tackle at the organization level, as you said, Nick. If we just measure individual teams as if they are silos. But I guess I haven't seen too many examples of companies who are able to find a solution for this problem. Have you guys seen anything in your work?


Nick Tune: 30:22  

I think that's where things get difficult. I think is quite easy if you've got the right people to have individual teams that are performing well, creating good code, focusing on the highest priority in their backlog, deploying to production multiple times per day. But when you start moving up to flight level two, and you're trying to coordinate multiple teams, you've got multiple incentives, maybe the company has multiple projects. And yeah, it gets very difficult and I don't think that is an easy problem to solve. I think you know, the first thing is company has to have a clear sense of priorities. If you're telling every team what you're working on is the number one priority, and they all think their work is the most important. I think that's one of the things to get over. I think techniques from domain-driven design can help a lot when you start doing event storming, looking at core domains, helping people to see that bigger picture is quite useful, bringing them together in those collaborative sessions, thinking beyond their team, and looking at other parts of the business that maybe they should know more about, or they don't know more about, or for whatever reason, they haven't spoken to those teams that they should be working with before. So I think a lot of those practices can help. So a combination of things to summarise, I think having clear priorities when your priority is not the top priority for the company, being incentivized to help other teams rather than achieve your own goals. And thirdly, having those collaborative sessions and workshops and people come together to talk about things outside of their team, particularly event storming where you get into the details of the whole business flow. Those are three things that can help a lot.


Yan Cui: 31:47  

Right. So I guess that brings back what you mentioned earlier, so incentives, right? So that if people, bonuses, and pay rises, all of that is tied to how much they produce as opposed to how much they’re able to help the company as a whole then, of course, he was going to prioritize their own priorities versus helping some other teams because they're not financially incentivized to make that sacrifice. Maybe potentially, this is something where having like technical program managers which I've seen exist in some of the bigger tech companies that coordinate across multiple teams where you got bigger projects that require multiple teams. Maybe those are the guys that can then come in and say, team number one, I know you guys got your own Sprint planned out, but you should spend more time helping out with team number two, because right now what they're working on has the higher priority from the company's point of view. Because I think in a larger company, it's just really hard to for everyone to see everything that's going on and understand the value proposition that your work has versus somebody else's work.


Nick Tune: 32:50  

Yeah, I think there's an element of self-organization I was talking about before when you apply techniques like event storming and bring teams together to help them see the bigger picture but I do feel like in large organizations, there is a place for dedicated roles of people who are looking across multiple teams or multiple streams of work and connecting all together. I would say my experience that's normally a delivery manager and the role of delivery manager. I haven't seen a TPM role that much although I've heard of it.


Yan Cui: 33:16  

Okay, I think that covers all the questions that I had in my mind. Do you guys have anything else that you'd like to mention before we go? Anything that you're working on, any sort of, you know, books or stuff workshop that you're planning?


Kacper Gunia: 33:28  

I guess we can mention the training that we developed recently for team topologies with Nick, which is talking about joining domain-driven design in the context of designing and developing the value streams. So we talk about techniques from dimensional design, such as event storming and core domain charts, and independent services who use heuristics from team topologies. Based on our years of experience, we explain how we would approach designing or redesigning an organization that would like to go and implement this model. Hopefully, if someone is planning your journey like that, that can be a good reference and you know, a nice shortcut where you can watch two hours of videos and pick up useful experience.


Nick Tune: 34:09  

That was the first video training I've ever done. It's not easy to record video training. One small mistake, it’s like cuts, got to redo that take again has to be perfect. Yeah, looking at all the videos that came out. I think it’s quite good. I'm happy with the content. I would say yeah if you're looking to move to team topologies and you're looking at how to organise teams so they can be autonomous and focused on the product. In that video training, we've basically shared the techniques we use so I think it's quite authentic and genuine not trying to oversell stuff or sell any frameworks and things like that. A lot of the stuff we talked about in this podcast today that kind of thing. I probably also mentioned London DDD Meetup. If anyone wants to come to that anytime or if anyone wants to speak at that, or run a workshop at that some evening in London, always happy to hear from people.


Yan Cui: 34:56  

Okay, I'll leave links to the workshop that you just mentioned, as well as to the London DDD Meetup group in the show notes. So anyone who's interested can also I guess reach out to Nick and Kacper to find out a bit more. 


Nick Tune:  35:07  

Thank you. 


Yan Cui: 35:08 

Thank you guys so much for your time today and hope to see you guys in person in London soon.


Nick Tune: 35:13  

Likewise. Thank you.


Yan Cui: 35:15  

Cheers. Ok. Bye bye.


Yan Cui: 35:28  

So that's it for another episode of Real World Serverless. To access the show notes, please go to realworldserverless.com. If you want to learn how to build production-ready serverless applications, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time.