AgileData #17 - Flying the airplane while building it - Jan Sheppard

Foreign.

Welcome to the Agile Data Podcast where we talk about the merging of Agile and data ways of working in a subscription simply magical way.

Welcome to the Agile Data Podcast. I'm Shane Gibson.

I'm Blair Temporo.

And I'm Jan Shepard.

Hey Jan, welcome. Thank you for coming on the podcast with us. What we normally do when we kick off with somebody new on the podcast is ask them to tell us a little story about their background so that the audience can kind of understand where you came from and how you got into this world of agile.

Excellent. I'll start a little bit earlier than getting into the world of Agile and start with getting into the world of it. When I was a teenager in the 80s and at high school I was school bought a computer when I was in the fifth form and I was really fascinated by this and thought wonder what that's going to do for my future. What ended up happening to the computer was it was put in the back of the physics room with a tea towel over it because I went to an all girls school and every day I looked at it and thought there's got to be more to life than this. And fortunately I was at school at a time when Applied Maths came in and this was the beginning of my initiation into the IT world. And it was if then else programming. And I was really excited to start off with but got bored quite quickly. So put down the concept of it being in my future until Y2K came along and got a job as a tester. On the back of answering a simple question, do you know the relational databases to which all I said was yes and the rest is history really. So getting in, fast forwarding to Agile, we were going through quite a transformation as an organization, wanted to harvest the value of our data and to do that we needed to work quite differently. And Shane just popped up as someone we should talk to, got him along and the rest is history. Created some magic since.

And one of the things I remember, I think from memory, this was probably the second organization I was lucky to work with back in those days. I remember you had this term and the term I've stolen and used relentlessly from that day on. And it was talking about flying the plane while building it. And the way I kind of explain it is you made a call at that time that to get this new way of working and to spend a year kind of building a new platform, building a new way of working for the team without delivering any value to the organization seemed like a crazy idea. So why don't we Try and do those changes while actually delivering something out to each of your stakeholders. And for me, that was really interesting because the amount of risk that you were taking to say we're going to experiment with this and there's a chance, in fact there's a likelihood that at many times we will fail, but we'll make sure we don't crash and burn in the ground. We might just take out a few trees and they fly for a while before we kind of get some altitude back. So, you know, how did you find that process given the amount of change you're making in the organization at that time?

It's quite interesting your perspective on how you saw it, because actually in my mind, there was no crashing and burning. There was no option of taking out trees. That actually wasn't a possibility until I've considered that until now.

In my mind, it was the only way to make the step change that we needed to. We couldn't go forward as an organization. We couldn't start using our data, we couldn't explore the possibilities unless we took that approach. We couldn't know everything up front. We had to just start and head in a direction. And learners, learners we went. And there was no prize for second, no option of failure. Therefore there was only success. So off we went.

And where are you at now? Because that was quite a few years ago. Has everything settled down and you're in a nice stable position? And I know the answer. Defined settle.

Defined settle.

Or are you still in an environment of constant change and constant innovation and constant challenges and inspection adaption and changing the way you work?

I look back on those days quite fondly now, to be fair, because the rate of change is so high, the rate of change is exponential. And while we were certainly pushing out into brave new frontiers at the time, and building the plane in the air was certainly our mantra at the time, the amount of change that we achieved in.

The space of time that it took was quite small to the amount of change that we have to be dealing with now in the same space of time. Our environment's changing, technology's changing so quickly that we just need to be going faster to keep up. And if we play this out right, it's for us to stay relevant as an organization, it's relevant as the data industry to be fair, because there is a future where robots take over and we're no longer needed. So let's get ahead of that one and make sure that we're doing the right thing for not only our organizations, but New Zealand Inc. And Data is a key and cool part of that.

