Shane Gibson chats to Tammy Leahy about how she helped scale the data teams she leads.

Read along you will

PODCAST INTRO: Welcome to the “AgileData” podcast where we talk about the merging of Agile and data ways of working in a simply magical way.

Shane Gibson: Welcome to the AgileData podcast. I’m Shane Gibson.

Tammy Leahy: And I’m Tammy Leahy.  

Shane Gibson: Hey Tammy, how’s it going? Great to have you on the show. I’ve been trying to get on onto the podcast for quite a while now. So before we rip off and talk about all the cool stuff you’ve done with your team scaling them out. Why don’t you tell the audience a little bit of background about yourself?

Tammy Leahy: Sure. As instructed, I haven’t prepped for this. So it might be a bit meandering. I’ve only been working with data teams for about four-ish years. And I come from an accounting and finance background. So I’m deeply technical at my core in my kind of what I will, it came through university, and I was very passionate. When I was going through university about making the world a better place. I started off wanting to be a translator. So I did linguistics, Japanese, Chinese. And my parents said, no, no, no, get a backup because that doesn’t pay, you won’t be able to pay your bills with that. So became an accountant. And as part of that did accounting and philosophy saw it as a way of viewing the world same as economics, same as music, language is everything else. So my whole thing is about thinking about the world in patterns, whatever your chosen language of choices. So  that’s why I’ve perhaps ended up in this space, because I do see patterns and ways of making teams work well together, because that’s one of the things I’m really passionate about is how do you get teams, people enjoying the work? And just loving what they’re doing and doing good, really getting to awesome and feeling awesome about themselves. So I’ve been in this in this role in this team for about four years, we started off with about eight of us, we’re up to I’m not sure quite how many, sometimes because we work with a few partners.

Shane Gibson: So if you had to pick how many people are working in the data analytics space in your teams right now, what would the number be this week do you reckon?

Tammy Leahy: So in terms of in our direct team, it’s around 22 to 25 mark, we’re recruiting at the moment. So it’s probably going to be up around the CD mark in about three months. And then we’ve also got kind of we call our data cart, but it’s a group of vendors that we work quite closely with. And there’s about 19 of them in working with us at the moment on quite a big piece of work. And then in the wider community, we’ve got a decent work of people who are just getting there, there’s the thing about the community as a sense of belonging with people. And it’s really cool how people in the community science talk about it as a place that they belong in or belong to. So that community at the moment, we’ve got about over 100 active participants. And I don’t know how many inactive because we’ve got many, many more people actually using the tools that we put out there and that we kind of coach on and provide learning on. So I don’t like to think about the numbers. Because it’s not about the numbers for me, it’s about the outcomes that we’re trying to achieve with what we’re doing.

Shane Gibson: So many questions we could go off on. So let’s start back in the beginning of it. So when we talk about numbers, we increase the numbers of people on our teams doing the work because we want to scale the work to be done. And we know that adding more people makes things harder. Every time we add new people to a team of people that are working well. We lose some velocity, we have to reform and change the way we work slightly. So when you had eight people at the beginning, kind of think back to then what was the team struggling with show what was the team topology?

Tammy Leahy: So when we first started off, was just before we worked with you actually thinking back then I actually found the picture on my phone of the first team forming the first team self-selection we did. It was a combination of BI team, and a kind of a business performance reporting team. So it started off as two silos really. And we had a really strong BI team lead who is actually our lead engineer now. And then me who’d come from all the commercial context of the thing and thinking about the value we could deliver. So the team structure was still a bit, it was absolutely suboptimal was throwing shit over a wall each other and expecting someone to understand what you meant. And so that’s why we went down the path that we went down to try and get a bit more closer collaboration and work amongst the team. As the analyst understood what the engineers were doing, or the BI developers were doing, and the developers understood what the analysts meant when they said all but the user wants blah, blah, blah, better. So when we say structure, I talk about structure as an operating model or a way of working, because I honestly believe that Agile lines become almost meaningless when you’re actually working in a properly collaborative way. And myself as a person that wears multiple hats, which represent the functions I feel for my team. So that’s going on tangent, I’ll come back to that in a minute. So back to the structure of the team. We ended up going from this kind of to functional silos, if you like to more of a squad based approach or team based approach small teams of four, typically, two analysts, two engineers, or at the time, there were still called BI developers that hadn’t yet learned the new tools we were about to start implementing. And then at that time, we didn’t have that concept of a product owner. So between me and the lead engineer, we were multi hating everything. So I was the people lead for everybody in the team. And that was intentional, when they did the restructure to bring our two teams together, I spoke to the tech leads at the time. And their view was that they wanted nothing to do with pastoral care. That was not the strength. The strength was in mentoring and coaching and thought leadership. And my strength was clearly in people side in coaching. So basically went completely fat, which was when you’re at 8 to 10 people tops. So that was one hat I would wear, I would also wear the product owner had or product manager had to be on how you define it for the platform. The data products were delivering as a proxy, because we didn’t have the business engaged in that way yet. Our lead engineers covering everything from the architecture to some of the building of the platform and the infrastructure. So lots of multi-hating not just double hating at one point, I kind of figured out even in the last year, I’ve worn up to five functional hats, to make sure things get to where they need to get to.

Shane Gibson: So that was one of the first things we did though. We worked out the hats that needed to be worn. And even though you ended up wearing a hell of a lot of them on your head at multiple times. We always talked about them as different hats. We talked about the pastoral care looking after people making sure they were safe, making sure that they could have a career make sure that this change as horrible or not as horrible. But as disruptive as it was, they were as comfortable as they could be with that change. And we talked about the head of work to be done, the prioritization and that kind of stuff. And we talked about the hats of designing or managing the work that has been done, and leading that and mentoring and coaching. So we always talked about multiple hats. In terms of using that framework to kind of start to drive the skills of the roles that are required within the teams, how much of that did you think played a success as you scaled out to more than eight, as you started to add more and more people to the wider team and scale out there work to be done? To those thinking about it in terms of hats and which hat you’re going to scale? Does that help or not?

Tammy Leahy: It has actually. Because for us, it didn’t feel. We were scaling for a long time. So it didn’t really feel. We were at a painful point until six months ago really. And we never approached it as we need another role or another function because we need not, it was never just because we noticed some kind of feedback loop either through employee engagement surveys, or through just talking to people one to one that we’re noticing some part of our system not working the way it needed to work. And then you try and diagnose that and you get down to the root of the problem. That would be because we’re wearing too many hats. And so we then say, “Well, which hats the problem, it’s that one, we need help with that one, let’s find someone who can help us with that particular piece of our system.” So for example, when I was running up until about a year ago, I had the kind of I hate the word evangelist or advocate for data, but I was running that function of helping the business understand what’s possible thinking help pushing them to try and dream bigger and use bigger things with data. I was wearing that hat. And then we had our lead analyst come on and he picked up that from me, which then meant I could focus a little bit more on stakeholder engagement, but by then demand had spiked. So there was a whole lot more delivery management type work, helping people prioritize amongst themselves, what work the squads are going to do, because you had conflict in product owners. Then our delivery practices Lee came on, and she picked up some of that, as well as a whole lot of the people coaching. But it turns out that my capacity, perhaps is a little bit too big. And so what we’ve ended up figuring out is, actually we’re still constrained and if we look at our last I want to say experiment when we brought in a whole new squad, which I would not ever recommend. At least not the way we did it because was a terrible, the feedback was certainly telling us was a bad experiment. We clearly weren’t in a position to bring the one because at that time, we didn’t yet have that extra person in our support crew to help with the onboarding, with the pastoral care. Like I said, we focused on what is the feedback telling us? What is the team telling us? And what is our system telling us we need to do or where are the problems, then how do we know what hat needs fixing? So I can go into so much detail on this, we actually did an exercise earlier this year, when we’re looking at, we just do, it just the system fault, it was a breaking point, the pressure was massive. And so we sat down a support crew and said, let’s do a functional mapping. And I’m using air quotes, because it’s effectively a hat mapping, what are all the things you’re doing? So we did it in person, there were four of us, there’s only four of us still in support crew with this practice. And we’ve got different colored posted notes each and we had a big table, and everyone had to write on their color, post it note, all the things they did daily, weekly, monthly, quarterly, whatever it was for the team. So we did that, wrote them all down. Turns out, I was still wearing way too many hats. Because when you wear lots of hats for quite a long time, it’s difficult to recognize that you keep putting one back on and you’re not letting it go to the person who should be wearing it. So we did all of that, then we took everything and kind of group them up into. I’m gonna keep using the word hats into the hat buckets. And then when we looked at the different colors, and the different buckets, it was very clear where a lot of us were just chipping in, because something needed to happen. But we weren’t focusing on it well enough. And it was really clear where someone was doing way more. The cognitive load was massive, because you could see the color ticket across everything. And so that was a pretty cool visual exercise for us to do to say, for ourselves as we call ourselves support crew, we’re the tech leads that people need. That’s us. For us to figure out what extra hat do we need to bring on now to help us what thing needs fill in because we’ve got problems in our system? And we had some pretty, pretty awful problems. Because this onboarding this new squad, we’ve got some awesome feedback from that.

