Getting into machine learning, and Team Topologies
It already recording?
Ian:Hello, Ash.
Ash:Hello, Ian.
Ian:We're here again.
Ash:We're here again. Why are we here?
Ian:Apparently, we're gonna record a podcast.
Ash:Let's do it.
Ian:Before we do, great news.
Ash:What's your great news, Ian?
Ian:Well, remember last time when we recorded the first podcast and we said, if you have an opinion about this, then get in touch with us on, well, now the era of and is over.
Ash:Not entirely.
Ian:Not entirely. But you can get in touch with us now. We have an email address, whatalotofthings@gmail.com.
Ash:Sweet.
Ian:And we have a Twitter account, which annoyingly is what a lot of thing because that final s was a letter too far for Twitter.
Ash:Too much. Always too much. Always breaking breaking boundaries and limits.
Ian:Yeah. I mean, that's that's why we're here. Yeah. And we've also got an Instagram account. I mean, steady on.
Ian:Try, you know, try not to get over excited about the Instagram account, but it does mean that we are part of the cool kids.
Ash:Yeah. I've literally never had that label attached to me ever in my life.
Ian:No. Nor have I. But, you know, we can aspire. Yeah. So, yes.
Ian:Maybe we should take a picture of us recording this, and then we can put it on our Instagram. Oh.
Ash:You can see us in our natural habitat.
Ian:I'm gonna take a picture of you now.
Ash:Okay. Most of me will be obscured by the pot filter and the cans. Yeah. Do you guys call them cans?
Ian:It's so cool that you call them cans.
Ash:Is is that is that actually cool, or is that just some kind of thing that I think is cool? Although I suppose that's what the nature of cool is, isn't it? You know?
Ian:Well, I think the nature of cool is that other people think it's cool. I don't wanna belabor the point or anything.
Ash:So that's why I'm not cool. Okay. I understand now.
Ian:Well, now you can add podcaster onto your, onto your business cards. Yeah. People will say, wow. That's amazing. You're so cool.
Ash:Just need to get some business cards.
Ian:Yeah. Then you can write that on
Ash:them. Okay.
Ian:Cool. So as ever, we have things.
Ash:We do have things. We each have a thing that we want to talk about. Yeah. And Ian's gonna start us off. So, Ian, what's your thing for this episode?
Ian:Well, I'm glad you asked me that. You'd think it was almost staged, wouldn't you?
Ash:Yeah. Yeah. So my
Ian:thing this week comes from or is inspired by Arthur c Clark's third law. So he was a sci fi author and possibly came at it from that direction. But his third law was that any sufficiently advanced technology is indistinguishable from magic, and I love that because actually in some areas of life our technology is getting a bit closer to that kind of threshold of of being magic, and particularly I feel that machine learning and AI, as I don't like to call it, but that area is one in which the IT professionals, they don't think it's magic. They know it's not. They know it's computers and CPUs and stuff like that.
Ian:But in some ways, they behave around it as they would if it was magic.
Ash:Yeah. Yeah. It does depend on who's looking. Mhmm. Because in the wider consumers of services, you kind of look like within your own families to those who aren't in the technology area.
Ash:And you do even the the the simple things that we, you know, we consider simple, we understand the constituent parts of them. You know, like, having a mobile phone Yeah. Is a classic example. And lots and lots of people, they will use them, but they don't understand what's happening within them, or how an app is structured, for example. It could look like something like magic, something like, well, you know, you turned something that was previously complex and required lots of storage and lots of different parts to it into something as simple as, you know, tapping on an app and doing a thing.
Ash:Yeah. But I think with any sort of sufficiently new technology as well, you always start off with a a limited set of people who are implementing that and really embracing it, you know, along the the sort of early adopters if you like. So I think there's something to do with once it becomes more widely used or widely implemented, then it becomes a bit less like magic, do you think?
Ian:Well, yes. Yes and no. I think that one of the contributing factors with this particular technology is the way that it it isn't like it's achieving results that you could maybe achieve by writing some code. Yeah. But, actually, it's beyond realistic complexity that you'd need to do it.
Ian:So if someone said write some code to identify tomatoes in a picture of a bunch of vegetables, pick out the tomatoes. If you had to write that in a normal kind of procedural way, it would be impossibly complex to kind of decide where to start and how to do that. Yeah. Whereas the machine learning way of doing that of supplying a lot of pictures with labeled tomatoes to a model to train it and then asking it that's that's very different And I guess it feels magical. And even people who really know what they're doing in this area can't always look into that model and and point out which bit of it is working.
Ian:There's a whole area of trying to figure out why machine learning models made particular decisions and trying to to make that more transparent because it it really is. I think it it it genuinely is a black box that a vanishingly small number of people really understand why it gives the good results it does.
Ash:Yeah. All the bad results, all the unexpected results, or whatever they are. Yeah. Do you think that the limitations of it will be exposed more as more people start?
Ian:Oh, yeah. I mean, I think the limitations of it are showing already. Yeah. I mean, everyone talks to Siri or talks to that other thing whose name I can't mention because it would wake up and try and join in with the conversation. Let's just say that Amazon made it.
Ian:But people regularly talk to these things and it they mishear them or they get the words wrong. I don't know if you've ever seen that YouTube video of two, Glaswegians in a Lyft, a voice controlled Lyft. I'll find it and put a link to it in the notes because it's very funny, but it kind of shows up the limitations of of voice recognition quite effectively.
Ash:Yeah. Yeah. And I think there's part of this is also about what we consider to be AI as well and what it can actually achieve because, like, machine learning is a subset of artificial intelligence. You know?
Ian:Well, so yeah. Sort of. I mean, when people talk about AI in the industry, I think that there's they talk about two main kind of camps of it, if you like. Yeah. And one of those is strong AI, which is also known as AGI, which stands for artificial general intelligence.
Ian:And it's basically referring to an an artificially created consciousness, a machine that has sentience that can deal with generalized situations in the same way that we do.
Ash:Like terminate?
Ian:Well, yes. Very like Terminators. Mhmm. Although, I think it would be safe to point out that the Terminator solution to many problems is to shoot
Ash:All problems.
Ian:So perhaps more general than that. But, no, I mean, you're absolutely right that the Terminator would be an example of an AGI along with Arthur c Clarke's Hal 9,000.
Ash:Also enjoys killing.
Ian:Well, yes. Although in a slightly guilty way. And, knows how to sing Daisy Daisy, which is, you know, obviously a very important skill.
Ash:I'm sorry, Dave.
Ian:Not as important as being able to identify cat pictures on the Internet.
Ash:That is true.
Ian:Quite important.
Ash:That is true.
Ian:But that kind of AI, which you can actually really call AI with a clear conscience, doesn't really exist at the moment. And people are talking about, oh, is it gonna be ten years' time or fifty years' time? But that's the kind of order. They're not saying, is it gonna be in 02/2022 or something like that? I guess when people in posterity are listening to our words of wisdom in, fifty years' time or other probably AIs will be listening to our wisdom in fifty years' time and mocking us.
Ash:Yeah. So these two really didn't understand what we were all about.
Ian:Yeah. Yeah. But, you know, that's a fair way off. So what we have today is more described as narrow AI or weak AI,
Ash:which
Ian:I always feel is a bit harsh. Because actually, it you we are getting some quite amazing results with it. You know, we can identify a tomato in a basket of vegetables. We can take pictures of, fish tank and count the fish in it without a person having to do it. Yeah.
Ian:We can even drive a car on a motorway or a freeway safely, probably more safely than a human. So
Ash:Definitely.
Ian:I think it's a bit harsh to call it weak AI because it is able to do things that are very, you know, very impressive and that maybe we wouldn't have been able to do using computers five, ten years ago Yeah. Even. So when people talk about AI, they might be referring to HAL 9,000. They might be referring to their Tesla. Yeah.
Ian:And then when people talk about machine learning, they probably aren't talking about HAL 9,000. So in that sense, I think your characterization is right that machine learning is probably smaller thing than AI. But machine learning has got different sides to it as well. So the sort of miracle stuff that we're seeing at the moment, the things that we think are magic, the image recognition, self driving cars, the generative adversarial networks that are creating pictures of people out of out of nothing, people who've never lived, People are using for art projects, which is really, really interesting. All of that is really centered around something called deep learning.
Ash:Okay.
Ian:And that's the, AI with the giant datasets that predicts what ads we will buy things from if we see them. All of those kind of technologies, that's deep learning, which is a particular machine learning approach. But there are lots of other approaches and algorithms in machine learning that work on much smaller data sets where you can get benefits and make predictions of a thousand rows, not 10 or a hundred million.
Ash:Yeah. So I guess that's like trying to learn those those composite parts and all the what goes into creating one of those models. Because you can do that, like, say, with a smaller data set. Yeah. As long as you have, you know, the right problem and then the right way to start.
Ash:And then you can start to use the various algorithms to to explore data much more. So where would you go to get started?
Ian:Well, I mean, if you wanna start small, it's actually really relatively simple. I did a couple of courses, actually, and I did them backwards. I'd the the they're both on Coursera, and I'll put links to them because they were both brilliant, actually. The first course that I did was, on deep learning, and that kind of made my brain hurt a bit. There was some there was some maths in it early on where I thought, oh, I didn't think I was gonna have to think about this ever again in my life, but I thought, well, plug on through.
Ian:And by the end, I was able to, you know, I was writing cat recognizer that could, take some pictures of cats and then say whether another picture, a different picture was was a cat.
Ash:So the purpose of the Internet.
Ian:Yes. Exactly. The foundational technology of machine learning, identifying cat pictures. And, you know, using TensorFlow and Keras and other high profile AI kind of frameworks and libraries. And it was brilliant.
Ian:I absolutely found it fascinating, and I think it was a really good thing to do. But then I went on and did another Coursera thing called applied data science with Python. There's a link to that as well. And in that one, I learned actually a lot of things that would have been really nice to know when I did the deep learning. Right.
Ian:So I learned about algorithms such as random forests and extreme gradient boosting and naive Bayes algorithms, all these kind of things that are machine learning algorithms that are really, in many ways, simpler than deep learning and will operate on smaller data sets. But you can still learn stuff and make really quite interesting predictions with them. And that course also covered things like visualization, so how to how to visualize data in a way that's beautiful and and informative. And it covered, data manipulation in in Python using Pandas, which is an amazing library. It's like having a sort of relational database in memory inside your Python code, and it's so easy to use.
Ian:It's just absolutely fabulous. So I learned a lot from both of those. I think I do them the other way around now. But the Yeah. The big big revelation to me was Kaggle.
Ash:Kaggle.
Ian:Which is spelled k a double g l e. And, I suppose I'm probably redundant in saying, yes, we will include a link to it in the notes. But Kaggle is a a data science playground where a lot of companies who have data science problems or machine learning problems will post datasets often anonymized, which you can use to build models, and then they evaluate those models on bits of data that they've held back from the datasets Yeah. And give you a score. There's also some very good starter kind of competitions and my favourite one is probably the one that people get directed to first when they're just learning and that is around the Titanic because most people have heard of that.
Ian:I've told there's a film. I've never seen it. But there are a lot of knowledge. People are familiar with that. And what they've done is they've take they give you about 1,300 rows of data about, about each passenger with things like what how many family members were they travelling with, what cabin were they in, if that was known, what their age, gender, all this kind of stuff is provided.
Ian:And for most of the rows, they've also provided a flag that says, did they survive or not? But for the and then they've kept back a chunk of data where they've they've got the same data, but they've omitted the survival. So the survival is a null in that data. And what you have to do is you have to build a model that can predict the the survival results for those held back rows.
Ash:Right. Okay.
Ian:You create predictions, upload them to Kaggle, and Kaggle tells you how well you did, what percentage you got right, and you're scored on a leader board. So you can see how your model did against other people's.
Ash:Right.
Ian:And it's really not that hard to get into it. It's not huge data. And there are lots of example notebooks where you can see other people's code and the approach they took. So as a way of getting into this and learning about it, it's really accessible and really interesting. Yeah.
Ian:So if anyone's listening to this and they're thinking, oh, that you know machine learning that's that's too hard. Actually, you might like to start thinking about looking at that as a way of of getting started. Just get that data, have a go.
Ash:Yeah. Because it sounds really relatable because it's a it's an event and a domain, if you like, that people know about and most of us have heard of the Titanic disaster. And I think one of the things that I really liked about it as well is is that you could you could apply your interpretation of the situation and the event and come up with different ways of looking at the data. So it goes beyond just taking a particular field, age or, gender or whatever it is, and just applying different models to, different algorithms to it. It's more like how do you interpret that data as well, and then how do the models complement that?
Ian:Yeah. And a lot of the work that data scientists do is actually that feature engineering, it's called. And a feature is really a column of data. But rather than just basing the, model on the features on the columns that you get in the data set to begin with, you can combine that in interesting ways, maybe with other data sets. Not so much in this case, but certainly other knowledge about what happened.
Ian:So one hypothesis that I, made was if other members of your family survived, it was more likely that you survived. That was my hypothesis. And if no other members of your family survived, it was unlikely that you survived. Yeah. And so all the information you need to be able to check that out is in the dataset.
Ian:So that kind of thing, taking what you know about the world that your model doesn't have data in it that says that explicitly means that you can maybe engineer new features that are perhaps more predictive than the ones that are natively just there in the dataset.
Ash:Yeah. And I think it shows the combination of data and your knowledge and the heuristics that you use for life and applying those to that data. And it's not, you know, it might be called a data science, but it's not merely about the data itself. It's about, like, what you do with it and what you can infer from it. So I find that really interesting.
Ian:Yeah. I I must admit, I sort of smiled to myself a bit because I don't know how it became called data science, but it feels to me that there's at least, something of an art about it. And I appreciate that as well because I guess it shows that we're not redundant yet. You know?
Ash:Oh, yeah. Just wait for the Terminators. Okay?
Ian:Okay. Sure I'll be, be low on their list.
Ash:I, for one, welcome our new Terminator overlords.
Ian:Cool. So I guess that's my thing.
Ash:Your thing?
Ian:So, Ash, what's your thing?
Ash:Well, I went on a training course a few weeks ago for something called Team Topologies with a, a friend called Matthew Skelton. It was held in Leeds. We've worked on quite a few things together in the past. So, I was really looking forward to going on this. So essentially, what it's about is it's like a set of principles for building the teams in your organization, or at least kind of mapping them out, structuring them if you like.
Ash:Mostly based on something called Conway's Law, which essentially says that the systems that you build will be replications of the communication structures within your organization. So I guess the the main example is, say if you've got a very large team of database analysts
Ian:Mhmm.
Ash:They're probably gonna build you one or maybe two very large databases for your applications to speak to. So that's kind of one of the big principles within this training. So I'm sure we've run into that before. Yeah. And they also talk about doing, like, like an inverse Conway's Law, where I say if you do have that single database analyst team with a large database, if you structure your teams to take the to to break up that database team and have, like, say, one database analyst within each feature team, then you will get a smaller database eventually.
Ash:So that's like the reverse Conway's Law maneuver, I believe it's called, which is kind of interesting. So So I don't know, Ian, how do you feel about, like, the relationship between architectures, if you like, and how your teams are structured?
Ian:Well, I guess I first I remember reading about this in the DevOps handbook, actually being quite struck by it. I mean, I'm talking really about Conway's Law. Yeah. And I was struck by it because at the time I first read that, I was kind of involved with a project that was doing the exact that was the exact perfect model for it. I guess my question now is that Conway's Law has been around for, I'm gonna say, a while.
Ian:Yeah. So what's the new thing that is part of this topic of team topologies that kind of is building on that?
Ash:Yeah. So Matthew and and Manuel Perez, the other the other sort of co creator of this, have kind of used all their experience to say, well, what types of teams are there? And they came up with and how do they interact with each other? So they came up with four types of team. So the first one is they're called a stream aligned team.
Ash:So you could imagine that as something that's aligned with how your business delivers value. So it might be you might have an account team who deal with a person's profile and all their settings and how they authenticate, and then a subscription team which looks at how they consume certain services from whatever your service is.
Ian:But that's that's a team that's aligned with a particular subsection subsystem of your of your system that basically are responsible for developing, testing, running
Ash:Yeah. That sort of. Yeah. So they have that as so they're the kind of delivery teams, if you like.
Ian:Sure.
Ash:It's hard to use, you know, like a common parlance for all these things. Yeah. So I guess it's what they're trying to do with the training. But then you have other teams, like enabling teams. So say if you're having a problem with your test automation or trying to improve security, you might have a a team which lives for a certain amount of time going and helping other teams to work on that particular part.
Ian:Okay.
Ash:So generally, they're they're time limited rather than having a security team forever, which generally leads to people just thinking, well, someone else thinks about security, so I don't need to. The security team thinks about security. So they try and have these try and have a, like, a time limit on them or some form of success criteria off the back of them. And then you have something which I found quite interesting, which is the complicated subsystem team.
Ian:Well, hang on a sec. Sorry. Can we just go back to the enabling? I'll find that. That's very interesting.
Ian:So an enabling team sound a bit like the functional teams that we used to have in the bad old days. Well, still do having some bad modern days in some places.
Ash:The good old bad old days.
Ian:Yeah. But, you know, having a a test team and a an infrastructure team and a those are, I suppose, enabling teams. Yeah. But what do they enable in a waterfall scenario?
Ash:Well, I guess that's the point, I think. So it's rather than having it as one particular as one particular discipline forever and ever. Mhmm. So you have your cross functional stream aligned teams, and then you have, these enabling teams to improve in certain areas that you discover through whatever you've used to discover your needs for continuous improvement.
Ian:But I love that they're not then automatically part of the wallpaper forever.
Ash:Yeah. Yeah. Because that well, I guess that's that's the lock against just having them there forever, having a a testing team forever. Yeah. Yeah.
Ash:So just having them with specific goals and specific times in order to try and improve the thing that you're trying to improve. But I I can acknowledge the danger and how I can see how organizations might misuse, an enabling team. An enabling team might hang around forever because that's one of the patterns that you see with the DevOps teams that have popped up Yeah. Are the classic example.
Ian:Oh, yeah.
Ash:So it's like, well, having a a an initial enabling DevOps team with a mix of the right people in it to help your streamline teams to, to improve deployment or resilience or whatever it is is absolutely fine. But then, I think, certainly in most of the places I've worked, they've hung around forever.
Ian:Yeah. We're just gonna say now, oh, okay. We've renamed our infrastructure team the DevOps team. Pretty much. Job done.
Ian:We're agile now.
Ash:Yeah. They're just the ops ops team, basically. So the other team type was the complicated subsystem one. Yeah. So this is really interesting.
Ash:Most organizations have at least one part of themselves, which might be written in some sort of strange specific language, very specific to or with a specific set of tools which are completely they're completely aligned to the that particular subsystem, but they're quite niche.
Ian:Like, for example, a quote engine in an insurance company because those things are always very hairy. Yeah. And actually that thing is commercially perhaps the most important thing because it will determine what margins they make and the probabilities and all that kind of stuff.
Ash:Yeah. Absolutely. So the idea here is to acknowledge the complexity of that and then, like, sort of manage around it and make sure that all the communication and interactions with that team are good quality and they hook in well to all the other stream aligned teams who might have mobile engineers on or whatever they are, yeah, but who don't know anything about that technology, and there's good interfaces between those. And then the last team type was platform teams, so those who build. It was described as improving the developer experience, so which I assume that they meant testers as well, and anyone else who uses it.
Ash:But, essentially, what it was is was to try and but anything that the StreamAlign teams need in order to deliver smoother, faster, better, stronger, whatever it is that you need, then they would be there to facilitate that. So they would build tools like, help you with, like, your local development environments, your build pipelines, whatever it is that you need in order to to make that better. So that would be, like, your platform team. Quite quite a wide remit, and, obviously, there's, like sometimes your your enabling teams might peel off from the platform team to go and do a specific thing or then be absorbed back into it. It totally depends.
Ian:That's really interesting. So now I'm I'm doing that mental exercise of, so there must be an example of a team that isn't one of those, but I'm drawing a blank.
Ash:Yeah. Yeah. I must admit I've been racking my brains quite a lot to try and, to try and cope with something. But I think for the most part, most of the teams that I've certainly worked on or with or near in the past could probably be have some of the at least some of those characteristics, especially well, especially the ones who are cross functional teams of seven plus or minus two people rather than, you know, gigantic model functional teams of whatever it is. And then the other thing was the interaction modes as well, which I found interesting.
Ash:So you have three. You have, collaborating, facilitating, and as a service. So might have two teams directly collaborating with each other on a particular product or feature, and then you might have a enabling team facilitating another stream aligned team to improve whatever it is they need to improve. And then the as a service bit as well where you have very clearly defined interfaces between the teams and collaboration is less. The thing I found really interesting about this was that I've been spending my career wandering around saying everyone needs to collaborate more.
Ash:It's like, well, and that's fair enough, but collaboration includes increases cognitive load, And then that cognitive load dictates how effective your teams are gonna be, which is kind of the big premise of of the training. So it's like, well, it was a bit of a revelation to say, well, too much collaboration actually can hurt teams quite a lot.
Ian:Yeah. It kind of reminds me of architecture good practice where you're defining components that should be loosely coupled and highly cohesive, which basically means that the interfaces between the components need to be very simple. But inside the components, the things that are being done there need to make sense to be together Yeah. And be tightly bound together.
Ash:Yeah.
Ian:And I guess the same goes with teams because if you need to collaborate for every interaction, then maybe your the composition of your teams are maybe they're they're not loosely coupled enough. Yeah. And actually, maybe that's a re a sort of way a signal to say, let's let's reevaluate how these teams are.
Ash:Yeah. Yeah. Absolutely. Yeah. I think I've worked on teams in the past where those teams who depend on us have sometimes been either frustrated because we were trying to act as a service when we probably weren't quite ready for it, as if they didn't understand what we were what we were selling, Or there's been a an expectation that you would be a service, but actually you need to collaborate with someone quite closely in order to deliver a thing.
Ash:And both of these things, they kind of rub up against each other a little. So I think the idea within the training itself was to say, well, it's like a transitional state. When two teams first start working together, they probably do need to be highly collaborative. But to leave it there is where the problem starts. So if you're just in a constant state of high collaboration over everything, you would expect the relationship to change a little, and then certain things that you consume from that team would become more like as a service, as in a bit more predictable, and you know, you know, what you're gonna get and when you're gonna get it.
Ian:And what you need to provide to get it.
Ash:Yeah. Yeah. Absolutely.
Ian:And that's interesting to me because I feel as though that changes the remit of those teams in the early part of that relationship. Because they're they're not team a and team b aren't just collaborating over what team a is delivering to team b. They also have to collaborate on making that simpler and boiling it down to what what's needed. In other words, they have to collaborate on making it making that service
Ash:Yeah.
Ian:As well as simply delivering it.
Ash:Yeah. Yeah. Absolutely. I think one of the other things that I really liked about it was that it was a nice there's a lot of visuals as well. So as in you can there was, like, there's a there's, like, a visual language for the four team types and the and the three interaction types.
Ash:So you could you could nicely, like, sort of overlay these things on top of each other if you are mapping out how your teams currently work in your organization. Because, you know, I think a few places where I've worked before, it might be there's there was probably maybe a few stream aligned teams who looked after too many different applications or were expected to collaborate with four or five other teams at the same time. They were the ones who had too much load. The visual language of it all gives you a nice way to to show where the the pain points might be. So I really, really like that about it as well.
Ash:And then you could set, like, a goal state as well and make it look make it visual. It's one of the powers of making work visible. Yeah. Say say if you've got five projects on the go on one team, and you stick them all on the board and say, well, we're working on five things, and the sponsor walks past and says, why are you working on so many things at once? Oh, that's a great question.
Ash:But to do that for teams too, I think, would be really powerful.
Ian:Yeah. And it's giving you almost an architecture of your team Yeah. Instead of just the kind of functional outcomes. Yeah. And, you know, being able to look at the hot spots in that and and re engineer it to remove them.
Ian:Yeah. That would be very powerful.
Ash:Yeah. Definitely.
Ian:I particularly liked the and I know you said you liked it too, the complicated subsystem
Ash:Yeah.
Ian:Team. Because that kind of reminded me of reminded me a bit obliquely of the design of a design thinking thing of a prioritisation grid. I mean, that's obviously not something you have to limit to design thinking, but that's where I sort of learned it. And the vertical axis was impact for the end user. And the horizontal axis was feasibility for this team to deliver.
Ian:And so once you you'd put all your ideas up on this and scored, you know, each one about how far along each axis it should be, then you tend to draw some zones up there. Yeah. And so you've got some things that are really hard to do and have no positive impact for the user. So you just think, right, well, let's get rid of those, not doing those. Then you get things that are very feasible, very easy to do, and very high impact.
Ian:And you think, wow. This is it. This is the secret medicine Yeah. That will make everything great. And the answer is, well, yes.
Ian:But that's what everyone's gonna be doing. Everyone is gonna do that. So, really, what you need to to be focusing on is the things that are hard to do that have great impact for the end user. It's really just saying that there sometimes the value of a thing can be in the complexity in the the hard bit. Yeah.
Ian:And I I like the approach of taking and saying, actually, those things aren't gonna work according to normal laws of delivering software or whatever it is. Yeah. And they might be the crown jewels as well. So let's have them have a team that works with them. But, you know, that team will still have loose coupling with the other teams.
Ian:It will still have those interaction mechanisms. And when you draw that in, you can find out the ways in which that's just not working for that team.
Ash:Yeah. Definitely. No. I think that's that's quite powerful. So you can acknowledge the complexity of something, see that there's value in developing it, but then also have those good, like, team interactions around the edges of it for all the the other teams who consume it.
Ash:And I think that would be really, really powerful to have too.
Ian:Yeah. So this is really interesting. There's a book, isn't there? I'm gonna have to read the book.
Ash:So the book came out a little while ago. So I've I've got a copy. So I'm working my way through it now, but I was really excited to do the training too because I think that how our teams are are structured within organisations is is really, really important. I've seen enough examples of of the cost of my career to think, well, maybe there's better there's better ways to do this. And hopefully, the the team topologies method, if you like, will give organizations loads of decent options about how they can actually do that and how they can visualize what they've currently got, and show where they want to get to.
Ash:So I think it'd be really cool.
Ian:That's fabulous. And the book's called, what, just Team Topologies?
Ash:Team Topologies. And the training course, is Matthew and Manuel travelling all over the world to do it at the moment. I think I think they're trying to tie it with a bunch of conferences as well. So there might be one near you, so check out the website.
Ian:For sure. Okay. So is that our things?
Ash:That sounded like two things to me.
Ian:Okay. So if you have got some insight or experience that you want to share with us, then instead of having to send it to us at you can email us at
Ash:Whatalotofthings@gmail.com.
Ian:Or you can tweet to us at
Ash:What a lot of thing.
Ian:I love that. What a lot of thing. Alright. Well, so that's it then. Thank you very much, Ash.
Ash:Thank you very much, Ian. And thanks to everybody for listening.
Ian:Yes. Episode two. You must be special people to have made
Ash:it
Ian:this far.
Creators and Guests