And so how are you managing that change? Because I suppose I have a view that it's going to be incredibly noisy, it's going to be lots of fires, lots of things you need to plan for over time. So if I look at a time horizon, 12 months, we should be doing these things to get ready. Ideally for that to happen, you still got to run the business as usual. The daily operations, make data available for people to do that. How do you handle that chaos? And your role is because I think you're chief Data Officer now. So again, constant change. You've now got the title that in theory says all data is yours. Not that I actually agree with that approach. You're the person that helps people use data rather than do it. But how are you managing that chaos?

Yeah, I think there's two key elements that I'd call out as critical for success and one of them we picked up very early on and it was in the days when we were working together and that was the concept of imagineering. So we've embedded imagineering in our sdlc, so we now call it innovation. But the concept was imagine the future and then engineer your way back to how you make it happen. That's allowed us to take quite significant step changes and directions and feel safe about taking those changes because we know what the future looks like rather than taking one step and then the next. And always been looking out into an unknown. So that's been a really, really important.

Concept for us, the imagineering, because I.

Know you didn't concept of an innovation iteration over a couple of days like it was five days in a Dragon's Den. I think we even had a podcast on it from memory. Did we?

We did, we did.

Yes. We, we went through the whole pain and beauty of it.

In a couple of. Couple of hours. Yeah.

And one of the things I really loved about that was the Dragon's Den. The panel was relatively senior people from the organization that were sitting there and the teams were pitching their ideas. How do you get that buy in at that level? Do you think it's a one off because of the organization you're in? And you just had the right people at that senior level in the organization. Was it a, hey, can you just come and sit in this thing? And they turn up? Because in other organizations I've worked in, those senior people are. The diaries are booked out for years. Those kind of things are seen as frivolous and not the way they should work. So how did you get those senior People to the panel, to the table, to be part of this different way of working.

So I'll pick up on the second element for success here and that is around social license, which includes a lot of listening. So one of the reasons we were able to go so far is because we, we listened to what the environment needed and we responded to that. Not what the environment wanted, so not what our business wanted, not those who our partners on the outside wanted, but what they needed. And we used data to fill those gaps and to enable people to see new worlds through data and use an analogy of the matrix quite often to describe that. So it's a really important aspect in the approach between the imagineering and the social license that brought us a lot of Runway.

The senior people in the organisation, of course their job is to keep an organisation safe. So how this was packaged made them feel like it was safe. And then we demonstrated value and the world had changed because of using data and looking at things in different ways. And then it's like that became the new norm for them. We didn't put anything that was left field out there up front and we didn't plan 10 steps ahead in any one point, which is in line with building the plane in the air. We knew what we were going to do next. We knew the gap in the business that that would fill and that when we achieved that, we re evaluated what we thought was next after that to respond to where the organisation now was instead of where we thought it would be if we were following a linear process. So to have those people at the table, it was.

Kind of, there was a bit of gamification going on and unashamedly pimping data and what a difference it could make. So by making it something that was showcasing how the world could be different with a little bit of effort and inviting the whole organization along, it made, it broke some of the barriers. Anyone can do this. It has value. The smallest thing has the biggest value. Type. Type approach. So yeah, it was delightful actually, that there was the buy in and that changed how they saw the work that we were doing.

And I think one of the things that. I'm not sure we did it on purpose but you know, it was a very fortunate accident and one that I've seen working with other organizations where we haven't replicated that accident. We haven't had the same permission to carry to go forward. It became harder. And what that was was you, you effectively were looking to change some of your technology at the time. So you were talking to vendors and going through that joyous process and you ended up doing a proof of concept with some of your data. And so the team very quickly, you know, got hands on, created something presented and had either and I seem to remember it wasn't planned, but maybe it was. They'd stumbled upon a piece of information that nobody believed was true. And then when they showed the supporting information on what they delivered, it said no, actually these are the numbers, this is what is happening. And everybody focused on that and said, oh my God, we never knew that. And it became part of an organization wide initiative to actually use that information and change what you focused on. Do you feel like that ability to get that win really quickly, to show what was possible, gave you more permission to then kind of take a bit more time in terms of the way you change the way you work and take that risk?