Shane Gibson: So you call it a support crew, I call it coaching team. So to be clear, it’s a group of people who are sitting out of the squads doing the work, to help figure out what needs to happen next, from a scaling point of view, where the blockages are, where the problems are, where squads need help. So their ability to sit back and observe, and then work with them from a retro point of view to go, we probably need to change this. So I was wondering back to that feedback loop. So one of the patterns that I see saw you do, really, really well. And I also saw Jen Shepherd do it when she’s been on the podcast before with her team was  at the beginning, you spent a shitload of time every week talking to your team one on one. So my theory, my hypothesis, watching that a couple of times is at the beginning that allows you to get very quick feedback from every individual team member about how you need to change how you need to guide or coach on the way we’re working. And without that, you’re gonna go down a path, and they’re not getting any feedback and had a problem. Is that true? Actually, it was half an hour an hour every week with every person at the beginning to get that constant direction change where we have a problem that we may need to look at, keep an eye on and then maybe need to help mitigate later on.

Tammy Leahy: That is true, I did put and that’s just one of my practices, is people need time, they need to be heard, they need to be recognized. They need to be seen by the others they work with. So I did spend quite a lot of time with them. And I still until our delivery practices, Lee came on and picked up some of that, that more pastoral care element from me. I was still doing that at a time when I had 24 reports, I was doing half hourly to hourly one to ones at that stage, it was between weekly and three weekly. And that was dictated by the person so I didn’t say we’re going to meet three weekly, it was what cadence do you want to meet on? How often do you want to chat and sometimes, if people have more going on in their personal life or more going on at work, or you’d have more frequent cadence, we’d have longer cadences where people don’t need to talk as much, but absolutely, because you’d have your retros when teams are learning this stuff, and people are getting there, sometimes they don’t always bring up the things that are really the problem.  there’s a symptom they’ll see and they’ll tell you about it at retro and then when you have a conversation the most effective way this was done actually was, I found if I have booked in the one to ones with the individuals all in the same squad on the same day, you start to get a really good feel. At the end of the day, you just have this vibe and this feeling for what’s going on in that team seem to know where issues are. And sometimes people will actually say things that other people have on their minds as it are. Did you know I was thinking this? And you’re “Oh shit, no, I didn’t know that”. And actually, they haven’t said that to me. I wonder why, is there something about openness and then I’d sort of find a way to broach a topic in a very open kind of question type way to then open that conversation with so and so. So that was really helpful. And actually, that’s one of the things I get a little bit uncomfortable about with scaling. Because how do you keep that quick feedback loop in a really authentic way, because I actually miss that. The further away from that I become the more I miss it, because that’s such a deep connection to the team and the people that not having that. , and again, maybe it’s me, I just need to get the heck go more, but I still at least do quarterly meetings with everyone in the team. And often you’ll get people message you saying, can I have a quick chat? So sometimes you don’t even have a regular meeting set up. But you just talk to people anyway, so that’s absolutely a feedback loop.

Shane Gibson: For me, I’ve got this thing coming out from the no nonsense central podcast that I do that there’s a difference between managers and leaders. I can now articulate a pattern where the manager focus on the work to be done. The leaders focus on the goals that the team should be working towards, and then helping the team be successful. And so that pastoral care there, how’s the team feeling? How’s team feeling? Because we lose a lot of that nature, we go back to being coming, focused on the factory, focused on the work and not focused on the people. So we lose a lot of stuff if we don’t manage it, if we don’t put hats in place purposely to do that pastoral care.

Tammy Leahy: The other thing that you have to have as well, because we noticed that when because we’d only been working with you for what, nine months, and then we went into that first lockdown. And  if we hadn’t done that work, before we went into that first lockdown, we would have been in deep in turn the lockdown, remote working. So it actually helped us a lot to be in that that frame. But a few of the other bits is not just pastoral care. It’s team coaching. So its team care. So how do you care for the human being as a human being? How do you care for the human being as part of a collective of some description? How do you care for your system? Some still not about the work to be done, but it’s how your whole how the people interact together. So that social system, but also the things that help that system function. So the way I see support crews, our function is to make sure people are cared for teams are cared for when our system can sustain itself almost without us, that’s the ultimate goal is that we could step away and this thing continues to work because the people in it are leaders in themselves.

Shane Gibson: So when we first started scaling, we had a really good conversation about when we’re going to go to another squad, we had some choices. And so one choice was bringing a whole new squad. And the other choice was split the current squad and half and bringing new members to both halves. And pros and cons on both of those. And from memory, we decided split the squad.

Tammy Leahy: That was so long ago.  I should remember that six months ago.

Shane Gibson: So six months ago, it sounds you experimented with lending and a whole new squad. Talk to me about it. What went well and what went wrong?

Tammy Leahy: Well, I suppose because I care so much about the people, I feel it went terribly badly, because we got some pretty strong feedback from the individuals that joined that they didn’t feel supported enough, they didn’t feel well enough cared for when they joined. So we’d set up the way we’d set it up was, we had a whole new squad start basically on the same day. So what was good about that was they had almost a cohort they were part of. So I come from a big four accounting background, I joined as part of my first two weeks were spent in a graduate training program, and you end up with a cohort. And that creates a sense of belonging. So in that sense, they were a really strong unit in that sense. They were almost against the machine kind of thing was a bit. So that’s where it was bad was us against the machine. But it was good in the sense of there were a cohort. So that was good. It was good in the sense that you didn’t end up with anyone having potentially useful new views, because I’m very strong on that idea of I want our existing team to be challenged as much as possible, in as nice as possible way with how we’re doing things because there’s always a better way. So it was useful having a team come in completely cold and completely new together without almost been indoctrinated for one of a better word, not that we indoctrinate people but they were in a position where they could completely define some new practices think of ways that are different, which equally is bad in some respects. So I suppose those were the good things the not so good things were that sent because we’re a full remote, we’re having to onboard them remotely, it was during lock downs. Just that connection with the rest of the team was really difficult to establish because there was no incumbent, no existing person to sort of start the squad. So we had buddies in place, we had the meeting with them regularly that a really close connection with our lead engineer. But it still wasn’t quite good enough, it still didn’t quite work to remove that sense of isolation. We had a really awesome product owner working with them. And so that helped to an extent she connected them quite well with the business and but it did feel a bit isolated. And then just the feelings there are engagement surveys. So we onboard the squad around October, November, we had an engagement survey run in December. And it was just you because you can look at employee lifecycle. And the team is big enough that you’ve got can keep it anonymous enough within the cohorts, but the new joiners cohort, which wasn’t just that squad at the time, there were two other people in the new joiners cohort had an engagement score of six compared to the rest of the team with engagement scores sitting at 8.5 or 8.7. So if that’s not telling you something. So they were saying things but I wasn’t doing one to one just them at this point, I handed off the people lead hat to someone else. So I feel  that’s part of this, this this concern, I’ve gone about having the pastoral care hat handed off, because the feedback I felt wasn’t quick enough, or maybe we heard it, but we were too busy with fighting fires because of rapid scaling elsewhere, that we didn’t hear an act on it fast enough. So many learners have come from that. And one of the things that we did was a second, we saw some of the feedback coming through. And we saw some of the messages coming through from that squad. We just basically I said at one to ones with all them. I said, “Look, I’m really sorry, this is a shift experience. This is absolutely not what we’d hoped you would have had coming in”, then just worked with them individually to start with to understand where they’re at what their concerns were,  a lot of it came down to really it was a connection thing. If you bubble it all down, it’s a connection thing and when you’re remote. And this squad was one of our first full remote. We had guys down south guys up north everywhere. That’s been a real challenge is how you get teams on boarded and connected, properly connected a real human connection. That was a big problem with that stuff.

