Subscribe
Share
Share
Embed
Exploring how humans connect and get stuff done together, with Dan Hammond and Pia Lee from Squadify.
We need groups of humans to help navigate the world of opportunities and challenges, but we don't always work together effectively. This podcast tackles questions such as "What makes a rockstar team?" "How can we work from anywhere?" "What part does connection play in today's world?"
You'll also hear the thoughts and views of those who are running and leading teams across the world.
[00:00:00] Dan: Are you on a cross-functional team or perhaps your inner team with many people from the same discipline, but you are a different kind of specialist. This can lead to opportunities, but also challenges, and it even raises questions about how organizations should well organize themselves. In this episode of We, not Me, we meet Ash Winter, an experienced software tester who has a particular interest in how teams and organizations work. So we can get some new thinking on balancing growing expertise with delivering where it really matters in a team.
[00:00:34] Hello and welcome back to We, not Me, the podcast where we explore how humans connect to get stuff done together. I'm Dan Hammond.
[00:00:41] Pia: And I am Pia Lee.
[00:00:43] Dan: So Pier, We've seen um, we've seen on the subject of humans connecting to get stuff done together. We've just, um, both. I think billions of people have enjoyed the Olympic games recently in Paris.
[00:00:56] Pia: I'm an absolute sucker for the Olympic Games. I love it. There's so many stories.
[00:01:01] and also there's a real kinship and there's a spirit that that often comes out. I mean, I, I now, now we reach mature age. I've seen many political ones, um, challenging ones, you know,
[00:01:15] Ones where there's been an undertone, but this one was a happy one. I really did feel actually that everyone got together was, I love how they took selfies on the podium.
[00:01:26] I loved how the Northern, Northern Korean, athlete took a picture of himself with the South Korean
[00:01:32] teammates. And Simone Biles, how they, her and her other US teammate, they, they bowed to the, I think it was the
[00:01:41] Dan: to the winner. Yes, the winner.
[00:01:42] Yeah.
[00:01:43] Pia: things like that was a little bit like everyone was there, you know, by the nature of all the hard work.
[00:01:50] And then whilst they compete against one another, there's a kinship of actually being at the top of their game.
[00:01:57] Dan: Yeah, it's wonderful. Absolutely wonderful. Yeah, and I think the, uh, one of my favorite moments was the, I dunno if you saw the massive argument that broke out at the, uh, women's, um, volleyball,
[00:02:07] beach volleyball,
[00:02:08] Yeah. And, um, the, uh, the mc just sort of. They were absolutely laying into each other, played, um, John Lennon, uh, imagine.
[00:02:17] And, uh, they just thought, just they all dissolved
[00:02:19] Pia: they just all started laughing
[00:02:20] Dan: amazing. Yeah. Hilarious. I mean it Great. That was a great, great call. And then the, um, president of the Olympic Committee noted it, didn't he? In his final speech. And he specifically said, you know, we've, people have lived under the, you know, roof of the Olympic Village, even though their nations are at war.
[00:02:37] And you sort of think, yeah. That's right. That's right. That's what it's, that's, um, it's, it's, it's very hopeful. You sometimes can approach these things with some cynicism, and here, you know, here it goes again, and obviously there's commercialism, there's all kinds of stuff that goes on, but at the core of it, it's, um, it's, it's heartening and, um, it's just what we needed.
[00:02:57] Just what we needed. wonderful. And it was very nice to see you in the shores, Pierre, and celebrate your birthday. So, uh, that was a real treat. Um, but today we're staying local and, um, we're going to be actually exploring a really, some really interesting aspects of teams, which, um, what emerges is, is how, how do you.
[00:03:17] Join a team. How are you on a team? As a specialist, we're gonna be talking to Ash Winter, who's a, seasoned software tester. Um, and he's seen a lot of teams from a lot of angles. It's a really great conversation. So let's go to here from Ash now.
[00:03:35] Pia: And a very warm welcome to you, Ash. Welcome to We, not Me.
[00:03:39] Ash: Hi Pia. Hi Dan. Nice to be here.
[00:03:41] Dan: Hi. It's great to have you.
[00:03:42] Pia: it's, yeah, real pleasure to, to have you on the, on the show today. well, you may or may not know the drill, so, um, Dan's gonna ask you a tricky question and you are gonna give us an honest answer.
[00:03:53] So I'm gonna ha, I'm gonna hand hand you over
[00:03:56] Dan: so, so Ash here are, I've got the cards. I'm shuffling them furiously. I
[00:04:01] Ash: All right, so this is random then. You're not,
[00:04:03] Dan: is completely
[00:04:04] Ash: not picking out something
[00:04:05] Dan: No, I haven't selected
[00:04:06] Ash: for
[00:04:07] Dan: for you. oh, here we go. This is going to, this is going to be, I, I think we might have had this one before. It's a red card ash, just by random. My biggest bias is what's your biggest bias?
[00:04:20] Ash: my biggest bias. That's a really interesting one. So obviously there's ones that you know about
[00:04:26] that you are,
[00:04:27] that you're displaying, and then there's ones that you don't know about.
[00:04:30] Dan: exactly. Have you got any that you, that you use in your sort of, you revisit frequently?
[00:04:37] Ash: yeah, I think one that I often catch myself doing is, you know, when you come into a, a situation or a team and things aren't going so great and
[00:04:48] Sometimes it's easy to grow, frustrated with the level of progress, but you've gotta remember that a lot, a lot of things happened before you got there.
[00:04:56] So knowing the history helps you to deal with it. So I guess sometimes I do fall foul to a bit of like a recency bias where, you know, just look at what's happened since I've been there. Rather than understanding the context and the history a bit better. So I think, I think that's part of my, like bias to action as well. I'm like, yeah, come on. Let's do this.
[00:05:16] Dan: Yes. Yeah. Leave the
[00:05:18] Ash: Let's deliver the thing. Let's, let's improve the testing, let's do this. And then it's like, well actually sometimes the bias to action and the bias to recency stops you from learning a bit of the context and history.
[00:05:28] So I have to stop myself a little bit and say, whoa, whoa, whoa,
[00:05:31] Sometimes you have to go back and have a look and find out why things have got to where they are.
[00:05:35] Dan: I think I have this myself as well, which is you think this is a clearly what I'm, what we're proposing to do what I'm proposing what we do is really logical. It's clearly the right thing to do, but it's still not moving forward. And, and, and it's just frustrating, but it's actually, you're not taking a moment to really understand what, uh, what might be hindering that you're not seeing.
[00:05:57] Yeah. This is really interesting.
[00:05:58] Ash: Because teams have long histories right you know, and they've, they've formed stormed normed multiple times before, like, you know, a new person comes in and there's just, there's a lot going on there, which you don't know about.
[00:06:10] So you have to be, you have to be patient.
[00:06:12] Dan: In fact, I'm finally reading Team Topologies, which I know is a book that you know well and you've, um, you recommended. And in there it says, ideally, teams should be long lived. Which, um, which is a great little statement, but it does mean there's history. Um.
[00:06:27] Ash: Yeah. Yeah. Like I guess like all things in life that has two sides to it, doesn't it?
[00:06:32] So if it is long lived, it can be harder than for someone new on the team or someone like, you know, like we were talking about specialists coming in to try and influence the teams in certain ways. If it is long lift, it can be harder to to do that because habits and cultures they form and solidify, don't they?
[00:06:50] Dan: yes, very true. We've given a little whiff of what we're going to be talking about, I suspect, but why don't we, first of all, on the subject of history, mo, go back a little bit and hear a bit about you, Ash, where did you talk? Give us some, your bio in a box, and, uh, we'll hear where that accent came from, I suspect.
[00:07:06] Ash: So, my name's Ash Winter. I suppose I've been a software tester for quite a few years now. Uh, maybe 15 or so so before that, I, uh, I worked for a small company working on, uh, market, uh, postcode marketing products, so using geographical information systems.
[00:07:24] But because it was small. Everyone just did a bit of everything, but it was my first job out of university, so I was like, I, I thought this was the way the world was, you know? I was like, oh, everyone does a bit of everything and everyone's happy to, to muck in to do whatever. and then I got a job as a consultant and Leeds, uh, in testing for a company called the Test People.
[00:07:45] And then I went into my first sort of larger corporate entity and I was like, oh. Everyone doesn't muck in and do everything. there's like developers that sit in that room, testers sit in that room. the product people are somewhere else entirely.
[00:08:01] And I was like, wow, this is very different. The operations people are, well, we're not allowed to speak to them. it was very, very different. So I was at the test people for maybe six or seven years. That it was a lot of hands-on testing, but it was also being a consultant as well. So going into different organizations and looking at how they did, how they did testing and how they might do it better.
[00:08:23] Spoilers, uh, testing is never the problem. It's always something else too, too much work in progress. uh, so, and that was a really interesting and varied sort of introduction to the world of. consultancy technology and seeing a little bit more of like what the different sizes of organizations and team, team structures had to offer. And then after that. I've kind of oscillated between contracting permanent work in software testing, but at like a sort of similar sort of more strategic level, if you like, with some periods of hands-on work.
[00:09:02]
[00:09:02] Pia: te So, testing teams,
[00:09:05] Are they unique teams? Um, or, you know, are, are they similar to other teams that you've worked in? Te tell us a little bit about them.
[00:09:14] Ash: So I think there's been bit of an evolution over the, over the course of like my, my testing career, which has been my first testing job in a more corporate environment. There was a big testing team I. Everyone was in, there might have been people who worked on say, performance testing or test automation, but everyone worked in one team, so testers in one place, developers in another place, product people in yet another place and closed and locked doors in between.
[00:09:45] which was interested because as it new tested, it was quite nice because I could, there was lots of people With a similar skillset to me and, and like, but maybe with more experience and I could go and tap into them. But then as different ways of working have emerged, since sort of, sort of the agile software development movement has, has gathered but much more traction.
[00:10:09] Then it started to change a little bit. So rather than testers being all together functionally as, as, as a discipline, you would have a tester or two on a development team with developers and analysts and other roles.
[00:10:23] which kind of had a, a couple of side effects because some, in some places, they were just like, well, we'll put a tester on each team and see what happens. Then that tester would be alone in their discipline on their team, possibly on a team of developers who didn't really know how to interact with 'em.
[00:10:41] 'cause they didn't have those skills either because they'd bid in their, in their room, the testers had bid in their room. So it was like it suddenly you bring them together and kind of expect everything to work out. And it doesn't always. And then I think there's a special set of skills from say, if you are the only one of your discipline on a team. You need to be able to influence others about showing what you do and what the value is, and then trying to get them engaged with the testing that you are trying to do. Because say if there's six developers and one tester, it stands to reason right, that the WA tester can't do all the testing, Because the output of six developers is far too much. So it has to be a team game if it's gonna be done well, it doesn't always work out like that.
[00:11:25] so yeah, I think it has changed like over the years from testing teams with different forms of testing being done on those teams, but very much as a service.
[00:11:37] So, they would be requested from. The development teams that can you do some testing for us, or it would be more nearer the end. It'd be like everything is ready and it's in the, in the, in the final environment before production.
[00:11:51] Dan: yeah, we're releasing tomorrow. Yeah.
[00:11:53] Ash: Yeah.
[00:11:54] Yeah. 'cause that, I guess that's the other, that's the other, uh, a fantastic thing about testing as well is that, often development takes longer than you think.
[00:12:02] Well, it always does. As, as a tester, I don't need, I know this because I've been on the receiving end of it so many times but you still had to play the game. You say, well how much time do you need to test this? And you say, I dunno, four weeks. And then they say, okay, well we'll get the developers to finish by then, but then they don't finish by then.
[00:12:21] And then you've got one week.
[00:12:22] Dan: three week overrun.
[00:12:23] Yeah.
[00:12:24] Ash: Yeah, pretty much. Um, but I do think there are some interesting. Other examples of testing teams still existing. Like, uh, IBM had a particular team called the Black Team, which, um, were sort of expert book finders and they would be called in every now and then to, to teams who wanted a bit more expertise in testing and then they would do their very, very specialist work.
[00:12:50] A lot of security and uh, ethical hacking sort of work. so you do have those, those, those specialties still, still exist separately, when you're on a development team, you're testing from the inside out, as in you are part of the team, you know the code base, you've got access to everything.
[00:13:08] Then people are consuming it from outside the team, so you're testing from the inside out. But sometimes there's a, there's a benefit from testing from the outside and trying to get in because then you are coming at it from either a, a security point of view or an accessibility point of view, as in you've either got someone trying to use it and can't because they've got accessibility challenges or someone who wants to, someone who has bad intentions for the software.
[00:13:32] So there, uh, there's, there's still like a few different team
[00:13:35] Dan: yeah, it's fascinating that, and in your, your, it sounds like you are, um, in this simplest form, you are, there's a sort of. You know, a managing polarities thing going on here isn't there? Because you can have, these testing teams are highly, they're experts. They spend time together. They probably do lots of development.
[00:13:52] They're absolutely on the money on testing. At the other end, you've got isolated testers who are sort of. You know, on their own in this alien world of developers and all kinds of other people. And, and they're sort of, probably doing their best, and they're, they're embedded. So they're useful.
[00:14:08] They're right at the fate of, right, of the coalface, if you like, but, have you seen a, how does this work? Because I, there are loads of other specialists like that. I've seen finance people on r and d teams, for example, so I probably feel a similar way. Um, yeah. What have you seen that works to sort of, not compromise, but to get the best of those two polls?
[00:14:29] Ash: You expected to be able to coach if you are a specialist on a team, you might not realize it, but I think that there's probably some expectation that you, you need some coaching skills or at least like relationship building skills. So, I, I don't really don't like the word embedding, because it sounds like you're some kind of, sort of alien entity that's been placed into something else that it's like, maybe that is the way of the world, but I don't like the world like that because I, I don't, I don't want to be embedded into a team.
[00:14:58] I
[00:14:58] Dan: No.
[00:14:58] Ash: be part of the team.
[00:14:59] Dan: That's true. I suppose I, I, yeah. Yeah. I suppose that's right. If I'm describing that polarity, I suppose that is the extreme version. Is it you feel embedded, but you might, you're well into enemy territory, which is not well, not what it should be. Not what it should be at all. Yeah,
[00:15:13] Ash: but yeah, so I think it's an expectation, or at least a need to have some coaching skills and relationship building skills. 'cause For that specialty to become part of the team. 'cause you're gonna need to share, aren't you? You're gonna need to build confidence with yourself at what you're doing.
[00:15:29] and if you don't do that, then I say you, you are in the more embedded space, aren't You You kind of sat sort of slightly on the, you know, maybe. Not on, on top of the team,
[00:15:40] maybe slightly to the side of the team, but you know, you, you're never really gonna have that, that level of influence that you want without those, without those coaching skills.
[00:15:51] Dan: Actually, uh, just, just going back to the digression Ash, I was just looking at some notes you sent me before. For, and you said often being described as embedded. Sounds like the team has a tick or something. I thought, I thought Pia would relate to that with the number of ticks in Australia, but yes. Um, yeah. No. Good. Good call. Good call.
[00:16:10] Pia: Do, do you find that you are a team of testers or you are a testing team? And I'm not sure whether that's quite the right terminology, but they're, they're two different things, aren't they? One, one's a group of individuals. Uh, do you get together and work out a goal and a game plan before you start? And, and does that bring sort of better cohesion?
[00:16:30] Ash: Well, I mean, it's a good call because say if you've got, if you had 20 testers who all worked together in a testing team, discipline based team who received code services deliveries from other teams and tested them together, then from a development, from a wider delivery point of view, very inefficient, but from a discipline point of view, very cohesive. And then if you split all those across 20 different delivery teams and put. A tester at each, all working in a slightly different context, working on slightly different things, then how do you maintain that cohesiveness? Because even if you're working in slightly different context and slightly different things, it's still useful to try and share that knowledge.
[00:17:11] 'cause someone might say, well, actually what you are working on affects what I'm working on, so maybe we could test it together, which would be a really, a really nice way to do it. So. The community of practice has been quite hot in the last four or five years, so we're returning to the, uh, the Spotify model here, which I'm, I would be amazed if you've not talked about the Spotify model in some way or experienced it.
[00:17:34] Dan: Well, weirdly, by the way, we haven't talked about it on the podcast, but we, back in the very early days of Squadify when we were trying to understand what this tech world was. We met a, a coach from Spotify and they sort of talked us through how they do things, but please share all because we've never covered, covered it on the podcast as far as I.
[00:17:53] Ash: uh. Right. Okay. So lots and lots of organizations, so they attempted to adopt the Spotify model, so you would have, tribes, which were like the, I think that was the highest level, and they would have ownership of, large parts of the business. I think in Spotify it was like, mobile apps, recommendation services, whatever it was.
[00:18:13] And then within that you would have everything that you need in order to run that bit of the business. So you would have, uh, finance people, HR people. Technology, operations, whatever it was you needed in order to run that bit of the business. So you would have that, and then you would have, squads and then I think they were called chapters or guilds,
[00:18:31] where you would have them by discipline. and then those chapters and or guilds would have a, like a community of practice between them to say, right, okay, well let's all get together and we'll talk about. testing, development, DevOps, whatever it was that they wanted to talk about, whatever was relevant to the skillset. So they kind of got big as the, as the Spotify model got bigger.
[00:18:56] although some of the implementations of the Spotify model were a bit, It only really, well, it only really works for Spotify and maybe it didn't work all that well for them. but very few that I saw had the, actually tried to put everything you need in that particular tribe. It was more about splitting up development teams rather than the whole business.
[00:19:18] So you've got the, you've got like how development works and then the, the like the whole business as well. So trying to split all that is hard, isn't it? Um, so most implementations that I was part of like fell slightly short of that. They would do the technology part, but then they would still have centralized HR finance functions, which you would then go to.
[00:19:38] So, but the Spotify model's really interesting because it's like a, now we're like 10 years on. It's such a curious topic the way that it's been done in so many places..
[00:19:48] So with communities of practice, I generally think like there's a couple of ways to sort of keep in touch. So you can either have a more general one where you might have, something akin to like, Like retrospectives where you all get together and talk about what's been going well, what hasn't, you know, that kind of thing. You might do it in like a lean coffee format hall, whatever it is. And then you've got, a community practice to solve a specific problem
[00:20:08] which are a bit more targeted.
[00:20:10] So say if, You have a particular challenge with, I don't know, security testing for example, or, you might have had a couple of security issues in the last couple of months and you need to upskill in that area. So you might have a community of practice around a particular, like a security testing.
[00:20:27] Do some workshops, talk to some teams, try and get it into their, their sort of general ways of working. So it's just like the two types, so the more general one or targeted a, a specific challenge. So, but the community of practice has been, like, over the last five years, I would say it's been a, it's been a way that testers have sort of tried to maintain that cohesion together.
[00:20:48] Um, and it's worked pretty well in most places that I've been to, to be fair,
[00:20:52] it
[00:20:52] took a while to react to the, the initial challenge of being split up and distributed throughout the company. It always takes someone to say, well, hang on. We can do something about this.
[00:21:01] Dan: Yeah. It seems that this is a classic sort of case of the, the sort of people trying to be too pure about and and simplistic about a very complex problem. I'm sure. No, as you say, Spotify is greatly admired, but now we look back and probably that, particularly if you're inside Spotify, I'm sure you saw loads of flaws with it because you're constantly working with imperfection, aren't you?
[00:21:22] Trying to balance so many things and um. You know, we do a lot of work within, with teams, in team of team settings and that sort of connective tissue between, you can't just have high performing teams. They have to perform together, don't they? So looking at those ways of having connective tissue is not taking away from the purity of, of being team focused, actually a, a pragmatic way to approach it.
[00:21:48] And, and again, something you, I guess you need to experiment with and learn to see what's appropriate in your setting.
[00:21:53] Ash: Yeah, because it never it never stops changing. Does it? 'cause like your business doesn't stop changing it, it grows under our contracts. or, you know, something new will come along. Like, you know, in the last few years, generative AI has obviously changed quite a few things, but it's just like there's always external factors working on your teams and your
[00:22:12] business. So to just to implement a model and then it just stays the same in perpetuity is probably not all that wise, is it? You need some review points in there
[00:22:23] to see what's, see what's changed.
[00:22:25] Dan: And, and I suppose the, the, if we remind the goal of this obviously is speed and quality, you know, and, uh, and really getting, getting products that customers want into their hands. And, uh, um, and, and that's always complex, isn't it? As, as everything is moving. Um, we've, we've talked a bit about Agile on the show. Can you just talk a little bit about that? I dunno how big a comet it is.
[00:22:47] It's just a couple of articles, but, so what's the, what's the reaction currently happening to, to Agile, which we've personally found amazingly effective, but what's, what's happening out there right now?
[00:22:57] Ash: My own journey with it came from a very classic, sort of waterfall model. Uh, I dunno if there Ever was a waterfall model, it's just chaos, you know? Um,
[00:23:09] Dan: It.
[00:23:09] Ash: Uh, I can't remember who it was that said to me. Something along the lines of people can't adopt Agiles.
[00:23:15] They've never had a method, any kind of method before. ' cause they've just done chaos. Um, but I was
[00:23:20] like, I, I don't wanna be that cynical, you know, but the, I think there's some truth in that. so I, I went and did the certified scrub master. Qualifications and product owner as well, actually quite a few years ago.
[00:23:35] And I really liked them. Uh, and it, it opened my eyes at the Lean Kanban practitioner as well, which was my first introduction to thinking and systems and, you know, the counterintuitive nature of flow and work in progress and all those other things that you've lived with your entire career. People are saying, well, if we've got 10 things in progress, that means we'll get there 10 times quicker. And you're like, right, maybe. But I didn't really have the words to, to refute that before I did all these qualifications. So I learned loads from it, to be honest. Doing those and then working on, Scrum teams, seven plus or minus two people on them. two week iterations visualized on physical boards. I thought it was brilliant.
[00:24:25] I had a great time to be honest, because I could remember what the world was like before it
[00:24:31] and I didn't think it was that much fun. And, people who say that it is, I'm like, well, I don't, maybe because. You would like immerse yourself in one singular part of it, but from a testing point of view, as a tester, you're generally at the sharp end of it all,
[00:24:47] because you can try and test as early as you like, but eventually you're gonna do some testing near the end and you're probably gonna have to have some awkward conversations about quality and how it's not quite met expectations yet.
[00:25:00] So in the old, in the old World, that was all saved up. Until like the very end of the project.
[00:25:06] Dan: sort of a free for all, and then the tester had to sort of
[00:25:08] Ash: Yeah,
[00:25:09] pretty much. Yeah. So in my first dedicated testing role, I was basically like, you know, a little kid doing some testing and there the company I was working for were looking to offshore a large proportion of their business. This project was worth like millions upon millions and my bug was the only thing in the way, this bug that I've found and raised.
[00:25:33] But they were like, well, we can't do anything until we fixed it. And it was really hard to replicate. and it was very intermittent, but it, if it's intermittent for one person and then you've got millions of people using your app,
[00:25:43] then, then literally thousands of people are gonna see it. So I'm there right at the end of this massive project with like the board. Asking me what's going on? I'm like, I don't know. I was like, could someone help me? Like I literally just found a book that I thought was interesting, so that wasn't much fun to me.
[00:26:02] So making the switch to a cross-functional team where sometimes it's tough, sometimes all the testing drops at the end of the two week iteration, and then you've got loads of things in the testing column and everyone's like, oh, you're finished yet.
[00:26:15] It's like, right. Well.
[00:26:16] Dan: just being held up by Ash now.
[00:26:18] Ash: Exactly. So, but now, now I'm a little bit more experienced and somewhat more forthright. there are ways and means of trying to not, not have that situation happen, but I don't, I, I feel like there There's too much cynicism around agile ways of working. Yes. There's some very, very dubious approaches out there, which I don't particularly agree with.
[00:26:44] Um, especially the, I won't mention any names, but the scaling ones, because to me they always seem like an excuse to do everything that you already do, but call yourself agile.
[00:26:55] Because it doesn't involve changing any of the parts of the business that actually need to change. Um, it's quite, actually quite easy to get, relatively speaking, to get developers and testers in teams and get them working iteratively.
[00:27:06] Yeah, there's a bit of grumbling. People go on about too many meetings, but it's like, it's actually, it's, it's actually not that hard. But then when you look at like, the rest of the business, like how we budget and how we prioritize what we're gonna work on, There's that, there's that tension isn't there, between organizing developers and testers into teams and then, trying to budget for the next five years.
[00:27:28] It's like, well, you know, developers and testers is, they'll be like, well, I can't, I can't travel in
[00:27:34] time, so I can't tell
[00:27:35] Dan: No, exactly. And that's right. It's right. Yeah. there's, there's,
[00:27:39] Ash: yeah. Yeah. But it's there. Yeah, Yeah, Absolutely.
[00:27:42] Dan: Um, so if you, you know, you've seen a lot of teams from so many angles. Actually, it's been fascinated to think about this specialist in the team and seeing the seeing how the system works actually from your, your angle. What would you say to the listener is something that you've learned that, um, you would, maybe they are a specialist or maybe they have a specialist in their team. What's your word of advice that they could, something practical they could take away?
[00:28:05] Ash: Um, one thing that really helped me is I did the Institute of Leadership and Management coaching and mentoring. but it busted so many myths I had about what coaching and mentoring was and how to influence people. So, and I just thought it made such a big difference. To like my work and how to work with people as a specialist, and it allowed me to retain like a deep specialism in testing and still work as part of a team and get on really well with developers, designers, uh, technical leads, business analysts, whoever, whoever it is, and be able to.
[00:28:43] Influence, like the adoption of a variety of testing activities, and then what all that means for quality. So I think it's like looking at how you coach people, whether or not it's, you know, the explicit stuff that you do or the implicit that you know, you just, or the tacit rather, that you just do without thinking about it.
[00:29:05] And I think I am. Mindful that I've always found it easy to be the only tester on a team because I think I'm wired that way and I don't lack, uh, I have a paradigm for testing, uh, that, which I feel like I can explain. and I feel like most people I can get on with, and even those that don't, that maybe that I do clash with, I can still.
[00:29:28] Form a working relationship with them. but I know that's not, that's not true for everybody. So I would say that working on your coaching, working on your people skills really, really help, to build up your confidence as a test, because it's all about knowing yourself, Right. If you know yourself a bit better, then you can, you can be on a team because you can be a bit more comfortable, can't you?
[00:29:49] Dan: That's perfect. Great. That's a, we're gonna capture that, that's gonna be a good, a quote to lift. I think that was very good.
[00:29:57] Pia: and Ash, so. Passing thoughts here, what would you recommend as either a book or film or podcast or piece of media? Could even be a song, um, that you would recommend. but yeah, that's something that, that's, that's been, uh, you're either reading at the moment or something that's been really valuable to you in the past.
[00:30:19] Ash: I recently read after it being on the shelf for ages and ages and ages, the Five Dysfunctions of a Team. I, I have no idea why I'd not read that book before. Because it's absolutely brilliant. I love a business fable, and I'm not snobby about them because I think it's a really nice way to explain some complex stuff when done
[00:30:40] well. So books like The Goal by Eli Goldratt, uh, the Phoenix Project by Jean Kim. These are all excellent books and. Some people get a bit snobby about business fables. It's like, well, it's not a real business book. And it's not real fiction, is it? but it does explain those, you know, those five dysfunctions of a team really, really well with examples that you can
[00:31:07] follow, and it's an easy read.
[00:31:09] It's like, what? What is wrong with that? So that would be my recommendation. Five dysfunctions of a team or any business fable that you fancy. And if someone gets snobby about it, tell 'em to go and
[00:31:21] Dan: Sling the hook. Yeah. A perfect place on which to end. Ash, thank you so much. It's been really fantastic to dive in in this, uh, on this topic we haven't really dealt with in such detail before. So, uh, it's wonderful. Thank you very much for being with us and best of luck with your next move.
[00:31:37] Ash: Thanks for inviting me on. I've had great fun.
[00:31:42] Dan: You know, it's funny, I know we're talking about software here and 21st Century technology, but a lot of that conversation reminded me, took me back to my engineering days, actually days of my MBA when we were doing, did doing an operations management course, and it was, it was led by this, um, a woman from, Denmark actually, who ran a.
[00:32:02] Bike manufacturing company, and she was saying this sort of a similar thing that the old days of factories were that you'd have the lathes over here and then you know, the sanders over here and the whatever. And actually what they did with their factory, and this became the thing, was to actually. Put them all into cells so each cell would make a certain type of bike and they became specialized at that, but each one would have a laden and aandra and or whatever.
[00:32:25] And um, it's a little bit like that really, isn't it? So you've got these specialist groups sort of siloed and you, but they don't really connect and there's sort of bits and pieces going from one to another. Very clunky to actually saying no. We've gotta put these all in one. And she did say, you have to invest in more kit, but she said it is transformational.
[00:32:44] They did it over one weekend in her case. But it's a little bit like the people in these teams going from very siloed, all in specialist lumps to actually saying, no, we're about building a product here that requires all of these lumps, so let's organize ourselves in that way. So yes, it took me back to my
[00:33:01] Pia: Took, you back to your engineering
[00:33:03] Dan: yeah, exactly.
[00:33:04] Pia: Here's my question about that unifying goal, because if you don't have a unifying goal, then you are just, you're, you're, you're in a slightly gladiatorial session proving your worth of your technical skill. And, e even whether that's not the case or not, we, we can perceive that to be so it's competitive and it doesn't need to be.
[00:33:26] and you know, when you talked about it the early on, the people are in different rooms and they're not coordinating and they're not. They're not commu communicating. So, yeah, I think that's the, that that's the, the key element that's, that's a leadership moment is not to get absorbed, and tripped up by the task, but actually to, to make that call, let's get really clear about what the roles are and what we're all trying to achieve.
[00:33:48] Dan: Yeah, absolutely. And, and, and as coming outta it, I think my conclusion, listening to Ashes, and you know, this is. Something that we, we strongly believe, and this is what we do, is sort of the, the team, the, that little group of seven plus or minus two people is the thing that is closest to the customer.
[00:34:04] It's most agile. It's most sort of fast moving. That's the thing that produces something. So give them primacy, sort of make them the most important thing, and then work out how do you connect those, the connective tissue instead of, rather than right. We have a whole sort of practice in finance, marketing, and sales.
[00:34:23] And we hope that the cross-functional teams work sort of flip that the other way around, make the team work, and then use the functions and the to, to build those communities of practice, et cetera. So yeah, it was really great to dive into that with Ash actually.
[00:34:36] Pia: It was, it was great. And, and I really loved that. he had such a, an interesting coaching and leadership and that was a, you know, a lovely thing that, that actually I. The leverage of all of that capacity and all that technical excellence is, is through the human that, you know, that's o otherwise, um, you are siloed, you, you are individualized, and you just don't get that collective effort and you don't not able to achieve really amazing things.
[00:35:06] Dan: Yeah, it was a very refreshing answer to that and great to see is, it would be very easy to sort of, I, I, we didn't talk to Ash about this actually, but I imagine as the testing person, you have quite a lot of power. You're very technical, you know your stuff, and you could easily play all those games as Trump cards, um, rather than actually engaging with people, as I said, being part of the team, not embedded in the team and not just.
[00:35:28] Trying to out smart people, but to connect, connect with them and solve it through human relationships. Um, really wonderful. I bet a lot of our listeners will find that really, really instructive actually as I'm, I'm sure this is, this is happening to them, but, um, yeah. Wonderful. But that is it for this episode.
[00:35:45] We, not Me as supported by Squadify. Squadify is the complete system to help your teams to connect and perform. You can find show notes where you are listening and at squadify.net. If you've enjoyed the show, please do share the love and recommend it to your friends. We Not Me, is produced by Mark Steadman. Thank you so much for listening. It's goodbye from me.
[00:36:05] Pia: And it's goodbye from me.