Absolutely. And nice that it looked like it was just an accident. On the outside it was well constructed. On the inside, the, the choice of area that we focused on was specifically chosen because it was a hot topic in the organization. And half of the story we knew that what we were going to tell, but the other half of that story we didn't until not long before we had to do the presentation like quite the day before. And we were using our own data to gain the insight that we thought that the organization should be trying to, to look for. And we knew the good news story and we wanted to find something in the data that was the not so good news story and it was there in plain sight. So being able to visualize data means that we could see things that we couldn't in rows and rows of data in seconds. Something that would have taken an analyst months to uncover. And to be fair, we had never uncovered ourselves when we just looked at.

So that was carefully constructed. And yes, it was everything we wanted. And we've applied that model quite often. Even before we started, we started prototyping with using Excel and creating graphs around things that people had never seen before to try and get the excitement and the thinking about the possibilities, not just what people know before we even bought a bi tour and went down that journey. So the path was well calculated in terms of taking the organization on the journey so that when we got to the point of making a significant purchase, they were ready for it.

And how do you balance it out now? So when we look at different ways of working, one of the ideas is this balance between delivering the value somebody's asked for and showing them what's the out of the possible. You know, I think the Famous quote is Steve Jobs that says, you know, if I asked them what they wanted, they wouldn't have asked for an iPhone. Right? They would just ask for something else. So how do you balance that? Not building something, that nobody building something, and they don't come right because you haven't actually built the right thing for them, but not building exactly what they want. You know, what the product owner mandates. Because what I find is often product owners give you a solution, not a problem. Right. It's a really hard job to go into that product owner role. And they're often telling you what the team want to build, not the problem that needs to be solved. So how do you balance that out to make sure you're building something that is actually what they need or want?

And that's always a challenge because if you ask your business what they need, they can only say what they know, not what they don't know. And that's where the concept of imagineering comes in, that we work with them with a blank sheet of paper. What does the future look like? What does good look like to you? And so neither solution nor problem in there. It's opportunity and then work back to deliver the opportunity to them. The first step in this journey that I took, I think it's well worth noting because the first step in this was the rule of N1, introducing that when we were working in spreadsheets and SSRS reports and quite static things, whenever someone came to my team and asked for something that always got whatever they asked for, plus one thing more so that they could see that there was more, rather than just limiting what they're asking for to spark their imagination and spark conversations around. Well, what does this mean? How does this now add value to your. To your business? So, yeah, it's definitely a journey that you need to pace yourself on, but the key thing is you've got to start somewhere and you've got to start with curiosity and drive. Otherwise tomorrow will be the same as today.

And did you find that by allowing the team the space of a week to do those innovation or imagineering iterations, that that helped reinforce that part of the possible message with them? Did you find that the team started again? Maybe bring it back from what I'm seeing in other organizations, we talk about this idea of if we're using scrum of a Sprint. And what I've kind of identified over a while is it becomes a relentless grind. Eventually the teams are now working for 40 hours or 37 hours a week. They're not doing the stupid 80 hours or the hero behavior that some teams used to have, but that constant just every two, three weeks, delivering something onto the next thing, it becomes a grind. And so what I saw was that that week of innovation, they're still working on some things that have value. Right. But it is kind of a break in the cycle. It's a step change. And so that seems to refresh the team. Did you find that?

It was. Exceeded my expectations beyond belief, actually. What came out of the other end of that week, and some of it is it was certainly breaking habits, but it was empowering the team to solve their own problems, things that weren't working for them. Okay, that's what you focus on. Because the team, I had 21 direct reports at the time and divided them up into teams of four or five and I chose who worked together because it was people who wouldn't normally work together. So they had to form their own teams. They had to come to agreement about what it is that that group would focus on, a way of working. So they had to overcome all of those challenges, which was mirroring what happens when you put a sprint team together. But they didn't get to choose their own start point, but they got to choose their destiny. And how they molded and shaped each team was very, very different. So there were a lot of learnings to come out of that as a consequence of not only what they produce, but how we could then work together differently. That would be better. And yet for me, as an observer, it was just amazing. Absolutely amazing. I will say though, the one time I have perceived risk in the time I've been on this journey was Thursday of that week.