Shane Gibson: So one of the things I say when I start coaching is let’s remove as many of the uncertainties as possible.

Tammy Leahy: Well, I go for chaos.

Shane Gibson: So you bought in an experienced product owner. You remove the uncertainty of a product owner who hadn’t worked on this.

Tammy Leahy: Actually, she wasn’t experienced but she was a good product owner. So she invested a lot into we coached her quite a lot. And she invested a lot into understanding what was required. What the squad found difficult was she wasn’t a data person. So she come from a research and insights background was amazing, because at least she had that and she could connect the dots. But she was really well connected with the business and understood the business needs. So in that sense, very strong.

Shane Gibson: But had she been a product owner with the other squads?

Tammy Leahy: No

Shane Gibson: So do you think if you had a board and a product owner who had been a product owner with the other squads before that you would have reduced the uncertainty for them?

Tammy Leahy: Absolutely. So when we diagnose, that’s when we boiled it down, and we said we can see three key issues here. So the data product owners that week, so the way we operate with our data product owners is they’re business people who have a job to commit to us, at least, , 20 to 50% of the time to support the squad, depending on how intensive and how new the stuff as they’re working on. And that’s a pretty hard commitment. , if they can’t commit that time to us, then it almost becomes a world we’re gonna put someone else in. And then you might not get exactly what you want, because this is just how it’s going to work. So what we found with that model is that in a world where there’s lots of demand on everybody’s time, that becomes a real, both. It’s a learning curve that these people if they’re committed to it, they invest the time and effort in and mostly the discretionary time and effort then, alongside the day jobs. And it becomes one of the feedback things we had from this product owner, I really enjoyed doing it. I’ve learned so much, but it’s such hard work because she had to get her head around, not just shaking your head around data and what it means and some of the decisions she’s got to make, which is different than a product owner who’s looking at a customer offering through a product or plan is very different in data and because some of the decisions you have to make, you’re in the detail of seeing this edge case of 5%. Do I care about that’s different than does the button, I’ve got a click on this page, do what I need, it’s a different problem. So that was one of the things was the burden that I feel it’s a burden, but it’s an opportunity equally, that was on these product lines is quite high. And she articulated that really well in the sense of it’s great opportunity but equally, it’s hard work. And that that makes it more difficult. The second thing we noticed really quickly was our support crew, which is our coaching crew and your balance. There was at that time was three of us. We hadn’t fully on boarded the fourth, the fourth or come on. And partway through, we were transitioning those people that you had. So by the time the issues that it was really hitting the fan that people need to transition, see total chaos. So that was one of the issues. Clearly, we did not think about this well enough, we just barreled into it. We were too busy onboarding this whole of the program work that we didn’t think about it well enough. And then the last one was really around just having a bit of remote experience. So this idea of it comes down to that thing of having enough time to think about it. So at the heart of it, it was support crew wasn’t well enough. I don’t want to use the word resource. But we didn’t put enough priority on bringing this new squad in because it’s just a matter of priorities if you’re constrained and unconstrained world. And from a data product owner perspective, let’s do something to have some maybe more dedicated data product owners who understand this world better can actually help coach these teams that was the other thing we didn’t have any coaches in. Because we didn’t have a team facilitator, we didn’t have an Agile coaching. So between me and the two other guys and support crew, we were wearing those hats amongst everything else. So I can see so many opportunities, where have we put some safety measures in place better coaching at least a team facilitator or a scrum lead or a coach, get someone that in actually have that people lead stuff solid and settled prioritize. There’s so many things we could have done better. And actually coming from that we diagnose those problems. We went and we dug, dug, dug, until we said, this is the root of the problem that has now resulted in us proposing a different model, but it’s not different. It’s just an evolution of what we were working on before.

Shane Gibson: So you described a good case of perfect storm. So the coaching team was going through a transition, they weren’t stable anymore, because they were changing at the same time you board and product owners who hadn’t done it before, and a whole new team, so everything was changing. So it makes me think, and it’s a pattern that I haven’t tried before. But actually, if we could map out some of the core practices, and then basically give it a chaos score and say, given the amount of change, then now that we need some extra focus, or we need to not do it, or we need to change something. Because we know that the chaos score on every line of that practice is red. So therefore, we might be successful, but highly unlikely. So going back to that, so you had already scaled though. So we went from went from two squats to three, then you said you got to 20, 25 internals, 19 co-partner people.

Tammy Leahy: So that was all that happened. So we went from 8 to about 15, it was a relatively slow-ish scaling. For the first I don’t know, 18 to 24 months. And then in six months, it went from that to boom this whole lot of big program of work happening with the vendor. Then there’s new squat coming on board. But that slower scaling period, we’re a lot more intentional about what we were doing because there wasn’t as much demand on us. In a way, part of how we’ve worked has created the demand. So it’s a good problem, it’s not a bad problem. But that we did actually test a whole lot of different things I’m calling it the gentle scaling period. During it, it didn’t feel gentle, but in relatively, it’s gentle. But even the first bit of joining the teams together that was a huge mindset shift. So the very first day of getting the teams to work differently. And there’s one of the guys who’s a senior engineering one of the squads at the star, he was like, this is just micromanagement, I don’t see any value in it. But now when he talks about he’s like, I can’t imagine any different way of working. This makes us safe. So we use the word safe quite a bit and how we think about things. And we certainly weren’t safe through this last notch gentle period of scaling. So one of the things we did when we brought when we went from one to two squads, but also we never really had a platform squad, the squad that built the machine that we fly with our data products, if that makes sense. We kind of had these platform type engineers embedded within the data product squads. And if you remember that we kept having these problems of actually we never read really quite got to build out the platform components that we were very just in time, we never built anything less, we can see a clear use for it, we never quite got to doing some of the things we really wanted to do to make life better, easier, faster for the people working on the platform. So we then brought the first step to go from two scores with sort of a lead engineer, and I don’t know what and kind of a jack of all trades sort of developer sitting outside the squad, then we brought a couple of people who had a much stronger interest in that sort of much more hardcore technical space. So if you think about tea skill spectrum, there are way down there, almost cloud and infra type and brought them in and created the platform squad. And that was great, because it allows create some focused on what do people actually need to be effective, because building it while you’re trying to drive it or fly, it’s painful. And if you haven’t got focus, as you’re doing that, it’s even more painful. So that was one of the things we did. So that helped a little bit of scaling, it meant that we could bring on or change the squads developing and buildings on our products much more safely. So it was one of the first patents we adopted was to create this platform in the platform squad does not maintain anything that the data product squads build. So if they build a data product, a dashboard, or a data service, or whatever it is, and it breaks, or it needs to change. It’s their backlog, they have to deal with it. And we make them we reserve some of the time to deal with that kind of stuff, the platform squads really managing the components that everyone else uses making sure that actually they can do the work effectively. So we found that those squads that the data product squads are becoming constrained because I don’t know, the clusters we’re using are not running fast enough. And they’re waiting in a queue. Platform squad, figure out how to improve their experience and over time that’s evolved to talking about now developer experience, and how do we think about making the experience of our squads and other data product squads better? So that was one of the first iterations of scaling for us was bringing this platform squad and separate data product squads?