Oh, yeah.

Yeah. So things I had, I had a rough plan of I would introduce something random each day to like, kind of disrupt or change direction or refocus in a something, something else. And when we got to to Thursday, it was. It was. The wheels were falling off and I thought, well, this is a good way to limit my career. If I get to the end of the week, that that would be success. And then the teams, they came back together and they were stronger for having gone through that process. And I litched them. I only intervened a little bit here and there, but they found their own philosophy, they found their own way of working. They found new depths to their relationships with each other. And come Friday, it was. The magic just completely shone through.

So, yeah, so our team, if I remember rightly, come Thursday, we had a disagreement about what we were going to produce or the way that we were going to produce it. And I think it was a light bulb moment that we thought, oh, let's give two for the price of one. But that must have been scary for you.

Yeah, it was certainly a moment to reflect on, but that was the power of putting yourself in a position like that and that was the outcome. This team split and there were two factions within the team and quite different approaches and couldn't bring themselves back together. But why should they, why should they not unitedly present two different options to the same problem? So actually that ended up being twice the value than those who presented one.

Yeah, and I guess that's the.

A metaphor for agile really when you're putting people in from different disciplines into one team to work together. It's not the traditional testers over there, developers over there. So it was kind of a good.

Test and there's multiple ways to solve the same problem. Those both ways are right. You might have to pick one just for efficiency or for some reason, but both are right.

So I have a theory for those iteration sprints though, that you wouldn't want to do it with a team that are brand new and never started to change the way they work. I wouldn't use an iteration sprint right at the beginning of that change journey.

Because I think the teams have to know how to form themselves. We're putting them in a high level of stress really because we're changing everything. We're saying you don't get two to three, you don't get three weeks to deliver, you've got a week. You don't have a product owner coming in with an idea that you can work through. You're the product owner, you're not working in your normal squads or your teams. We're going to get you to self form again in that short period of time. And so my theory is the team have to be quite resilient. They have to have been through some of the pain and some of the joy of this new way of working before you could do that. What's your view?

Absolutely, yeah. Because.

The innovation sprint was the opportunity for us to take the next step in our evolution. So if you expect something to evolve that hasn't even formed, then.

That could go very, very well or very, very poorly. So yeah, the timing was quite critical because we had been going through the pattern, we were well entrenched and well established in the, the pattern that we had and it was good, it was working well to be fair. And so the future, which coming back to the earlier point is the rate of change was about to increase significantly on us. So we needed to find a new way of doing what we did. Same number of people, same structure, same style, but different approach to it and find new debts who had more to offer than if they worked in a different way. And equally who didn't have more to offer, who was at their maximum with what we were doing. And that certainly came out through the process in a way that turned out to be safe. No one got broken over it and everyone came out stronger. But certainly some were already operating at their maximum. Some had more flexibility in them to change. So timing is essential on that. It's when you're not. When you've hit your peak, but just before you hit your peak, which is.

Hard to guess, right?

Hard to guess.

Great. After the fact. Yeah. Descriptive model of what happened is always much easier than a predictive model. What might happen.

Yeah.

But so obviously for you to pick the right time, you needed to be involved in the team. So again, you know, you weren't when you took this risk, you didn't stand back. Right. You didn't go, right, I'm going to take this risk. You guys go and I'll keep an eye on it from afar. And one of the things I think you mentioned it, you know, 21 direct reports, one of the behaviors that I found quite interesting and now I've seen it very rarely, but I've seen it a couple of times afterwards is I always remembered that you did one on ones with your direct reports every week.

So with 21 direct reports, that was somewhere between 10 and 20 hours every week spent having a one on one conversation with every team member. And for me, in retrospect, that was incredibly valuable. That built a safety net because enabled you to constantly get a feel for where they're at and then bring that back and go, okay, we can maybe accelerate over there, but we probably need to slow down or put a bit more of a safety net around over here because things are getting wobbly. And so when I've seen other people do that, the teams have seemed to form and storm and norm better than when we haven't. And so much so that actually what I talk about now is this role of pastoral care leader. So one of the things I find challenging when you work into a new organization is as they start their journey, some person typically gets given the role of if they're doing a scrum, scrum master product owner, pastoral care leader, team lead manager and stakeholder manager. Right. And five roles coach, five roles in one day. And so being able to devolve and say, well, look, actually we need a scrum master to focus on that. We need product owners to come in and focus on that. But that pastoral care one, it wasn't until I saw the investment of time by you and a couple of other people that I'm like, actually it's something that we probably need to do.

And it needs to be embedded in your DNA rather than called out as a role that, like, it's a task, I think, because you can't achieve anything unless you have good people who are empowered to do amazing things, right? You can just turn the handle and produce another widget. But you can't be effective in today's environment unless you have good people that are enjoying what they do, being valued for it and adding value to the organization. And it was really interesting times. And you used the word risk again. And now I'm starting to feel quite nervous about what I've done instead of going, oh, yeah, that was quite a journey. The concept of the 21 direct reports was.

What has been called out as my riskiest decision in my career and.

By others. But the decision at the time, there was no other option. It came about because of having two teams. An information management team looking after all the reporting side and a data warehouse team looking after the data warehouse and building it out, but not the two teams not being connected. So while data was going into the data warehouse, it wasn't necessarily coming out in a way that supported the business. And the reporting team were doing what all good reporting teams did at the time, and they had their own database that they were putting the data they needed into it. So the bringing the teams together and effectively creating a startup with 21 direct reports was in response to that. The only way to break that behavior and that culture was to break the shackles that the team.

Meant and the culture that was around it. By creating a startup and putting everyone in together, they're all equals. And that's where agile was a really important tool for bringing people together into teams, bringing the developers and the analysts together and them getting to know each other. And by finding that by working together, they can achieve some great things and getting to know the business that they're in. And so, yeah, agile was very, very important to that process. But when I floated the idea that I could see no other way than effectively creating a startup, the pushback and from those who care about these things and it is their jobs, including hr, that you should never have more than eight direct reports or you create a new.

Layer in the hierarchy. And it's like, but that won't work. It won't get us where and it's like okay so be it kind of thing. And off we went. And it worked. It absolutely worked. Because the things, the artificial barriers of the team structure were stopping us from moving forward. We've certainly moved on from that as the teams experience expanded as you touched on do have data end to end which is absolutely fantastic. And now it's keeping with the functions. Teams built around the core functions with team leaders so they're leaders in that function. And maintaining the horizontal way of working is the next step in our evolution to meet the changing environment that's coming. And I haven't yet come up with what the next structure is, but I'm sure I will. The times, right. But all the way through this it's been the people, it's been a lot of the same people from the beginning in this journey and they've had to believe in the vision, they've had to believe in that this is the right way. Absolutely delighted in how people have grown and evolved themselves. The skill sets they've picked up the way of working. Absolutely amazing.

And one of the things for me is if you do about 21 people, that's a large group of people. And in the area of data and analytics it's a hot market. There's lots of jobs and lots of cool stuff to play with and you've had quite low turnover from memory within your team. And it's not because your organization has sleep chambers and free lunches and share schemes. It's not that. Do you think, why do you think that is? Why do you think your team have been quite stable in terms of working for the organization and working together?

I think it's them actually is why they've bought into this way of working and this vision and they've used it to grow and evolve and that they, they bring their best selves to work and they, they thrive. Right. They thrive in this, this environment and as a result we achieve some pretty phenomenal things. And that's cool.