Shane Gibson: So if I use the DataOps brand, definitely one of the earlier teams I’ve worked with that came fully on board with that idea as a data product squad. That theme of you built it, you deploy it, you own it, it breaks, you fix it and that’s always a problem. But that idea of just holding out a percentage of time. So they can have right to fix that thing. But what it gave us is there was a lot more focus from the teams on delivering things that wouldn’t break because they knew they had to fix it. And then the second one was that move towards platform as a product, the idea of a squad who are building a platform, but the key focus was the building it for the data product teams, squads, they’re not navel gazing off and bow cool shit. So there was always that balance of how far he could a platform squad be and building the product? How they get early warning when there’s something that’s needed that would take longer than iteration so they had to start working earlier. How do they know that they’re not over engineering it? But how do they also get feedback from the other data product squads about would this work for them? I remember one of the ones was to the early modeling, and lineage and beating it effectively a bunch of hints in the code that then formed those lineage maps and that to and fro. So how did you get with that? How did you get on with that idea of the platform squad, building a product, platform as a product? The customer has been the other data product squads, how do they get early warning? How do they not overbake? How do they make sure it’s for purpose? How do they get feedback from their customers which are the other data product, would you get to lead with it?

Tammy Leahy: So this is where we’re trying to experimenting a little bit at the moment with improving those feedback loops. So the platform’s call itself has ended up growing a little bit, mostly because the number of squads we’re supporting the number of users we’re supporting has grown, which indicates that we haven’t scaled, we haven’t automated enough to scale effectively enough, but it’s one of those fast, it’s a problem, you have to go fast, you have two choices. Automate as much as you can up front. So you don’t need to bring on more people or bring on more people and fix it later. And we typically do the whole, what’s the minimum we can do? So we brought in basically one more person into that squad to support. And typically what happens is, the team just talks to each other. So one of the patterns we’ve got happening now is the senior engineers and the data product squads are almost the beacons that will talk to the senior engineers and the platform squad. And they’ll share it and this is not working for me or this is working but I’m having trouble with this piece of it. So that there’s almost just some chats happening within a team’s channel. We’ve got three people problems.

Shane Gibson: So that’s key. It’s the senior people and the data product squads are not logging tickets for the platform squad about what they need. They’re having a conversation with them to say, “Hey, this is where we think we’re going. These are the things we’re struggling with. So it’s a conversation first”.

Tammy Leahy: So we’ve a pretty long running backlog for platform squad, it’s got so much on it, and we’ll never ever get to all of it. Because it’s that vision of what would a perfect thing be, but actually, what is the next most important thing for us to do? And that’s how we tend to approach it. But if you were taught some of those guys in the data products, because they always say that we’ve never got on to stuff they wanted quickly enough, you can never do enough. Because there’s always more to do. At the very beginning, what ended up being was in retros, the guys would complain or what didn’t go so well would be our we couldn’t run this thing because the platform couldn’t do X, Y, Z. So to start with, that was some of the feedback that was through the retros. But then over time, as we’ve kind of created this more collaborative prep amongst that group of people who are interested in the engineering world, as they’ve got closer, and as we’ve seen leaders emerge more and someone’s got a really strong interest in testing, or someone’s got a really strong interest in improving how we deploy, then they’ll talk to each other more, because that’s just happening. And actually one of the people that joined the team, as part of that new squad, not even an engineer just started a lunch and learn session randomly. It was, “Hey, let’s just get together and talk about stuff”. So it’s really cool to have the openness within the team today, let’s just talk about stuff.

Shane Gibson: That’s a good pattern. So you didn’t just pick up the Spotify model and draw the lines and the words, you didn’t just pick up the safe piece of crap and try and force that to happen. What you did was, you knew that those things may organically grow when they add value, and you watch for it. And then as people started to create those groups outside of a squad, you encouraged it. And if there was value, they’ll keep doing it. And if there was no value that stopped doing it, and we don’t need to put these artificial lines and try and drive it because we think it’s valuable, the teams will, will do the things that make themselves successful. And we just need to observe hint, and sometimes guide but never do.

Tammy Leahy: Sometimes you don’t even need to hint because these are smart people and they’re passionate about their work and you give them freedom, they will find awesome stuff that you could never have even thought about.

Shane Gibson: So when you started to scale when you when you went through that Uber scaling, how many of your practices and patterns were stable were put together in a way that you could actually teach somebody new coming into them? Or were they still relatively ad-hoc, and that was one of the problems?

Tammy Leahy: And there are there are two steps in that kind of faster scaling, that not gentle scaling piece, the first step was onboarding. This whole other program will work start with 15 developers and then 19, all up. We view, we ran a pilot, so we kept ourselves slightly safer, we ran a pilot, because the first time we were getting, we were allowing, I say allowing, we’re getting not our people into our platforms in a way that you could do some pretty bad damage if you didn’t know what you were doing. So we wanted to make sure there are some safety measures in place. So we tested it as part of that pilot process was one additional squad. And we were really open with them about how we were working what we were doing. They gave us great feedback about what they needed to see what wasn’t in place. So coming over there, we’ve got this thing which we call doc site, which is effectively just a repo that’s been surfaced through, we paid you can only access it when you’re inside our network but that’s got it our data catalog. It’s got our ways of working. It’s got our principles and standards. And so what our team did was they built this standards and practices section. There’s a big BAU or user guide section. So when you’re onboarding, follow this guide, get yourself set up. If you’re new, here’s the standards and practices. These are the principles and the philosophy is that you don’t want to die in documentation, but you’ve got to have just enough that people can understand and at least they know when they have to ask a question. So that was really helpful running that pilot and understanding that we need to document little bit more of how we work in the technical practices that people understand it. Then as we brought on more people so that was in place, then as we brought on more people into that program of work, we very quickly figured out that one of the patterns we adopted was this concept of a data translator. So something that we realized quite early on with our squads was don’t commit to a sprint and refine the work you’re going to do but you’ve not really done any of the thinking around the modeling or the design work. If you’ve got a product owner who’s really close working with you. You’ve got people who understand the business they can actually get an outcome within an iteration. When you’re working in a place where you’ve got people who don’t understand your business, you kind of need to provide them with the level of support to be able to get the data products out in a timely way. Because this is a project, it’s constrained with time, money, all the rest of it. So we introduced this concept of our data translators, and they were working ahead of those squads to define the models define working as the interface between the business means the business owners and engineers the squads. And then one of the new patterns we had to implement as part of that scaling. So this was as we’re bringing on, we went from one squad in that program to, I don’t know how we’re up to now for three engineering and one kind of movers squad. And this is also different, the way that is working is different than the way our internal squads work. Because our internal squads don’t split between Dev is none of that other internal squads into end. But this was more about what can we reasonably expect of people coming into this world. Anyway, we implemented this new thing called a Data Design Forum, which to start with was really just a way for us to teach people how to model better, and for an opportunity for people to send check models. Because part of what we do is we document in a coming soon section, the thing that’s going to be built, and so we standardized the template around that high level headings, why are you doing this thing? What is the user getting out of it, define your table’s transformations in enough detail that someone can pick it up and work with someone who’s reasonably qualified. We don’t want to turn people in code monkeys, but that pattern evolve because we found that if we weren’t providing an opportunity for people to challenge each other’s work, or to get some other someone else who might have seen that domain before that subject area before to say, you haven’t thought about this problem with it. We were getting lots of rework coming back through the squads. And when you’re in a time constrained, cost constrained space reworks. So we implemented that. So it’s not an art forum, it’s a data design forum. So we implemented that, and that helped a lot.

Shane Gibson: So the idea that I kind of just had around uncertainty mapping, when you start to scale? Effectively, you have applied that to your iterations. You’ve gone and said, if we would be interesting to see whether you could codify it, here’s some lenses. And if we could score the uncertainty in those lenses from one to three, or one to five when we know its domain that we have no expertise, and our product owners knew, it’s not data savvy, as much as some others, a whole lot of things you go, our level of uncertainty is high. So we want to do some work early to reduce the uncertainty of entering into that iteration. And one of the key things that you and your team did really well was you do the work early to reduce the uncertainty and then you stop the natural reaction is people go and do the work. They create the data model. And that becomes the design that has to be implemented, where your team are always in. So they were always using it to say, in this period of time-box, how much early work can we do that reduces the uncertainty and has value, but it’s still a guess. It’s going to be validated when we do the real work, but we have a better insight in what we’re walking into. So I thought that was a really good technique but you had to get that balance. Because otherwise detailed people love to go and do the work, they love to deep dive and solve that problem.