And I think I come back to your point about the word risk. You know what I've seen over the last couple of years is most times I'm getting engaged is not because the organization as a whole has decided to adopt an agile way of working. There's an organization in Wellington, it's been through this change and actually took out six or seven layers of middle management because they actually did do a top down one that said we're going to try a new way of working as a Result of that new way of working. They decided that those hierarchical lead roles, those teams of eight, didn't make sense anymore. And so they actually restructured their organization, removed the them. But most organizations I work with, it's somebody with the ability to influence or make the decision for their team to try this new way of working. And often we can't use the word agile. I do remember when we started this journey, it was don't use the word agile, use the word iterative. Because agile had already had a bad name or a new way of working. Yeah, a new way of working. So there is risk there for effectively, what I call the shit umbrella, right. You need somebody that has got the, the mana or the ability to make the call and help their team be really effective and find this new way of working. But they're effectively becoming the shit umbrella and they're wearing a lot of the risk from above the umbrella if things don't go well. So, yeah, my view is maybe risk isn't the right word, but it's definitely there.

Umbrella.

Yeah, yeah, yeah, look, courage.

We'll use that word then, shall we? And with a small dose of ignorance. If you don't look for what could go wrong and you deal with it when it comes up, it's a much happier journey that you go on. And Absolutely. Like.

Like building a plane in the air. This should never have worked. Right. And in the early days, I used the analogy of bumblebee. I can't explain why this approach worked. I have no idea why it worked and why we've sustained it for this long, to be fair, because a lot of other organizations have tried going on the same kind of journey they've got so far and then they shut down. We've been doing this for quite some time now. So, yeah, it almost feels like it's the bumblebee. This approach defies gravity, but it's working, so don't question it.

But do you think that's because we didn't start off with a methodology in mind? So, yeah, as things become hot, the big data bollocks that became hot in the marketplace, as things become hot, everybody buzzes around it, right? And then they want to codify and they want to create a methodology, typically, in my view, because you can sell a method on, right? So they all want to standardize it and have a certain way of working and that's the answer. But actually it's just a way of thinking it is a way of working and that way of working has got to change. So, yeah, the bees do buzz around, but there's always a hive. And as long as you're changing for, you know, as the environment changes and the teams are empowered to adapt their way of working, not stick to the mantra that they had a year ago because that mantra probably doesn't fit where you are today, probably won't, definitely won't fit where you are next year. Do you think that's it, is that you've let the team constantly evolve and manage that change?

We have had to constantly evolve and there is a next step and as I said, I don't know what that looks like yet, but it will, it will come clear when its time is getting near. A real test for.

The impact of this type of change is when we were going through yet another restructure as an organisation and that was the end of the startup structure and moving into, and we'll use the overused term centers of excellence around each function because we use that rather than the word teams, because teams immediately create silos. And as the change document was circulated around everybody and showed a typical HR hierarchy with the box at the top and all the direct reports.

The vibe of the team changed and I didn't know why. Like quite suddenly the whole room was, it was quite very, very different. And I looked at people's screens and they were looking at this hierarchy, this traditional hierarchy and they were all going into anaphylactic shock.

The fact that they were going to be forced back into a box was most unpalatable thing. They'd gone too far and they had enjoyed the freedom, the way of working and what they could achieve in the way we had. So, yeah, it's interesting how people respond and certainly the next message is that's to help us be stronger in the functions and of course we'll continue to work in a cross functional agile way because that's what makes us succeed.

Yeah, I think you're right. I think.

The ability to map it back to something that you thought you knew, like a hierarchical org chart brings of it all the behaviors that comes with that org chart, even if you're not working that way anymore. There's that perception that, you know, when you see the word team leader, actually they're now going to dictate what works done when rather than be the pastoral care leader, which is actually we need to scale because we've got too many people for you to spend an hour every day. So we need somebody else to take over that loving and hugging, right. And you know, making sure everybody's safe. So.

And that's pretty Clear feedback that the team lead rather than the manager.

Absolutely. That they had a leadership role, leadership in their function as well. So we could continue, continue growing out.

And that's where I think, you know, there's a thing that's Spotify published some ways of working when you scale, which was the way that the airplane ended up flying for a period of time. And as I said before, what happens is people then go. That's the answer. So everybody called it the Spotify model and then started implementing exactly the way Spotify did. Spotify got quite upset about that. And actually it's a detrimental to the way of working because actually they've now said they're not going to publish any more about what they've changed because they didn't like the fact that people started treating it as a methodology, not as, hey, this is what we did, give it a go. And more importantly, they said, if you do something different and it works for you, could you let us know? Because we wouldn't mind trying it. But again, that was their idea of how do you go from a group that's small enough to work together to then scale out to 50 groups that actually still working across each other or near each other or impacting each other. How do you do that successfully? Scaling's hard.

Scaling's hard enough. If you use the Chinese proverb that you never stand in the same river twice, it's exactly that. And how you operate as an organization, how you structure your own teams. So Spotify, that model worked for them, it worked for them at a point in time, and it got them to somewhere different. No other organization standing in the river at the same point. They're different, they've got different cultures, the environment is more or less advanced than the one Spotify was operating in. So there is no such thing as.

A recipe for guaranteed success. And that certainly been.

See, wouldn't you give me that riverwater a year or two ago? Because one of the things I learned was having come from another organization where I was helping them on the agile journey to yours, I thought I knew the answer. Right. And actually what had happened was that team had grown and when I started working with your team, I naturally started them off at the level the other team was, if that makes sense.

Yeah.

And they. And I got blank stares. You know, it was like, what do you mean? You don't understand this? And it was like, oh, duh. Actually, the other team has got to that level. I've got to start at the beginning. The next organization I worked with, the team I Worked with after yours. I was like, right, now I know how it works. Start at the beginning and these are the steps. And again, epic failure. Well, not epic failure, but, you know, lots of learnings. Because that team grew differently. They implement things in different orders. Some things they didn't implement, some things they found a better way of doing it. And so that analogy of actually it may look like the same river, but you're never actually at the same point in time in the river and it actually isn't the same. Is perfect for that way of working. There you go. I'm add that to my toolkit after fly the plane while you're building it. Yeah, it's gonna be.

So is there a certain test you do to find out what the maturity of the team when you on board them, does it.

No.

Gut feel?

No, for me it's observation. So I have a mental checklist in my head that over the years I've. I've kind of said these are the things I want to look at and just observe. And I thought about codifying it, but then I'm like, as soon as I codify that into a checklist, it's an anti pattern. Right. Because now I've got a methodology and actually you need to watch the team in their bat in their thing. One of the examples was one of the checklists in my head I always do is team noise. So observing how often people are moving across their desks and working with other people. And so, you know, that gives me a sense of some stuff. And one of the teams I was working with, you know, they were quiet and as we started our journey, they stayed quiet. And for me, that's an anti pattern. Right. When I see the team, the noise not going up, I'm going, okay, we've got a problem. What I didn't realize was they were incredibly mature at communicating digitally. So they were constantly chatting to each other online, even though they sat next to them. And that was the way they worked and that was successful for them and they weren't going to change that because there was no reason. But I couldn't see that. And it wasn't. You look and you go, ah, yeah, that's. Yeah, you're actually.

You can't think other failing.

I can't think. I think we might have something we need to work on.

Right.

Because that's for me, is all it's about is, okay, have a think about this. Is it working for you or is this something you should focus on changing? And if you're going to change it what would you think you'd do? But yeah, you fall into that human habit right of here's my checklist.