Tammy Leahy: And to be fair, the way it’s working with our external squads is our translators are prototyping, they’re getting into a huge amount of detail. But actually, that’s a pattern that works. You run a small prototype to define the thing that you need to build. And that’s why internal squads do as part of the process as they all prototype it, not only does it help you understand if the thing you’re going to build works, but it also helps you define your test groups and what you need to test. So that’s been really helpful having that prototyping mentality if a design comes through now with this big program that hasn’t had a prototype, that’s a risk indicator for us. So we haven’t codified a risk mapping or anything that doesn’t exist. It’s been done by this person who hasn’t seen that domain before riskier, let’s provide some more support on in it.

Shane Gibson: So I’m not suggesting you do a stupid risk ignores, but just being able to look for the patterns of the way everybody’s thinking about these things. And again, that prototyping process, there was kind of sort of standard behavior with the prototypes never went to production, which is another anti pattern everybody else does as a prototype. And it’s close enough that they push it and then deal with it later. With your teams, your squads, they were prototyping to learn more. And then they rebuilt from scratch pretty much using

Tammy Leahy: Well, that’s a cool iteration. So since we’ve moved our tool into a much more cohesive toolset that engineers analysts are working on the same tool set. Now, the prototyping will typically happen by an analyst, because it’s closer to their end of the tee skill spectrum. But it could happen by anyone in the squad. Sometimes you’ll get a prototype that’s so good that the engineer will take it QA tune it and then that will become part of the production code, which is super cool. Because it’s just that beautiful mashup of people across that T-skill spectrum working really well together.

Shane Gibson: But to be clear on that pattern, it’s not here’s a prototype, push it. It’s the engineer saying, it meets all our coding standards and things, our definition of ready meets our definition of done. It complies of all our standards which most people will pick up those things in the beginning because they make their lives easier. One experiment you might want to try and I’ve never been lucky enough to be able to work with a customer that we could try this is there was an idea of Agile dojo, it came out of Walmart. And so what they used to do was they had a separate space. So effective was a building. And whenever they brought on new squads, they effectively went into the Dojo, and they actually did their work. But in a Dojo environment, so they were surrounded by more coaches than normal. They were often taught they mentored as this whole idea of they were put in a Dojo space to start the work. But it was different to working in what they go to when they go back into the normal. So I thought that was a nice idea.

Tammy Leahy: I’m smiling because we’re experimenting with it at the moment. So our next iteration has been after this learning from onboarding a whole new sculpture never ever doing, again, is that we will always start a new squad with someone who’s been in the practice. So you’ve immediately got domain knowledge, you’ve got knowledge of how we work there. And it’s more it’s more than just the knowledge of how we work. It’s that connection. So someone who knows that so and so s mountain biking, and go and have a chat to them, if you wanna go for a ride, and we intellect, stuff  that, the less kind of technical stuff or the more social stuff. So that’s one of the things that we’re doing now, we actually did a self-selection exercise was the whole team, which I spoke to a few other guys about afterwards and I didn’t get my first choice, or that was my second choice. I was hoping you were at least got the first and second choice. Because you have to balance that thing over the skills, the knowledge, the people fit amongst the teams. And but one of the patterns were trying on this agile Dojo concept. And the next year was our delivery practices. They came on in the midst of all of this chaotic stuff happening. And thankfully, she’s been so focused on empirical evidence and listening to feedback that a lot of what we’re doing now has come has been borne from us having conversations with her and her coaching us. So one of the things we’re trying now is when we experiencing because we’re going through another scaling spike at the moment, as we’re experiencing that we’re taking people out of the platform squad. So we’re taking guys who understand absolutely how the things work. We’re buddying them up. We’re embedding them inside the data product squads with the new people. So the new people then work on either a piece of tech debt we’ve got or a ticket that’s in the sprint for the squad that they’re a part of with pay programming. So idea we’re testing this now. But one set of hands on the keyboard, two sets of eyes. And the other set of eyes is your platform trainer. That then allows these people to have basically really tight mentoring and coaching as their onboarding, but they’re in the squad. So the platform trainer behaves as if they’re part of that squad. And that’s why you start to build connections with the other people in your team. And we’re moving away from a four person squad, we’re trying out a super squad, it’s still not that big, it’s eight people. And we might split them up depends on if eight works or not. We’ve tried with six and eight before and it hasn’t gotten the feedback we have from the team. It’s just too many streams to think about. We want to keep ourselves small so we can be focused together to call the squad to mob things together. So this platform kind of thing is really interesting, because the feedback we’ve had so far from the squads themselves has been, it’s awesome. Because we don’t have to carry that burden of coaching someone through all the new stuff, the platform trainer does that. Then from the platform teams perspective, this is awesome, because we’re in there with them day to day seeing what’s good and not good on the platform. So they’re using it as a feedback loop for that whole vision of how do we make the developer experience awesome. So it’s actually quite so far, we’re only two and a half weeks into it. And we haven’t even done the big, big scaling, this is the first little bit. It’s been working reasonably well. And that’s a pattern that we’re going to if it works, we’ll look at the feedback from those around but so far so good. We’ll try and adopt more fulsomely. So as we onboard squads and other lines of business people who are not as not part of our team in an Agile concept, look at how we can adopt that same practice. So get one of the more experienced team members from platform to jump in with the new squad, work on something with them to help them learn help them connect back to the people in the practice. That’s been really cool because you can see the excitement with everyone. The guys who are in the squad with new people coming in. They’re really grateful. I saw one of them today. And this has been awesome, because we can still focus and know that these people are getting on boarded, but we get to connect. And then the platform guys, they’re getting to do something different. They’re not in the hardcore tech, they’re actually helping to build a data product, but in a really kind of collaborative way. Because most of them are innately coaches and mentors. Most people are good coaches and mentors, you just got to give them the chance.

Shane Gibson: And that’s kind of interesting, because that means they are actually a platform and practice squad. So if I like in it to what we’re doing with AgileData, if we treated the AgileData stuff as just a platform, just a product, we’d never worry about ways of working, . We never worry about how people actually use them what they do outside and inside and how it flows. We just worry about the features on the platform. But focusing on the practice as much, then we use it. We see how people use it to do the job. And then we go, “Well, there’s an opportunity over there to remove some complexity or streamline or remove the bottleneck”. But if you’re not embedded in the in the way of working, you just end up building a product that’s disconnected. So, for me, it sounds like your platform team is more platform practice team.

Tammy Leahy: It’s not just the way about our practice, it’s more about the experience of using data. So whether you’re a developer or an end user. So one of the things we learned through this other big program work was actually having a changed engagement lead working with us to help us almost act as that feedback point. Because when you’re in data, your analysts everywhere. You’ve got people in different teams who aren’t even analysts, you don’t even know they exist. I’m super keen on this stuff. So having someone who can almost create that for not front door, but front door in the community. So we’ve actually got a team site, or a team’s Sales Team channels. It’s the beginnings of a community. Some of it’s grown organically, we haven’t been super intentional about it. They’ve been certain things we’ve been quite intentional about but that’s the other aspect. So we think about developer experience is one thing that the platform squad has as an objective, or an outcome they want to improve the developer experience. The other part of it is as a support crew, we want to make sure that anyone who needs to get data can get it quickly, easily understand it and actually use it to value. So how do you create that experience for people that they don’t have to go and find the analyst? Who knows the answer who does the thing? And it’s not just implement a data catalog.

Shane Gibson: What about just a self-service tool? Can I just drop one of those really cool self-service tools in there and people would just serve themselves?

Tammy Leahy: No, but that’s the old school  when I was an auditor they told me that you just install the platform, but you don’t do this this whole thing, or you got to provide that wraparound service.

Shane Gibson: So you’re almost talking about data experience. Their definition of developer experience versus data experience. That’s a key differentiator many years ago, for a very short amount of time a week to zero. And one of the patterns they have at the beginning, which I thought was really cool because it was in the old days where you had servers and somebody else’s data center, but they’re still servers. And the way they dealt with it was they had a threshold of minimum number of user’s maximum number of users. And what they did was, every time they got to a certain maximum number of users, they entered the server. And the reason they did that was they were for provisioning. So they effectively bought the firepower went up, the query time went down for all the users that got to the best it was ever going to be. And then as they added more and more users that degraded and it was automatic. There were people involved, but there was no discussion about expanding on those essences, just the way they worked. If we took that pattern, do you think the idea where we proved a neighbor splitting worked? We prove that splitting squads in half and bringing people in was far more effective than dropping a new squads? Issue lost some stuff, the greater good came out eventually. Do you think they’re actually a pattern of whether you’re starting to get to full velocity you automatically split and then you’re over investing but when you have to scale you already have and then you constrain your scale to that pattern  there is no stupid idea of we’re going to bring 100 people on. No, the neighbors haven’t split enough. So we can for project that at this point in time, we will have enough stable squads who are experienced and safely able to do this work and enjoy it to do that work but until then, bugger off just get in the queue because heading 100 people no matter where we get them and how good they are, doesn’t work. What do you think? Do you reckon the idea of for provisioning and just constantly neighbor splitting would work if you permission to do it.

Tammy Leahy: I’m inspired greatly by nature and natural systems. And so one of the concepts of nature is that nothing will ever grow infinitely. And I know that you’re not used to proposing it because you hit a natural ecosystem limit where your ecosystem doesn’t support it. So if  about our practice, and the way we work is, we’re not going to need an infinite number of data squads, or data product squads, it’ll always be constrained by actually what the business needs to deliver, what they need to do, what they’re thinking about, how much money they can afford to spend on it. I agree with this concept of for provisioning and having an idea of what might be needed in the future and then growing towards that as you need to, but you also need to be conscious of. We’re probably going to go through a recession. What does that mean? Does that mean that we’re going to get different constraints put on us around hiring practices, for example, maybe, but you kind of need, you don’t want to put yourself in a position that you’ve brought all these people on? It’s a great team culture, and suddenly, you’ve got to make people redundant, you’ve got to think you’ve got to balance carefully. People who are permanently with you and augment a little bit, bubble up a little bit with great partners, and then shrink back down as you need to. Because at the moment, I see lots of demand, and I see lots of un-serviced demand and I see so much opportunity, but I am very conscious of the fact that no system will ever grow infinitely there is a natural limit. And there’s a constraint in it somewhere. So you have to respect the constraint. And the other point is that I never to do things too far ahead of time. Mostly, it’s not one of those buildings, they will come situations. I don’t want to, because they don’t come. It’s not reactive, but some people could see it as a reactive stance, but it’s that feedback loop of just how far forwards you accept your feedback from.

Shane Gibson: It’s a balance. But often when I start with a new team or a new organization, I talk about the adoption curve. Because empirically, I can say, I’ve got enough data where we started off small and nobody really wants to talk to us, because nobody believed we can deliver anything that. And then over time, we start getting some success and then the kimono opens. The massive amount of latent demand gets flooded. And then I’m not sure we’ve got to the stage where empirically I can prove that we then get to a balance, I think we do. The natural constraint comes in there, you’re not going to end up with more data people in the organization than the rest of the organization. So we’ll go from there, but coming back to that [inaudible 00:57:50].

Tammy Leahy: But just outside of that, one of the models you can adopt is part of it’s a risk issue. So if you’ve got so much demand, and someone says my thing must be done. Now I’ll support you to bring on your own group of people to do that. So that’s the other pattern. So listen to one of your podcasts a while ago to do called Juergen Apollonia did it unfixed at work. And I really liked that as a pattern library to think about how you scale things and how you grow things differently. So we use that when we’re thinking about solving our scaling problem, say, similar to your point of at this point, you automatically factor in another server. So we’ve said when you bring in another squad, because this is about supporting frameworks and coaching frameworks, you automatically need to bring in another people lead or another coach. But really, I want to try and avoid that by scaling in such a way that we don’t do that. We become experience people with people help support others to grow those teams within their areas? Because I’m strongly of the view that the best work happens closest to the problems and closest to the business. Not in some Center of Excellence or some silos of ivory tower or whatever it is, that’s not the approach.

Shane Gibson: We had one of the podcasts we did was with a professional Scrum Master. And one of the things easy it is everybody tells me I should become a coach. And he goes, “I’m a Scrum Master”. I love being a Scrum Master. I am the most awesome Scrum Master in the world. And I just want to be a Scrum Master and that’s the same within teams. So I have a framework where I talk about novices, practitioners, experts and coaches. And I’m very clear that lots of people just want to stay being an expert. It’s very valuable. It’s a valuable set of skills and roles. It’s a valuable career. And we shouldn’t always think that everybody wants to be a coach. So having experts within a team but allowing people in those squads that want to go to coaching level and stay in the squad. They don’t want to be a coach across multiple squads. They just like to lead and mentor and coach people in the team.

Tammy Leahy: We’ve got that exact practice happening. And one of the scores you’ve got this guy is just you give him any scale problem, he is so expert. People go to him like, I’ve got a problem with this, can you help me fix it? He knows his stuff, but he doesn’t want to go and become a coach for the whole practice. And that’s just not his bag. He loves his work. He’s awesome at it. He’s awesome when people asking questions, he’ll coach in that context when you compare that with some of the other guys who actually, I do want to influence others. And I do want to do things differently. So I absolutely see that happening that you get people who sit at that level, and they love it so much, and they’re so good at it.

Shane Gibson: One of the other things that has come really clearly on the no nonsense podcast is this idea of setting a clear goal for teams and let them get on with it. And so one of the challenges that I see regularly, when you bring external parties and partners, or vendors or whatever you want to call them, when you drop a bunch of people in there aren’t going to be there forever. Who worked for an organization, that’s not the same organization as yours. So that organization has a set of goals and outside your set of goals that brings in a really interesting tension. So how did that work for you? Obviously, dropping in people that had never worked in your organization, before you had the whole subject matter expert, they were professionals, but they worked in different ways. So they didn’t know your way of working. Is that whole change, which is horrendous to begin with? But how did you deal with the fact of the goal of that organization probably isn’t the same goal as your organization? How did you deal with that problem?

Tammy Leahy: Honestly, I haven’t perceived that as a problem. And I don’t know if it’s just because we have such a great working relationship with our partners. When we set up this, we call it a co-op for one of a better word, but it’s like a partnership, when we set it up, we approached it in a very different way. We don’t do RFIs every time we need a piece of work. It’s akin to a panel, I suppose like a vendor panel. But we’ve had situations and we haven’t fully leveraged this, we haven’t fully utilized as we’re working it, but we’ll have situations where we’ll have a problem. We’ll take it to the group and say, we’ve got this problem we need to solve, can you help us solve it? And typically, we’ll have quarterly sessions, we’ll go in and say, this is what we’re seeing coming up, this is what we’re planning to do. Here’s where we might need some help, can you guys ever think about it? They will go away separately and meet together as a group of three separate vendors. So in they compete with each other in other respects, but there are a group who work together. So I appreciate, it’s just amazing. I’m actually constantly surprised by how this works. They will work together, they’ll come back to us with a cohesive approach to a problem. And they’ll say this is how we think we need to approach it. So I can’t help in this space. So we’re going to come at our expertise in this way. And this is how we think we can deliver it. Because one of the things we did find was, we didn’t go out and pick a vendor who could do everything. And when people came to us as part of the selection process, we were really clear that we don’t believe any single organization can do everything perfectly, there’s always going to be someone who’s got greater depths in different areas and others. And so we looked for people who were really clear on their strength theories, and where they could absolutely contribute value, versus those who said, “We can do everything under the sun thing”. And some of those organizations could probably do everything at great depth but we had specific problems we need solve. And we still have similar problems. So we went down that route. So we have almost domains technical domains that each of our partners operate in, they blue at the edges often, and they will talk to each other with a blue happens. And one might be better fit than the other. I haven’t perceived it as a problem that the goals, I come from a consulting background, I understand the constraints. And so I respect that. And I don’t tell them that we’re going to have work next week, and then they line people up and then they don’t like that’s just disrespectful. And if you maintain that kindness, I just care for each other and respect for each other, then it just seems to work.