And the vibe is the most important tool you can have. And when you talk about pastoral care and all of those good things, you can distill it down to that one thing. What's the vibe of the team? Who's out of sync? Is it quieter, noisier than the norm? And the norm does change over time, but certainly you've got to be on top of that and that comes back to the time that you give your people. So when the startup structure was forming and having the 21, it was 21 individuals that I'd put together and trying to build into or unable to build into something. And by giving everybody time, I got to know more about them, what their A game looked like, why, what else was going on in their lives. It meant this needed to be an easier week for them, or what their hopes and dreams were, how much capacity they had. And by being able to unpick all of those things and then build it back as a team, it didn't matter if someone was having a bad day because something was going on at home, because the team adjusted around them. And it was interesting. There was one bad hire.

In this time and the team dealt with them in an organic way because they came into the team, they disrupted the team, accepted them, almost like surrounded them to start off with and to bring them into the way of working. And essentially the Vibes, the rhythm of how the team worked and that everybody was expected to contribute, have their say, no one got dismissed. If they said something out loud, you'd get told off if you didn't say something, if you sat on it. But this one person didn't take well to that kind of environment and became dismissive. And it's almost like the team just didn't react to that. They just left them behind and moved over and they became isolated and therefore lost their ability to disrupt the team. So it was quite. The team dynamic is quite an organic thing. And when it starts working like that.

It'S something pretty special.

And what I often talk to when we start the journey is depending on the size of the team, especially when you're in a bigger team, there will be people who decide that they don't want to work this way. They give it a good go and they're more than capable of working this way, but they actually go, you know what, I'm not really keen on doing this. This is not the way I want to work. So they Kind of vote themselves off the island and we have to have a clear understanding of how we're manage that. Will they move into a different role in the organization? If it's a team way of working, not an organization. If the organization is going to work that way, then how do we help them find something that they're going to be happy in? And the second scenario is when they get voted off the island by the team. And you'll see it time and time again. Like you said, the team swarm around and onboard them and help them and then they see that they're struggling so they actually really interested in behavior. They then start spending more time helping that person to get them up to their velocity. So the team velocity goes down while they help that person. And then you get to a stage where they go actually for whatever reason you're not making it. And then they just isolate them. And so we need that pastoral care person to be watching that because often, you know, there are times where it's not the person that's, you know, they're going through something in the personal life.

Absolutely.

And so having somebody who's connected with them, they can then say, you know, okay, well we just need to be, we need to keep that person safe because they're a little bit fragile at the moment outside of work environment. It's really, really important. And I think that's something that we don't talk a lot about in Agile in the way we work, that keeping people safe is really, really important when they go through this level of change.

And it is, change is hard, it's hard on people. And so it's a wee bit about making it.

Mild disruption. So it's part of every day, not that you get established into a pattern and then tomorrow you suddenly do something else. It's that constant evolution as such and it's strengths. Some strengths are emphasized now and de emphasized later or that continuously molding and growing and where some skills are more valuable now, how do you bring them in as you head in a new direction. And I think a real key to that is to have a balance of diversity in the team so it has more resilience. One of the things that we did because we were pretty top heavy to be fair, we had a lot of senior people and certainly intermediate and had no junior people in the team. So bought some junior people, started hiring straight out of university or Polytech even. And that's added another dynamic to the team because it's a different way of thinking. There's no patterns of work experience before there's a lot of, a lot to learn about how to be part of an organization, new skills and all the different outlook on life even and the.

Fact you have to wear pants when you come to work.

That brings. But that's added an extra layer of resilience to the team to be able to adjust, to be able to continuously adjust because we're challenging ourselves with a different lens on diversity of thought on a daily basis.

Us, cool. I think we're pretty much there for time, but I think the, the key thing there is, you know, change is constant and, you know, we probably need to do another podcast in a year's time to see whether you're still flying one plane, 100 planes, fighter jets, what's actually happened.

Absolutely. Thank you. This is, this has been great.

Excellent.

Right. Catch you later. Thank you.

And that Data Magicians was another agile data 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.