Shane Gibson: I think they’re understanding the business model, and that they’re a commercial organization that has to make money, that’s the goal in life and then understanding how that works. And then using that as a strength, “Well, if we work this way, then we’re supporting the way you work, and then we get that symbiosis”. So going back to the beginning, I was wondering, so you started off with two teams of four. And the team topology was analysts, and what you call BI developers, but they were the engineers. So engineering team and an analyst team, there was the team topology. As you started building out to multiple squads, how did you do the domain split? How did you decide which squads were going to work on when? So not so much the prioritization but what was the team topology in terms of because you talked about the squads were into when to begin with, until you started getting a platform squad so it was a squad, got the work, deliver it, maintain it, then how did you define what a squad was going to work on or specialize or be subject matter experts on? How did you deal with that domain split?

Tammy Leahy: So the first bit obviously was creating that platform squad that was the first split. Because I think then it became a function of who had existing domain knowledge and it was mostly playing to people’s strengths really. So if you think about one score to be fair, I’ll take that back. At the beginning, it was just a matter of, let’s just keep our heads above water. And thinking right back to it, the very first couple of things we did. One was a customer product matrix, which to be fair was within that domain that that squad was knowledgeable in. The other one was around contact center data. And again, to be fair, the guys in that squad had existing knowledge of that. So we did play to the strengths of people’s existing knowledge, existing domain. And one of the patterns, one of the things, one of the reasons why we’ve done it because we’re changing to the super squad way of working at the moment. And this platform train away working is, we noticed that the cognitive load and the squats was two weeks, even after we bought the third dot internal data product squad in they because they were all new, we didn’t overload them, we gave them one subject area pretty new, pretty greenfields and let them go with that. But it meant that our other two squads ended up with just ever expanding domain and ever expanding cognitive load. And it becomes, especially when you start doing that with integration type data products, there’s lots of spikes that turn up and that can be difficult. And with the COVID situation, I don’t think we’ve had complete squads for in any of our squads for the last six months, we’ve always been running sort of 75%, 50% because people have been sick or away. So one of the things that we as part of that we needed to change was we just need to reform because people are carrying too much, we need to split the domains a little bit more, because it’s too much. And everyone crosses over, they touch each other’s domains. But that’s where having that data design forum helps you keep that consistency of your source of truth. So that’s one of the things that we’re actively working on is which pieces leave which squads and who adopts them. So one example is that new squad was working on more customer touch-points, they’ll pick up a hold of the contact center type data as they’ll become their domain. And that will reduce cognitive load and the squad that originally developed it, because it’s now nowhere near the domain that they operate mostly in. So it’s about who operates mostly in something who has the most expertise. But they’re not the only squad that can do it. They can all do all of it. It’s just a matter of quality, speed and time. Anyway, it’s not the best cab necessarily, but it’s the next available cab off the rank might do the work. So the way we think about it is people’s strengths, and what do people enjoy doing? Because it was part of the self-selection exercise, we told everyone about what the work streams are working on, because our squads are embedded within bigger teams of teams. So it’s part of a change that’s happening within our business. And so I gave them an overview, we had the product owners come in and talk to us. And this is the work stream product owners come and talk to us about what the streams were working on what they were looking at doing. And then when we did the self-selection exercise, we said to the guys, this is what’s happening, these are going to be the objectives or outcomes that those streams are working towards. Here’s roughly what that might be on the roadmap, it’s being subject to change, because this is the first cut. Find something that you want to be engaged with, it was really useful because some of the guys in the team were actually disengaged from the things that we’re working with. I’m bored with it. Now I want to work on something different. So it was quite a cool opportunity for people not only to pay to the strengths, but to find something that they actually interested in. And it didn’t work out, because I wouldn’t get the first choice but you can try.

Shane Gibson: There’s always a risk that once you get patents are working, they become immutable. So you just double down on them. And you never sit back and go, let’s take a fresh look at those. Let’s write out some lines and redraw them because some change is good. And change is as good as holiday sometimes. So that ability to sit back and observe and go, we’re not just going to double down on the practices and patterns we have  now, but as we scale, but we’re going to look at them and say what would we need to change?

Tammy Leahy: Well, you have to listen to the feedback and the feedback we’re getting from the teams was very much that. It wasn’t a stagnation, but it was a bit of this, again, so that’s not great. You don’t come to work to say this again. You come to work to do something cool that you’re engaged in and that you really feel compelled with. So you listen to that and then you take action to help resolve if that feeling exists.

Shane Gibson: So watch out for the behind the scene there got the t-shirt just to close it out, go back to the community. So we talked about the squads and the coop, and then your community is this ability to have people outside the Core Data Professional group, engaging the literacy and that. So tell me how you’ve gone with that one, because that’s always a big challenges.

Tammy Leahy: We like good problems really. So it started off really as a change management exercise, and I hate those words. But when you’ve got a problem, you’re changing some tools on people, you’re changing a way of working, you want something different to happen typically, if you’re in a project management world, it’s change. So how do you manage the change? So we flip that around a bit and say, this is a cool opportunity, where we’re changing some things, we can change how we work with that something so we can implement a new paradigm around it. So rather than just putting a self-service tool, and let’s actually put a self-service tool in and create a community around it. So one of the examples was when we implemented our analyst tool, our analytics tool we did for the women, we did this in cohorts. So we started with a couple of groups that were really close to our team. And we’d worked with them really closely before we knew they had good base skills, and we could easily move them into the new tool. We ran intensive one week training sessions, which we’ve got support from our partners with. It was sort of morning time, sort of two hours come in, we’ll do in person training, it was all based around some  online learning, they could self-paced if they chose to. But it was almost a cooker long thing. We did that intensive one week, and then we had weekly drop in sessions, and we still run those so that that particular community is really strong, we’ve got a team channel with it. If people have a problem, they often say, I can’t take formats. I’m an accountant. So in Excel, I know date format suck, but apparently date formats kill everybody. So if people put comments in, I can’t get this date format to work, can someone give me, help me out? And then it was so awesome. We saw this chat that went to 27 different interactions. And it went from an analyst asked asking a question about how do I deal with this problem? Then another analyst popped in not even part of our team, part of a different team, who’d been one of these cohorts popped in and said, “Oh, have you tried X, Y, Z?” Than an engineer popup shows, there’s actually a much better way to do that. Try this. Then the first day I was popped into it. And then all of a sudden, they were five different people and people had learned from this interaction. So it was we had to nudge it. So the way we nudged it was by having regular sessions that encourage people to come. So there’s got to be a what so on it for me, no one’s gonna give you an hour of the week to come to a drop in session if they don’t see value in it. And so what we found is there’s ebb and flow with a little bit if there’s a bit more busyness in the business, we’ll see that lots of these business based teams won’t necessarily turn up. And we’ll say, not much talk about this week. Let’s not do it. But there’s always a topic, there’s always a share. So our lead analysts will line up, someone to talk about a problem they’ve solved, or a new insight they’ve gained, he’ll line up that to come and then talk about it and share it and that’s worked really well. And we also have a little bit more of a not exclusive, but a slightly smaller community with advanced analytics, where we’re trying to push analysts who are excellent in their domains, you’ve got a desire to learn more and grow more to develop more statistical skills, so push more into that Data Science, ML type space. And so that’s a smaller community where they share deeper insights, more kind of grunty learnings than the one that’s run at the drop in clinic because it’s open. And that’s the other thing. Openness is important. This is not exclusive, these drop in clinics open to anybody across our business. And what we found was our community grew much faster than we expected it to because our focus groups was one area of the business. And then all of a sudden, the other side of the business just started turning up. We’re like “Hey, nice to have you here. Let’s talk about some of your problems”. So it’s been really cool to get different perspectives. So we’ve done that for the analytics tool explorers, who we’ve seen a little bit of a pop up around the engineering practice, as well. And as that grows out, as we get more product squads embedded within other parts of the business that aren’t in our core group that will become more and more important as you start to, not standardized practice, but at least have some consistency so people can talk to each other effectively. So that’s been important. We do quite regular posts about sharing success stories. So we do a bit of storytelling. So if someone’s had a win, we’ll actually make it a little bit. It’s a little rah-rah because that’s just how we are a little rah-rah about it and share that and it’s nice for people to recognize and they do some cool stuff. Because often they just do it move on to the next thing. And there’s some amazing stuff that these guys are doing, and you just need to recognize it. So we do that. And then one of the other things that we did was we actually did a full on community building event. And it didn’t quite work out because we were experienced a little bit of a COVID spike, but we got drinks and pizzas, beers and pizzas. And there was there was, there was a task at hand, the task was because part of what I want to try and do is with this community is identify not product owners, but people within the business who care about the value that data can deliver. And then get them to help us articulate that value well. So for everything that we’ve got running on any of our platforms, on any of the tools, I want to understand, why does it exist? And what value isn’t enabling? Because if it doesn’t exist for good reason, and it’s not enabling valuable, why does it exist? So what we did is we called it a data insights, data and insights sharing or inventory creation, some boring-ish name, but the seller was come meet others in the community, we paid for people to come from down south up north, to come together. COVID meant that not everyone was. So we ran full hybrid, we’re everything we do, we run full hybrid, because we want to be open and accessible. And we started off with said, “Here’s a simple SharePoint list with some simple fields, fill in for everything you can think of that you’ve been using the new tools or the new community, things on everything you’ve done”, because you do so much in your day to day that you don’t even recognize as valuable. But as valuable, it’s created something. So we did that, had some drinks, had some pizzas. And it was amazing because it that created the sense of belonging. And we’ve had people more here and more in the customer research base go. This isn’t just a data and insights community. It’s a data research and insights committee. And they’ve been talking about is like a ‘we’ thing. And that makes me so happy. Because it’s not a ‘me’ thing or ‘my’ team thing, it’s a ‘we’ thing. Because the ultimate goal like I said before, is this needs to self-sustain, we should all be able to step back from this. And people are so connected, and they’re so passionate about the things they’re doing, they can get it to self-sustain. So the next iteration for us on that is figuring out exactly what needs to be true for this to self-sustain. And you can see pockets of it, where there’s more maturity in it. We don’t even we almost don’t even need to do anything, then pockets of it where there’s less maturity and you do need someone in there. But you do you need you need your advocates, you need those people in there who are going to give a little nudge every now and again if stuffs not moving or if you see things quieten down to understand, well, why is that quieten down? Is there a product? Is there a problem with the product or service like the data experience? Is there something wrong with it that we need to fix because it’s quiet and down? Are they just busy and they haven’t had a chance to connect? Maybe we just need to set something up to connect them. So it’s been faster than we expected, many more people came into it than we thought we would get. And that’s mostly because we’ve just been open about it. And we haven’t been exclusive about it. And we haven’t been wedded to tools, there was a change we were making to bring some new stuff in. But at the same time we’ve got patched the business, we’re not working on these platforms. But there were embracing them as part of the community because they know stuff that we don’t. I love building communities. I just love this stuff.

Shane Gibson: We could go on for hours. And we probably need another one where we talk about community building the cool stuff you did. But one of the things I pick up on the air, and it’s a term that I’ve stolen from you and use time and time again. And your love of nature is that idea of a permaculture, they’re actually one of the signs of success, one of the things we should strive for is when the people who started have left and it keeps on building without us. That’s what we’re striving for writers that we know is successful when that Permaculture is there and keeps building and iterating and changing the way it works without us so. So that’s pretty cool.

Tammy Leahy: One is if you understand, how trees are connected networks? So a tree by itself stands but underground is connected through a whole network of microbiology, I’m not gonna use the terminology. It’s effectively a fungus network. Sounds a bit gross, but super cool. So if you think about it, what we’re trying to get growing is that network that exists and connects all of the things you see above the surface. So to the leadership team, they see these cool things that create value, but below the surface, there’s this connected network of people. And if you think about nature as a system, network systems always have the best way to get resources to flow to the place and get knowledge to flow to the place. And so if you can create a networked way of working and I am not going to use the word data mesh because it is not that it is a networked way of working but maybe it is and then maybe I don’t understand that concept well enough. The idea is that you create that network that sits below the surface that’s semi visible but actually, that’s what the whole thing thrives on. Because without it, those trees are way less stable. They’re way less affected. You can see a forest that’s got a great underground system, there’s a forest that doesn’t, like it’s just amazing the difference.

Shane Gibson: Building something that where the network is supporting is great, we got to be careful, we don’t end up being ducks where we’re pedaling furiously. And we look like we’re doing it. You could take the journey you’ve done over the last four or five years, you could do a presentation at a global conference, how you’ve adopted data mesh, but , realistically, what you’ve done is figured out principles and patterns that enable you to distribute, decentralize the work at the  time, when it makes sense. And we have a whole lot of testing experimentation, and making sure it’s safe. So you could go down and pretend you’ve done at data mesh. But I don’t believe you’re the type of person that will pick up the latest vendor bullshit, and try and pretend that’s what you’re doing. But the principles, the principles of self-organizing team are in control of what they do the principles of splitting up based on domains, the principles of platform as a service, and the principle of, and we didn’t even get on to federated data governance and stupid committees, which we’ll get you back for another podcast on there. If I look at those principles, those are the principles you’ve been aligning with and trying to implement the years. There’s not just go and pretend that we’ve done database, because you’ve probably got more patents for how to do a data mesh than anybody else I know but just the way you work. You’re just striving for to achieve those core principles, because those principles have value.

Tammy Leahy: I don’t think any of us would say we’re anywhere near there yet. And in fact, I would even say we’re not anywhere near there yet. Because we can always see ways to make it better, we can always see ways to be more effective. And a lot of the things that we’re doing, I suppose this is probably one of my failings is I tend to “Oh, that’s awesome. That was great”. Recognize the success quickly, and then move on to the next big problem. But there’s just a pattern, we want to shoot for the stars, and we want to do some awesome stuff. So when people say you’ve done some good stuff, it’s so much more we need to do, it’s one of those things that we have. If you look at look back at some in some of the guys say, if you look back to what we’re doing six months ago, it’s a world of reference today. And I don’t get to see all of that anymore because it’s not either of us anymore. So you get little snippets of it from talking to people when you see how things have changed, and you see how engaged people are in it. And for me, it’s that thing of if you can get your network system of people working really well together. So all those things  coaching, team coaching systems, thinking all of that stuff, then you never will be there, because then the stuff changes too fast and there’s not as there. So I don’t think we’re doing more than anyone else. We might be converging on similar things to other people because it’s like nature. You get a dolphin and a shark. They both swim beautifully fast in the sea, but they’ve converged on it through a completely different evolution. And it’s the same as our team. Our teams converged on this way of working as other teams I imagined have and maybe they don’t talk about it either.

Shane Gibson: Maybe the teams that are doing well that aren’t the ones talking about it, they’re the ones doing it maybe that’s the key point.

Tammy Leahy: Maybe we shouldn’t ever do another podcast.

Shane Gibson: No, we should share, and I’m gonna hassle you to do more. Because I want to help everybody understand the patterns that you’ve applied, not the principles, because everybody knows the principles but the patterns are things that you’ve experimented with the head value and they’ve seen in context and the ones that you tried it didn’t have value but made it for somebody else. Because that for me that’s the gold, that’s what helps people was describing a pattern that they can experiment with. So it’s been great hour and a half. Thank you for your time. They’re good rabbit holes and we do come back out. So thank you for coming on finally. I really enjoyed that. And we’ll catch you later.

Tammy Leahy: Thanks, Shane.

PODCAST OUTRO: Data magicians was another AgileData podcast. If you’d like to learn more on applying an Agile way of working to your data and analytics, head over to agiledata.io.