Leveraging Workplace Personality Dynamics & The Essence of Business Value

Ryan Purvis  0:00  
Hello, and welcome to the digital workspace works podcast. I'm Ryan Purvis, your host supported by producer Heather Bicknell. In this series, you'll hear stories and opinions from experts in the field story from the frontlines, the problems they face and how they solve them. The years they're focused on from technology, people and processes to the approaches they took, they'll help you to get to the scripts for the digital workspace inner workings.

Okay, get a new

Stephen Russell  0:34  
MRI, I'm just testing. Let's try and get myself set up with a decent microphone. Can you hear me right? Yeah, I

Ryan Purvis  0:46  
can hear you fine.

Unknown Speaker  0:48  
That's fine.

Ryan Purvis  0:50  
Let's say in a nice sunny day by Judy.

Stephen Russell  0:53  
Yeah, nice. Nice. Spring is spring and spring in

Ryan Purvis  0:58  
spring a spring. It's so weird because I you know, normally would be in the same boat. But now I'm like, I'm going the opposite direction. We're going into August. I mean, it's an autumn. Although I mean, it'll, it's cold in the mornings. The cold is like 16 degrees. 17 degrees. Yeah, but it feels cold. Because you so used to 2530 degrees?

Stephen Russell  1:18  
Yeah. I was. I was on a call with one of our colleagues in Singapore. And we temperatures really dropped to you know, it's come from 32 to 31. Today. Me a fine.

Ryan Purvis  1:34  
Yeah, never changes much there. I don't think it would be not to LA, and they get five to five days of bad weather a year. Otherwise, there is Thomas's perfect, I can understand why over there. So so healthy, and and well built in little less stuff.

Stephen Russell  1:50  
Yeah, yeah. It's a big difference.

Ryan Purvis  1:54  
It is a huge difference. A huge difference. Right? Do you want to give yourself a bit of an intro? And then we can crack on?

Stephen Russell  2:01  
So yeah, so I'm Stephen Russell, I am I kind of probably lean a little bit of a double life. I'm founder of shimmy technologies. And, and what we do there is we tried to connect the performance of the workforce to customer success. And to a little bit about that. And but I also work with businesses in a capacity as a consultant from a product management perspective. So currently working with great companies singular decisions on their subscriber intelligence, so looking at how subscription businesses, particularly in the paid TV space, and can understand the relationship they have with their customers.

Ryan Purvis  2:40  
So what I mean, we talk about workforce productivity. I mean, what does that what does it actually entail, especially nowadays with people working from home? And how has that changed? You know?

Stephen Russell  2:52  
So I think that's, that's a really interesting question. And I think there's, there's kind of two perspectives, one of which is really easy to get your head around, and the one that people default to, and the other one is a bit harder. And can sometimes you can get a bit philosophical about it. So the two ways you would think about it is how much work people are doing, and completing county tasks or getting thrown in a day. Or you can connect it to kind of customer value, and how much customer value is being generated. And then they're not the same thing. And there's a lot of busy people doing busy work and not necessarily generating value. So yeah, that's that's how we think about it, we try to understand, you know, for the time that people are putting in, because at the end of the day, that is the the limited resource, the one that nobody has any control over for the time that people are putting in, how much value is being created? And what are the things that are blocking them from creating more value with the time that they can spend?

Ryan Purvis  3:54  
Yes, so you made a comment about busywork versus customer value work. And we were told a meeting the other day, and how many meetings how those have increased, you know, having many fold. And trying to get that back to a unit, the GAO worked out a formula for that.

Stephen Russell  4:09  
And we're still working through it. So we've got a couple of projects that way, we're doing validation on at the moment, and one of them is, is meeting analytics. And so the other time and some of the others, so as I've mentioned already, you know, connecting people performance with customer success, and then the third one, and probably the most in the wrong order, but that is personalities, and understanding personality dynamics, which I think now, probably more than ever, and personality is is such a big driver of individual performance and in terms of people's ability to create customer value. And I think that's one of the areas that you know, it really interests us, it's always interested in us, but I think even more so now. It's probably the thing that people aren't really talking about but and personality dynamics and things have been around for ages and some people love this. Some people roll their eyes. And the reality is that people are different. And those differences are both valuable and destructive in different ways and in different settings. And I think when it comes to meetings in particular, so the work that we talked about, where we were trying to understand who you spending time in your meetings with who you have, when you have successful meetings, who you with when meetings, maybe go off the rails or are less valuable. And what we're what we're looking to try and validate is, or understand, I guess, is the place that personality plays in that and really coming at it from the perspective of as a manager, what can you do to ensure that you understand the personalities you have in your team, and you're taking steps to address the gaps or give people the opportunities that they would need to perform and to contribute in the best possible way? Because people weren't there for themselves, it's their own personality.

Ryan Purvis  6:00  
But now you are you deriving the personality from analytics, as opposed to doing like a Myers Briggs or enneagram, or any of those sorts of tests beforehand.

Stephen Russell  6:09  
So the latter, and now the deriving it from from behaviors and from analytics is something that we are interested in and have looked at. And the reality is that, obviously, we're a very small kind of, we're in Star mode with doing obviously, a lot of validation. And so, for us, it's about making sure we put our innovation and our time and attention into things that we think are new and different, and are going to make a material difference to the way people work. And there's so many psychometrics out there, that we haven't at this point needed to do any of that kind of inference from data, I should probably take a step back and say, you know, at the heart of everything that we do, is this philosophy that there is there is a connection between fundamental factors that influence performance. And we're trying to understand that graph of performance factors in detail. So we can take signals from certain data sets, and sort of try and interpret those. But sometimes it's just easier to ask the question directly. Yeah, sort of, I guess, a long winded way of saying, Yes, we used personality questionnaires, to understand personality at this point. But then understanding that in the context of the performance graph, and the factors that influence performance, that's the bit that we think we're doing that that, you know, is new, and maybe helpful.

Ryan Purvis  7:43  
Two questions are the mentals. You mentioned what what are the examples of those fundamental behaviors?

Stephen Russell  7:50  
So there's hundreds of them. And it's kind of hierarchical, essentially, somebody described it as kind of a pixelation of performance, which I quite like that, that description of it, but but really, there's sort of five areas that we really focus on so. So process, and within the context of process, you'd have things like, a processes defined, are they understood? Are they efficient? And are they applied? Right? So it's all very well having a process but if people ignore it, so we've got kind of, you know, what's the procedures that are required to execute the work that needs to be done? And then you've got expertise. And that's obviously the ordinary stuff you'd expect, like learning, development and certification. There's also situational awareness, right? situational experience, have actually done this before? It came time. Right? So training is one thing game times another, how much game time have he got? So that that's, that's the expertise angle? And we then look at things like, agility? So to what extent can this work be done in isolation of anything else? Or is it dependent on other work? And to what extent can people make their own decisions? Do they have the data that they need to make those decisions? So that would be the agility angle. And the alignment? One is obviously the kind of classic stuff around, you know, to understand the vision, what the goals are, what the endgame is, why we're doing it, but kind of the meta stuff that keeps everybody moving in the same direction. And then energy, you know, to what extent are people applying themselves is that they feel motivated to do that work? Is it the sort of thing where they want to go the extra mile? Or is it something that is actually a bit of a bit of a ball like I don't really want to and, and, you know, people feeling fit and well and healthy and are they feeling under pressure stress, they got the right level of stress. So underneath those five, cap those, those five, kind of what we would say characteristics of the work. So if you think you've got the personality of the worker, and this is the personality of the work, and the personality dynamics of the work would be process, agility, expertise, alignment and energy. Those are the those like our big five, if you like, in the way that you'd have extraversion openness. agreeableness, that

Ryan Purvis  9:56  
yellow ocean was the acronym for that. Host right? Yeah.

Stephen Russell  10:00  
I mean, all those all those methodologies are built around the big five and this ip ip, which I forget exactly what ip ip stands for, but it's essentially an index of personality statements, which you can use and they they're positively or negatively keyed to certain personality factors. So that's, that's essentially how we map fatigue.

Ryan Purvis  10:23  
So the second question I had around that was, are you trying to answer questions like, if I need to brainstorm an idea, these are the people I should have in the room. If I need to do something operational to solve a problem, these are the people I should have in the room. And if I need to do something creative, or whatever problem solving, I have these people that you might have overlaps. And, you know, obviously, diversity is important. But is that what the software is trying to try to help the, the decision maker with their decision to make a terrible language? But you don't? I mean, I think

Stephen Russell  10:58  
so. So I think it's a, I think I understand where you're coming from, I'd say no, that's not what we're trying to do at the moment. And it doesn't necessarily mean it's not something that we wouldn't kind of go in that direction. I think what we're what we're trying to do is, start at the beginning, so make people aware of what's actually going on. So we talk about hidden risks, and we talk about sort of the unspoken truths of, of the work that's being done. And so, you know, highlighting to, to management in particular, but then also other people in your circle, who you might need to collaborate with, where you feel that some of those factors might be a challenge or a gap. And making sure that other people are aware that you feel like that or making, making other people aware that those things are true, means that that's where the attention goes. So we're not necessarily getting as far as saying, you know, you've got this type of challenge or this type of problem where you are, this is the this is the agenda of your meeting, these are the people you need to bring. And, but from the agenda of the meeting, or understanding the work topic, you know, the the work item of that meeting is about understanding the characteristics of that work can mean that people's attention go on the right things, and that you don't get caught up on stuff just because it's the loudest voice in the room. And but also, when people come together for those meetings, do they all feel the same way? Or is there a subject matter expert who people should just sit back into 30? Not particularly casing? That makes sense?

Ryan Purvis  12:28  
It does. Which leads me to another question. If you come across, okay, ours,

Stephen Russell  12:32  
you know, we use Okay, as I've used like cows, and pretty much every, every role for the last 10 years or so, all I needed, I

Ryan Purvis  12:42  
needed a consultant, I should have got you to come in.

Stephen Russell  12:45  
Probably not because I didn't tell you how to use okrs. But that's different story.

Ryan Purvis  12:49  
I know we'd love to have back there. But but that's what I was trying to get. Why why brought that up, because we're about to do this now. And one of the reasons why we're trying to do this is we have a technology team, we have a risk team, we have a American expert team, and we have a couple other teams. And we're trying to get everyone to work together a little more, you know, the usual words efficiency effectively, etc. And we thinking that, you know, we have, we have a quarterly plan, which, you know, someone has to maintain and manage. But what we're really trying to say is, we have these objectives, and we need to meet those objectives in the quarter. And we need everyone's and everyone to be aware that when you when you agree to these objectives, that's those are the priorities. That's what you should be working on and not not get caught by the sort of magpie effect or something else shining this shooter past and it was a squirrel, you know, it takes that takes the thing away. So that's why we're doing another okrs. Now, would you with what you're doing with Schumi help in alignment like that, because you said you mentioned hidden truths or hidden work. That's the thing that hurts you the most is the work you're doing. That's not a priority, or not aligned to the priorities. But is it also a priority? If that makes any sense? Because as you said, it's just a loss at the time.

Unknown Speaker  14:07  
Yeah, it does. I

Stephen Russell  14:07  
mean, there's a lot to unpack in what you just asked. So I try and give a coherent answer. So So I guess you start with why, why are we doing okay as and I think from what you just said, you know, that it's about not getting distracted. And, and it's about making sure that people are working on the things that are going to contribute most of the organization's success, fairly straightforward. That's why that's why people go to okrs. But I think it's very easy to get caught up in the procedure of okrs. And you got to ask yourself, really what what's important So, firstly, why are people getting distracted? And because I, I tend to start from a position that people are generally good, they generally want to do a good job. Not everybody wants to go above and beyond. Not everybody is interested in permanent that everybody's massively aspirational, or what's the word ambitious. But equally, people don't tend to turn up to work and think I'm just going to go and do something unhelpful today, or I'm going to go off on a tangent. And so generally those people are doing those things because they believe they are valuable. Right. So that's, that's my starting point. So then the question is, well, is that a problem because it's taking resources away from the other things that the business feels are more important? For too long, right. So time is the resource that none of us can control. It's the limited resource that none of us control. So where people get frustrated with that type of stuff is is when a job hasn't been done. And the thing that the magpie, the magpie distraction, has eaten up the time it should have been spent on it, right. So nobody cares about the distraction, if the thing that they care about got done as well. Yeah, yeah. So so so I guess what I'm trying to say is understanding what people are spending their time on, and where they're successful, and understanding why they're not successful in certain places. You don't need okrs for that. And actually, okrs can help you feel like you're making progress in terms of alignment, when actually, you're not getting that much further. So I've seen I've seen organizations go through okrs process processes. And at the end of it, what they have that they didn't have at the beginning, was a conversation and a spreadsheet. And I say the conversation is the important piece, do I understand what it is that I'm that I need to be doing and why it's valuable to the organization. And then the second piece is, will if I discover something else that I also believe is valuable, that wasn't part of that original conversation? To what extent Am I allowed to go and work on that and try and create that value. And people should have the freedom and the autonomy to take those opportunities when they come up. But equally, the company in the organization needs governance to say, Well, okay, you're now spending too much time on it, or that is now taking resources away from something that we deemed to be more valuable. So, okay, as it's helpful, in a way, I tend to feel like it's been more for much, much bigger organizations than the ones I've worked in. I think when small wins when I see small organizations doing okay, as they tend to be a side project, and they tend to be something that HR care about a lot more than people at the front line. And which sounds horrible. I know, HR friends of mine, he'll be telling me after saying something like that, but that's just my experience on

Ryan Purvis  17:36  
it. Yes, I mean, I was chosen from the CEO. Which which I look, we haven't we haven't gone through the exercise. So that's one of those things and see what happens in in three, six months. I mean, our challenge is that you got these different pockets doing the things that that that there are priorities for you for the team. But they don't always link up with the general, you know, organizational priorities. It starts getting done, obviously. I mean, I wasn't would be here, but, but it's hard to find that even even more seamless environment, I guess.

Unknown Speaker  18:09  
So what would you use it? I

Unknown Speaker  18:10  
didn't use it.

Stephen Russell  18:12  
So let me let me take let me backtrack slightly and say it's not I don't necessarily advocate for not using it at all. But just I think it's often seen as a panacea, right. So let's say let's say the organization successfully implements okrs. And everybody knows what they should be doing, and understands what, what success looks like, okay, of the five things that we believe influence performance, you've really only touched on one of them, maybe two of them, right. So you're, you're now very well aligned, everybody's moving in the right direction. And everybody's work is contributing towards a common goal. That's brilliant. And that's a really important thing. But the actual work that is then being done, and the work that produces those key results. okrs isn't gonna help you with defining good procedures for that, or making sure they're implemented. Okay, ours isn't going to make sure that you've got the right people resources to the right tasks, and that they've got the right situational experience. It's not going to help you motivate people, and it's not going to help you kind of manage pressure. You could make a case for the fact that it would, but you'd be retrofitting and, and, and, you know, it touches on agility, it touches on people's ability to make their own decisions. Like if you've given them that, that alignment, you've given them that clarity of the end goal, then yes, people will be in a better place to make choices for themselves. But you've not necessarily given them the data they need to make those choices. You've definitely given them the confidence so you know, okay, as a great, they're a powerful tool for alignment. But that's like saying, You're only going to deal with introversion extroversion, personality dynamic and you're not going to worry about agreeableness or openness or any of the other things that make up the person's personality and contribute today, who they are at work. So, you know, when you're thinking about the character of the work. Okay, as a helpful for making sure that alignment pillar is, is nailed on. But there's, that's one of the five

Ryan Purvis  20:23  
I see your point, I mean, I think we're already looking for alignment out of it. All the other things you mentioned, I mean, that's what you rely on, maybe we go into product management, now we get the technology focus would be based on building things that will have high value to the customer based on a prioritization agreement, you know, framework of some sort. And that handles the processes of what about what am i building this sprint and what I building next sprint, and, you know, what's the vision for the next quarter or whatever it is for the product. And that should marry up with the objectives that are now part of the Okay, our exercise, but all the things that go with building the product or other tried and tested processes and procedures, and, you know, the sort of agile methodology in Scrum, there's things you would do that their own processes that own procedures. DevOps is another one where you'd have a whole bunch of agreed, I don't want to say rules, maybe principles, on you know, releasing, often, and small pieces of work that's been tested and an epic bang, yes, those sorts of things. Is that sort of we used, were you going?

Stephen Russell  21:33  
Or? Yes, I think that's, that's the point I was probably trying to make him maybe overstate is, you do need an alignment, you don't need okrs to achieve alignment, you definitely need alignment. And and there are different levels of work, right. So there is there is the frontline work, people doing the work. And then there is governance and management of that. And so you do need to be able to express it in different ways for different people in different settings. And so, yeah, that I think that's where I was going with the comment about agility, you know, when you're prioritizing a backlog, and you're prioritizing the work that is going to be done, and you putting that in an order has to be those choices have to be driven by higher and higher risk, probably the wrong word. But you know that the organizational objectives, you know, what are we trying to achieve for the long term, and, but equally, you know, those objectives. And again, it depends on the size of the organization, if those objectives don't change very much, then maybe okrs work a lot better. I've worked more in businesses that are small, rapidly growing and often require a lot more agility. So understanding those objectives requires strong conversations and and upfront discussions about the business value that we're trying to generate in the customer journey that we're trying to generate. And not just, you know, what working with one of them is more valuable than another in isolation? Probably a slightly incoherent answer to your question. I'm very sorry.

Ryan Purvis  23:14  
No, I think that's when you get down to the point that I think, I mean, I struggle with us. So to win, and specifically with working with with guys trying to build a product, what is what is value? You know, value is such a vague, and maybes, because it's a V. A vague term, you know, how do you how do you generate? How do you decide what, what is valuable? Because if I look at look at high load, for example, there's the the key thing there is we rely on data from our customers in order to provide a risk output that tells them where to focus on to avoid people dying. So so the value there is, you know, pretty, pretty clear, you know, how do we make that happen in the quickest possible way, so that they know where they need to spend their money to save lives. But then you break it down into the next level down. So we now have stuff we have to do for our internal people to make their jobs easier to get through the data processing the the the report writing the you know, all the things they have to do, versus what the customer has to do and giving us their data. And you see this constant back and forth thing where we try to take the effort manual effort off the customer. But in order to do that, we have to bring it in internally to the business first, and then we can look at systematizing it, you know, then it's a case of Okay, well, now we've done so so I'll give you sort of background to this. When I joined harlot two and a half years ago, we were using a very complicated Excel spreadsheet full of macros that every customer would go and copy the data into. And then it would process the data in the Excel spreadsheet. They would then get emailed into a central team, who then manually would move it out of that Excel spreadsheet into another spreadsheet and do the risk calculation. Okay, if you can imagine how difficult that was to do for for 10 customers. When I joined, we had 19 customers, we now I don't know how many we've got now, but it's a lot more than that. And the only way to scale that is to take away the load from the end user. And other problems, which I'll talk about now, and bring that inside. So other problems we had was they weren't sending us all the data, for example, now they sent us everything. Because there was a level of, well, this is too much work for me to do. So I'll just send you two or three records versus the 300 that I've got, because it's quicker for me to just do three and shifted on. Now they send us everything, so we don't have that problem anymore. But now we've got to this data processing problem. Now, the value so the reason I was bringing up value is how do you judge? Or how do you balance the value to the end user customer, the one who's paying the bills, versus the person who has to do the processing work with internal work, because both of them need to be in harmony or balanced, even though one pays for you know, the wonder if there's a measure easy measure to say this is money versus the resource. But if we overloaded too much to the end user to the end customer, then you never solve the internal problems, which makes it more expensive to run the business. So you've got a cost benefit balancing act. And that's I mean, I guess, in a way, my long winded example is a question is how do you? How do you decide what values? And who gets the who gets the response to value?

Stephen Russell  26:22  
There's a couple of parts of that, how I would answer that. And I think I would answer it you've we've talked before about a book a moment is one of my favorite books was introduced to by a data engineer where it was still a very good friend of mine. And it's called the goal. And a lot of people have had heard of the Phoenix project, or at least a lot of people in it have heard of the Phoenix project, but fewer people have read the goal, which actually the Phoenix project is based on. And there isn't the reason why I bring that book up is because what you're describing to me as I'm listening to you, and you know, the thing I took from that book is an understanding of the importance of systems thinking. And that took me down the sort of the path that led to Schumi as a kind of an idea of philosophy, and then a product in a company. And, and there's a there's a message within the goal that sometimes gets lost and certainly got I think got lost with the the Phoenix project translation now is the books called the goal for a reason, right? So the goal is the goal of the company, what is the goal of the company, and it ultimately comes down to three things, right? So make sales, get get customers to give you money for whatever it is you're you're making. The second thing is to make it and deliver it to the customer. And the third thing is to do that second one fast enough that you don't run out of money before they give you the money. Right. So it's, it's really simple, and sales, building products, but doing it fast enough that you don't run out of money in the meantime. And that's that's the function of any business. So then, so then if you think about your example, you know, you're describing a system within a system. So when you get to a system, when you think about systems thinking one of the most important things to start with, that people don't necessarily analyze is what's the purpose of the system. So the purpose of highlight, and we get philosophical about this, right, but it stops existing. If it doesn't make sales and doesn't make, it doesn't make a product that people want to buy and doesn't do that quickly enough that it doesn't run out of money, right. So that's just the brutal harsh reality of the capitalist world, right. So we'll avoid that the discussion about that probably for today. But the point is, if that's the purpose of that system, then the system that you're talking about where you're trying to understand the workflow and look at that, and it helps it that lives that lives within that bigger system. So it has to exist in that bigger system. And so the the, if the purpose of the purpose of that work isn't aligned to the higher objective of hailo as an organization, then you end up in conflict, you end up with a dysfunctional system. So that's the first thing. So the people who are making that decision, I think your question was, who gets to decide what value it is, you get to decide what value is within your system, the bit that you have control over. But you can't be in conflict with the systems that you're the biggest systems that you're part of. So that's where okrs can be helpful. And this is a long winded answer, but I'm going somewhere with this. So So, so then the question is well, okay, does it in this context, that this that the coalface and where we're trying to improve this process for ourselves and for our customers, what is it that we're trying to improve? We're trying to improve our ability to sell to them. So we were trying to increase the number of sales that we can do and the capacity for bringing in revenue are we looking to improve this At which we can build the product, and for the quality of the product that we that we build, and, and then you know, we're looking to be as efficient as possible, so we don't run out of money in the meantime. So that's the, that's the decision, that's the first decision that whoever's designing that value on the ground needs to be thinking about. And that's, that's the joy of okrs is if you, if you use something like okay, as then you can join those two things together. Because ultimately, the CEO, you can dress it up in lots of different ways. And you can write very clever over objective statements. And this is what we're trying to do this year. But everybody in the organization exists under the context of three objectives, make sales, build a product, people want to do it fast enough that we don't run out of money in the meantime. Right? So there's always that high level purpose that should come down into any of the, into any of those objectives. So that's the first part of the answer.

And, and then, the second part kind of comes back to, again, comes back to kind of the character of the work because, first of all, there's an agency profile, right. So if you've got, if you've got those three objectives to begin with, and one of them isn't don't run out of money in the meantime, and there is an urgency profile to all of the different work items that you could choose from, there's an urgency profile to them, some things will be valuable, but incrementally, some things will be valuable, but only up until a certain day after which they no longer have helpful or we've missed the boat. And so there's different profiles to the agency of work. And we I like to use C three. And so cost of delay divided by duration. So in my mind went blank there for a moment. So cost of delay divided by duration is actually from this similar world as things like the

Ryan Purvis  31:49  
sigma,

Stephen Russell  31:51  
there is I think it's I think it's all baked into that type of stuff as well. So it's very much about, you know, this, this work item has a particular value and its value has an urgency profile, I will be more valuable at certain points less valuable. If it's not not delivered on time, then, so Scott, it's got a value, but then also it will take a certain amount of time to do and so if your objective is to try and deliver as much value as possible, you know, in kind of a flow state, you have as much value coming off the the production line as it were as possible, knowing that the world is uncertain, and knowing that it changes and it's volatile, and things can be unclear and complex, then, and that's that's how you make those choices. Because I think the other things to the second part of the answer would be whoever makes those choices is probably going to be wrong more often than they are right, unless you operate in a very stable environment. And so it has to be the people who are at the frontline, who know that who know about the changes. First, they have to be allowed to make those choices, and they have to be empowered to make those choices. Now the anxiety then that managers will get is well, do we have a right process to go? You know, do we have a governance around those choices? Do we have the right expertise in place for people to making those choices? And can I trust them to be making those choices for the right reasons and for the right motivations, and that that really then becomes the job of management is to make sure that people are in a position and have situational experience and the right procedures to make those choices when change happens. And but make those choices in a way that is aligned with the with the higher ups as it were?

Ryan Purvis  33:34  
I think that's that's how we've addressed it is that the priorities are determined by by the business, inverted commas. But these are these are guys that are in the industry have been around, you know, a long time. And they've all worked in the roles that we are servicing. So they they've taken sit there as the customer and say, you know, this report needs to have, you know, bells and whistles on it. Because you know, I need the bell, I need to whistle you know, so so I think that is we've got it right. I think the challenge we've we've always had is answers the industry thing, I think the level of of understanding on how to build software is just not there. And there's almost a expectation problem that well, we talked about it today. Or why can't have it by Friday. You know, it's like an Excel spreadsheet, right? You know, I can put I can build an Excel spreadsheet in a couple days. Why can't you build a piece of software in a couple days? And yes, some things you can cause I mean, of course, you could build some stuff very quickly, that there's some stuff that you know, takes takes time and it takes refinement sessions and it takes workshops and it takes backwards and forwards and you know, markups and you know all these new terms that for us is kind of commonplace, but these guys it's like so you're going to build a prototype. What does a prototype actually mean? I don't understand that concept. And oh, no, you show me this. Can I just tell the customer they can use it from Monday? No, this was just a prototype. This is a movie a throwaway. Now that we've moved Prove that we can do it. Those sorts of things. Yeah,

Stephen Russell  35:05  
I don't think it's that that, again, is only going to get worse, and is only going to get worse, what's interesting, so I can freely admit, you know, I've been guilty of being that manager, he's saying, Well, it sounds a lot easier to me than then you're making out. And I think that we should be able to do that faster. And, and in a way, you know, it, it's, it's driven by one, it's driven by a need to do things quickly enough that you don't run out of money in the meantime, right. And the frustration sometimes comes that when people are detached from that reality, and they're not looking at a p&l, or they're not looking on a runway, and they, you feel that they don't necessarily have the same motivations, and they're not necessarily putting their energy in for the same reasons. So there's, there's there's that side of it, which is making sure that people understand those three, the purpose of the business, and understand that the conversation is in the context of those three things, immediately makes that go away. Right when people feel like others are making decisions for their own interests because of their own silo. And that's where conflict comes from. If a conversation begins with, this silo exists within this bigger silo. And so we all share, excuse me, and we all share the objectives of generating income, creating products and doing it fast enough that we don't run out of money in the meantime. And then that's that immediately resolves a lot of the conflicts and a lot of the emotional stuff that goes on in those conversations. So that's the first thing, how do you deal with the kind of the emotional tension and the motivations of both parties in that discussion. And then the second thing, I think, is agile probably hasn't done as agile with a big a, probably hasn't done as a huge amount of favors. And because it's been so poorly implemented so many times, and it's got bad reputation by people who don't really understand it. And it's kind of clung to as the answer to everything. But some people who do and I probably sit somewhere in the middle. I think that as long as people can see and understand that customer value is being created at each of those steps. And as long as that's communicated back to the leadership, in the context of making sales products, doing it fast enough, we don't run out of money in the meantime, then, then actually, those conversations are a lot easier, and get resolved a lot more easily. What I mean by that, and why the challenges with that is actually, certainly, I think in the areas that I've worked in, there's been a massive wage inflation in developers. And what that meant is that a lot of businesses have ended up trying to hire more and more junior staff. So the situational experience isn't there, the commercial awareness isn't there, at the frontline, and so that that communication doesn't happen in the way that it needs to. And it there's a there's a role of a manager, there's that that technology leadership role, that is sort of taking out that information and turning it around and speaking to the execs in a way that says that we're doing this and we're taking it, we're taking these steps, because this is ultimately how it influences those three things. Either it's going to make a product that people want to buy for a higher price, or it's going to be we can do it faster, isn't it, that translation isn't happening in a lot of cases. And if the team of the frontline can communicate their choices in that context, then that's that's when you don't need okrs

Ryan Purvis  38:59  
Yeah, as you say this I mean, this is exactly where we've attained a good sense we're in that we're in that position. I think our challenge has been as the technology team has gotten into a good position we got good process we we have the right involvement from the business we we do work in progress thing, review them every week, we repeat, we release code every week. That's with functionality. So So why don't we giving them visibility, what's coming to we're getting their feedback on anything we have released. Three, we were kind of using a ring deployment method where we can deploy to a certain sort of certain amount of users can see the functionality first before it goes to the wider audience. So we could feedback from there. So I think our feedback loops are quite good. Which is one of the key things I got out of the I'm reading the DevOps book, the DevOps handbook that goes with So yeah, I these things are all intuitive to an extent I mean, and agree with you that jargon poorly implemented usually. Usually everyone just reads it as well. Got to do two weeks sprint. And you can you can change your mind every two weeks, which is not quite as opposed to work. But you do have a level of flexibility. So

Stephen Russell  40:12  
yeah, sorry, it's a question of trust is this this idea that if you just trust the team, they'll bring you the value back. And, and that's only true. If the character of the work is you know, you've got decent processes, you've got good people with situational experience on it. Now, you could, you could trust me to go and build you some software, and you'd be wasting your time and money, because I'm not going to build any decent software, because I'm a software developer. Just because somebody has the role title software developer doesn't automatically mean that they will either, there has to be an element of situational experience, choices, alignment, energy that's going into it. So making sure that the team, the character of the work, and the character, that project is understood in those terms, and the gaps are being addressed, is much more important than just saying, I trust you for two weeks to go away and do what I want, you know, what I need, and because there's 100, there's 100,000 reasons that they won't, that have nothing to do with people's integrity, or capability or, you know, it's and that's where it comes, it starts getting bit becomes a personal thing becomes about the people and not about the work. And I think that's the, that's the thing that people need to probably spend more time on is describing the character of the word, and not the character of the people going,

Ryan Purvis  41:33  
you hit the nail on the head, because as bad as I was about to give an example of something I've dealt with, I've dealt with a few times, actually, let's be fair. So so when I, when I started writing code, many, many, many, many years ago, it was always about not just writing code is about understanding it. The problem was, and, you know, trying to make its thing now was never the best developer, I'll admit that. But I always felt that I took the time to understand the problem, to deliver appropriately and properly without needing you know, all these extra people to help me. So what does that mean? You know, I come across developers a lot they need, they need a business analyst to go get the requirements for them. They need an architect to tell them how they're going to put in a bullet, they need a tester to go test the quality. They need someone to do deployments for them. And that's that's almost as sort of that they're, they're not a fully diverse developer in my mind, you want someone in my mind at that developer will look at something and go Okay, so you want this to serve you coffee every Wednesday at nine o'clock? You know, why do you want to do that? what's what's the reason behind that? And, and Is this the one but you know, they're suckered into asked good questions. And before they've even touched a piece of code, they've gone through the list this exploration exercise so deeply, that when it comes to actually writing the code, the code is like 10% of the effort. And it's almost the boring part because you've done all the hard stuff. And often, what I find is that I get these developers that will take the problem, it's a one liner, they'll go and write a whole lot of code. I'll spend days and weeks writing this thing, and I'll come back and go, here's what I got you and you're like, Yeah, but that's nothing to do with what we do. Like it's a complete mess. And that's the, that's the challenge that I that I try and solve the developers to get them to do all the other stuff first before they even write code.

Stephen Russell  43:26  
And it's a really difficult thing to get right. And, and I think my my personal experience of that is the people who who are the best at that aren't the best at that, because they were born that way. They're the best of that, because they've been doing it the longest. And I know it sounds a bit you know, but there's not a Udemy course for that. Because I think it is. And that's not something and I again, you know, this is where people will reach for procedure, and they'll reach for the scrum manual. And they'll reach for, we need to have really highly defined acceptance criteria. I've seen acceptance criteria done to the enth degree with the best of intentions. And the work still misses. Because there's still gaps in the understanding. There's things that weren't said so, so. So I think that comes with experience. And that's why situational experience is such an important part of expertise. It's not just certifications, it's not just qualifications, it's situational experience. And I think that you know, because that takes time, and because that is such a valuable skill when it comes to actually creating customer value. And it's expensive.

Ryan Purvis  44:39  
It is at any rate, right. I mean that people you know, I didn't learn that stuff by magic. I just happened to work with a very good team. Who, yeah, who didn't who made sure you understood that was the way you do things. Because I used to write stuff on my own, you know, obviously, you develop very bad habits, but you know, you work with a team that they say, well don't even touch the code till you've shown me your design. And show me you know, I mean, when you go to university, they teach you things like pseudocode and, and state diagrams and all that stuff, which, you know, yet a university level doesn't really help you. But when you're building an application for the enterprise, you know, you need to do some of those things. And you need to have an have an underlying understanding of, of what you're building.

Stephen Russell  45:21  
JOHN, john, my, my business partner, uses a phrase, and I'm not sure where he gets it from and the last responsible moment. So there's a couple of different algorithms for figuring out am I spending too much time navel gazing and during, during the quantification, or not. And in, in lane, it's called,

forget what it's called. That's annoying. But essentially, you defer the choice till as late as possible. And john, john describes it as the latest responsible moment. Right? So what understanding at which point does not having made a choice become irresponsible, and started damaging? So knowing that there is a decision to be made, there is a decision point that is a point in time at which somebody will make a choice? And what is the latest point that that can be actually made? And, you know, this, I have absolutely no idea why it is this. But it's, there's, there's like a theory around. So if you've got, if you've got 100 days to buy a house, how long should you spend looking at houses before deciding to put an offer. And I forget exactly which percentage, it's like 32, or 37%, it's like a, it's like a third of the time, basically. And after which you're unlikely to see any more houses that are better than the one you like the most at that point. But any less than that amount of time, and you might have considered things that you find attractive. So it's really interesting algorithm that I can I can find links to and send them to you, because I can't remember it brilliantly at the top of my head just now. But that's, that's, that's ultimately the same thing, right? So if you try, and if you can quantify things a little bit, and put people then, and then they can understand them a little bit better. So when we're talking about, you know, designs, and we're talking about feedback loops, and we're talking about the way the product is made, and understanding that, you know, at the moment, we're still in the process of understanding what the choices are, and the decision point looks like this, then you can you can explain to people why it's important to spend that that time getting to that decision point. And and that, you know, from that point on, there's no point continuing to navel gaze about it, we're probably not going to get it, we're probably not going to nail it. We're probably not going to get it right. That's that's tech. Right. But what's understanding and judging and being on the same page about what's the what's the appropriate amount of time for us to invest in making the decision and understanding the choices? That's, that's really important, because ultimately, that that feeds into them. Now, are we building something people want to buy? And are we doing a customer? So it's always a trade off? Yeah,

Ryan Purvis  48:10  
I mean, I think that is the reality. It's like a SimCity you're the you're the conductor, and you got to keep all the pieces moving. But you in some cases, you got to you know, slow things up to speed things. So slow things down or speed things up. There. No, I totally, totally get where you're going. Yeah. So how's that worked with? You know, if you start in a new organization, you can you can do that stuff? from the get go? What about going into an organization that's that's been doing it the old way for a long time, and I say old way waterfall approach or no real process, just just building chasing fires down, you know, fixing bugs and, and building stuff at Hockley.

Stephen Russell  48:55  
I would preface my answer with there's nothing wrong with doing it, what's four, if that's the right way to do it, and the waterfall versus agile is a debate that I have. I have little little interest in having had it many, many times and come out, bruised and battered by people who have bigger, bigger and uglier than I am anyway. But the point I think is rather than trying to understand the change that needs to happen, or where people need to get to getting on the same page about what is happening, right now. So in in lane, again, you would build a process flow map, and then you'd say you'd have your current state and then you'd have your desired state and try and figure out your your phases in between. and step one with your agile or waterfall doesn't matter is is understanding that everybody has the same mental model of what the current state is. Because the conflict comes from a lack of understanding about what's actually going on when they can't see the work and this is even worse now. We're all remote, right? So you can't, you can't see people working. And so there's just a horrible, like intuitive emotional thing that goes on and where people start to panic. And they fear that they're spending money on workers that aren't as productive as they need to be. And it's very old fashioned kind of ugly. Tree mindset. Exactly. That's exactly right. And that's, that's definitely not what we want. So, so yeah, so the first thing is understanding what is the current process? And what actually happens? And then understanding where are the optimizations in that the optimizations then, as part of understanding that process, you're essentially describing the system. And coming back to my point earlier, to describe the system, you have to describe the purpose of the system. So is the purpose of the system to make it less onerous on the customer? Or is the purpose of the system to shorten the time it takes for us to get from idea to sale? Now, there is a point there is a there is a way of describing the system that you've drawn out that both the execs and the people who are doing the work agree on. And that's the first step doesn't matter where you want to get to, if you don't have that to begin with, we'll just go around in circles arguing. That answer your question, you've gone quiet this

Ryan Purvis  51:28  
person does. So and I agree with you about the use of waterfall versus agile, I don't think it matters, because we think it's still the same in the end. I mean, the only the only difference, obviously, is that, you know, waterfall you're not you shouldn't be writing code, necessarily. On day one, you should be understanding the requirements and, you know, doing all the documentation you would normally do. The problem with that approach, obviously, is that some some systems, some businesses will have moved on from their requirements by the time you start building the system. With which is where I think the Agile has a benefit with the agile approach, but that the converse of Agile is you tend to be building things like you build a barnyard where you you add to the barnyard, every so often with something new. So it doesn't look the same. It's not consistent inside uniform, it's you know, it's very patchwork, which for some products is fine. I think that's that's totally okay to do it that way. But I think it comes down to be very clear on what you want to build from day one. As you said, what what's the output will end in mind probably be the, the phrase, and you're gonna zig and zag as you get there.

Stephen Russell  52:36  
That's it. And it all comes back to the decision point, right? So waterfalls, absolutely fine. If beyond the decision point, the things that factored into the decision are unlikely to change is that it's absolutely the right way to do things. And probably more helpful, in fact, for everybody involved in the embedded coordination, and that it depends on each decision gate, being, you know, not not being before a whole bunch of change to the factors that went into that decision. So if the factors that went into the decision are going to change, after the decision has been made, then waterfall is a terrible way to do things. And obviously, that's why people get themselves into a bit of a mess. Now, on the on the other side. And with agile, I think sometimes it's it's not clear what the decisions are that needs to be made and who needs to make them. And I think they're, I think it's what you were saying that there are core choices, there's core architectural choices, and both from a commercial business model perspective, and from a technical perspective that needs to marry up. And a lot of the design decisions around that can be a bit more flexible and impact less. So I think it's understand recognizing where a choice is materially going to influence those three things that the business is there to do. So is this choice going to materially impact sales? Is it going to materially impact the quality of the product is it going to materially impact the speed at which we can build it, where you have those three choices, those choices need to be taken by people who have the commercial awareness and the situational experience. And and it's it is the leadership's responsibility to make sure that they are. And it's actually you know, it is negligent and irresponsible to allow decisions that are that important to the existence and the organization to be taken by people who are unqualified or inexperienced, or maybe even just don't have the information. You know, we all make good choices based on the information that we have but founded called bounded rationality and systems thinking and bounded rationality, but just don't have the information that you have. I'm not going to make the same choice, am I?

Ryan Purvis  54:51  
Yeah, I think you've actually answered my question in the beginning or on the framework for deciding value, which is speed, quality or sales.

Stephen Russell  55:00  
But that's what that's what I took from the goal, you know, kind of build a quality product, kind of sell it to people, and kind of do those two things quickly enough that the capital I have right now means I don't run out of money. Those are all the choices anywhere in the organization should be taken in that context. And I think it's amazing what happens when you have that conversation with people because all of a sudden, you know, your, that their commercial points, right. But technical people love that conversation, because they want to be making choices, technical choices. And this is where this is where it's interesting to watch technical people having conversations with commercial people where they're not described, they're not talking about those things like the commercial person, I want a blue button, I just want a blue button. Why can't it be blue? And why can't it be blue on Friday? It's like, technical people what it can be, but in the back of their mind, they're thinking, it doesn't seem like a very sensible thing for us to do as a business. But on the flip side, you know, what technical people aren't trained to do, and isn't part of software development training is actually explaining why they feel like that in these three terms, so that the commercial person on the other side of the table goes, Okay, yeah, Wednesday is fine. I'd rather have it on Wednesday with the things that you're thinking of that you're not expressing because we've not got the same common language, we've not got the weight the same way of talking about these things. And I'd rather wait and get the one that you're talking about. And that's what, that's what collaboration is about. You can't collaborate with people if you don't have the same language. Hmm.

Ryan Purvis  56:37  
Yeah, I can, I can see so many scenarios where I've tried to explain something to someone and you can just see that the minute you've started down the track, that it's either too much information, or in their mind is too technical to detail that all they wanted to know was Dude, that's on Friday. Yes, that's all they wanted to hear.

Stephen Russell  56:55  
And also the appreciation, you know, Kevin worked on both sides of the fence, the appreciation of the emotional reaction that person is having when you say no, right? So, so they understand the implications from a customer's perspective of right, I'm going to have to go back to the customer say, it's not gonna be Friday, that means they might go with our competitor. Right? So that means the agency profile or the work is, if it's not done by Friday, it might as well not be done at all. Right? So there's an emotional response to that, that then clouds the rest of the conversation. And I think that's where, for me, I can I can debate anything with you. If you agree with me that some empathy is always a good thing. Right. So So that's my, that's my kind of life philosophy. I'll debate any topic with you. As long as we can agree that some empathy is always a good thing. And that's that's where often these conversations can be most challenging is where that empathy is not necessarily. And if you can, you can, you can sympathize with people's frustration, but actually understanding and empathizing with the position that that puts them in. That's difficult. That's that's where a lot of its tension in the conversation can come from.

Ryan Purvis  58:09  
Are you familiar with with Ray Dalio?

Stephen Russell  58:12  
Yeah, principle? Yeah.

Ryan Purvis  58:13  
Yeah, the only thing I mean, he's got a lot of good stuff in there. But the thing that really struck me was his radical candor. And that is it is that so it's what I'm very lucky with, with our current businesses, they are very, very transparent. And they'll say things like, Look, this customer, this is a big one, this is an important one, like, we have this one, it opens up all the other ones. So we need this feature this functionality. And that's very easy to say, Okay, well, this thing moves to the top of the queue, because the other stuff is important, but it's not this this is customer as you know, better customer sales, that kind of stuff. But I have worked in organizations where Yeah, you don't know what the the underlying politics are to, to the blue button by Friday. And I will tell you, it almost becomes a fairy tale. You know, and if you don't do by Friday, the you know, the wizard is going to come in and Zapier or something, I don't know, some nonsense like that. But it does make making decisions very difficult. So I'd rather have you know, radical candor, which is no products crap, we need to fix it, it's not looking good. It needs more usability, it needs, you know, whatever it is, to sort that out.

Stephen Russell  59:23  
I couldn't agree more. And actually, it's not just because I'm talking to you, but I've said this to other people about when when we work together. You can be very direct you can you can you say it as it is, right? But we always I value that because I always know that it's coming from a place where you're trying to care about the same things right. So we we found a happy place with that understanding of Right, okay. If we crash, then let's go back to what are we here to achieve? What are we actually trying to achieve because it's not about the blue button. And the radical candor thing is not just about being direct, it's also about it coming from a place where you care about the other person's success. And that that's where that works. And it if, and I think this is why the importance of that communication, the importance of that ability to express why the blue button needs to come on Wednesday, and why that is in the shared interest of the organization. That's where that big that's, that's why it's so valuable. That's why it's so hard.

Ryan Purvis  1:00:30  
And you're so right. I mean, I used to get, there was a guy that I worked with a hockey player as well. And he used to always say you'd like route one, which is to smash the ball through everyone. And I had to learn over time to sort of slip slip on right upon left to the short ball just to change it up. And, and I hope that I've improved on that. I've been said, not being so harshly direct, but the director The Good, good intention.

Stephen Russell  1:00:53  
And it always was a bit always was for me, but I think equally, when it's not there, you miss it, right. So So as a manager, as a leader, I've known there was something someone's not saying there's something here that somebody isn't saying, and I can't tease it out of them. And it's like, if you think to yourself, I need a Ryan. And if someone is just going to go, the problem is this. And this is what we should be talking about. And it is sometimes you may route one, but you need route one, where like I say, it comes from a place of empathy, it comes from a place where you've got a common goal. And the common goal is not the delivery of the button, it's the hierarchy. And that's that's kind of bringing it full circle, you know, that can be the value of Okay, as is it can encourage the conversation to go up in that way. It rarely does, because that's really how they're understood. And it's just, I need a blue button, because I need that page, because I need that thing. It's like just you just making another hierarchy, you're not actually aligning people around. And these are the choices we need to make to be successful. And if we take that path, that's the outcome. And if we take that path, that's the outcome. And we both benefit from option A, for example, which is I mean,

Ryan Purvis  1:02:08  
well, I mean, it's the diversity thing, you need to have all different types of people in the room. And I always used to sort of have in the back of my mind that sometimes you need to be one person in the room, because there's all these other people in the room. And when they're not, and and if there's someone else, it's like, there's there's always a reason, excuse my example that you know, if I'm, if I'm usually the one that's this direct and blunt, and there's someone else, it's more direct, more blunt that I don't have to be that guy. So I'll be the other, I'll be someone else, I'll be collaborative, and the nice guy or whatever it is. Because if someone asked to do that other role, because I think you need to have that fluctuation in order to get, you know, a good result. And

Stephen Russell  1:02:45  
that's exactly what we're trying to achieve with our when we're combining meeting analytics and personality analytics with for a manager is to sort of say, like, this is what this is what the makeup looks like. And these are the people you can go to if you need if you need a route one comment, and this is the person who's going to give it to you. And if you need a bit more of a go away and think about it. And this is the person to ask him, it's not about it's not about kind of removing any of the humanity, it's just there's a lot there's an awful lot that left unsaid. And or it's always said at the watercooler when actually it needed to be setting the meeting for everybody's benefit, it might have been uncomfortable, but it just needed to be said. And so for managers to understand the dynamics of their team, and the character of the work that's being done, it allows them to pull the strings in, in the way that they might need to whether they're giving people the authority to, I'm asking you for your root one opinion, I say it say as you see it, and then let's go from that.

Ryan Purvis  1:03:44  
I think there's a cultural thing to that as well. So if you notice, when I moved over to the UK, for missing, I find here people a lot more. I don't know if it gets to the point or direct or where you know, there was a joke about South Africans talking like this speaking of the machine gun, cuz like that. But But if you notice, my first couple years in the UK, the dieters learn how to, you know, talk a little bit to the left a little bit to the right, and then down the middle. So it's a it's a cultural thing. I mean, it's the same working with resources in Europe and India, and that you've got to be aware of how they handle conflict and,

Unknown Speaker  1:04:20  
you know, absolutely.

Ryan Purvis  1:04:23  
So, I'd loving things, that kind of stuff.

Stephen Russell  1:04:26  
I was just gonna say on the on the end of that, but you know, that that's absolutely true. And then, and cultural dynamics is important. But even within those cultural dynamics, you have different personalities. And, and again, that's the importance of understanding the character of the work because if you, if you took it to high level, the way to navigate that is to be specific, but within, you know, within the cultural kind of norms that be really specific, and then everybody's having the same conversation and there's not this kind of unspoken bit. But that is that is what ultimately trips me Pull up is not what settings was not set that gets us in trouble.

Ryan Purvis  1:05:04  
Yeah, and it's funny, I've just finished reading a book now, which I recommend you because then you recommended the goal to me turn the boat around tennis ship around, which is about leadership with intent. And it's moving away from the sort of leader follower culture that we've grown up with, in business to lead a leader, which is, you know, empowering. So instead of being top down, it's bottom up. And there's a couple of key concepts in there things like, you know, taking deliberate actions. And I mean, this is, you know, a very, very short summary, but it's written by an ex captain of a submarine, and how he could handle the submarine with the worst crew, the worst record, etc. And he had 180 days to be ready for deployment and how he approached it with his team and how they change things. And he had obviously some, some conceptual things he wanted to try out and how some of them worked. And some of them didn't work and all the rest of it. And I'll say that for you to read, because I think it's worth reading and seeing how he puts it all together. But a lot of this and a lot of these problems, and you talked about trust in the agile team, rely on a leader leader culture, not a leader follower culture, because everyone has to buy in to have this A, B be willing to trust the other person, etc. So with

Stephen Russell  1:06:18  
that, that's ultimately the difference between agile and waterfall where agile will win every time is people at the front line have the information first. So they're the people who need to be able to make the choices that need to be made quickly. Now, there's choices that need to be made slowly, and they're bigger than more strategic or that you know, then, then then yes, that there's still a need for different roles, and probably probably a type of hierarchy, and probably not to the traditional hierarchy, thinking that, you know, there are different types of choices that needs to be made. But the ones that need to be made quickly. And the ones that need to be made. For the purposes of kind of productivity and efficiency they need to be made at the front line.

Ryan Purvis  1:07:01  
Well, this is and this is what's in the book. So so he changes how, you know, instead of him being the captain who decides everything, and is the bottleneck, in essence, it's the other way around, the crew makes the decisions, they know the areas they they they handle the situations. And all he has to do really is confirmed what they've said. So you know, they're going to go to periscope deaths, he says very well. They're going to blow the baddest hands. He just says right now, any day makes comments like, you know, the times where he's gotten involved to make changes, he's actually made more mistakes, because now he doesn't have the technical knowledge of that, that vessel where he did the previous vessel because he was a different role. And that's sort of I think the the last medium is that you trust your team to make the decisions as long as you give them like the guidelines or the guidance and the what's the word? Not the parachute, the net, that if they make a mistake, it's not a big deal, you can recover from it, just learn from it.

Stephen Russell  1:08:02  
So I agree with you, I agree with our take on the book, I I feel like I've read a similar book, or it might have been sort of the Stanley McChrystal which is, which is a similar sort of message. And I think that that type of dynamic between the workforce and the leadership was what's happening there, and is very much about that character of the work, right. So the frontline people are bringing their choice, this is the choice I've made. And it's the latest responsibility to know what have we got a decent enough process to make that choice? Have you got the situation experience expertise to be doing it? You know, do the data need to be doing it? Are you making it for the right reasons? And are we sort of motivated in the right direction, it's almost a sense check of is the character of the work is the character of the decision appropriate for that person to be making it? If it is fine, let them make it. And it's, it's it's more about then spotting when a choice is being made, where the character the work is ugly, or the person making that choice is the wrong person. And not because there's anything wrong with them but just because there's not a match between that person's expertise and experience and the character of that particular work. So that's where that's why we're fascinated with personality and not just the personality of the work the personnel sorry, not just the personality of the worker the character of the work as well. Yeah, this makes that possible. Yeah Miss

Ryan Purvis  1:09:37  
definitely put you in contact with with Diane we she's got it. She's got a thing called so called raw w AR A w liquid place resilience, something to get the acronym, but but they are they are doing assessments of people and their stress and their energy and all that stuff to help them cope Obviously through the pandemic and that as well. But it's almost that it's aligned to what you're doing. There. I don't think they have a tool or technology that lines up with that, if that makes any sense. I'll, I'll after this, I'll put you in contact. Right. So it'd be nice, complimentary.

Stephen Russell  1:10:17  
Yeah, as far as saying that, and they're probably already on wireless, intuitive. And it's kind of obvious that these things are multifactorial. And it's a system that creates that frustration and that stress. And this stress manifests because of problems elsewhere. And those problems could be a lack of information that is dependent on it could be a lack of confidence and inexperience, it can be all sorts of things, you know, can be, like I say, hundreds of different reasons that people find themselves under pressure, and then behaving because of their personality dynamics, behaving in ways that are less desirable for them and for the organization. So yeah, that'd be fascinating to have a conversation for sure.

Ryan Purvis  1:10:57  
Yeah, good. We've gotten fairly long now. Do you have anything else to do or ended there?

Unknown Speaker  1:11:05  
Um, I

Stephen Russell  1:11:09  
think we've covered most of the things that I think I was just as far as kind of future and the work. That was the only area that I thought we'd maybe touch on, you know, what, what is the future of digital workspace look like? And because I think that's an interesting, I think the future of digital workspace is an interesting topic, for a number of different reasons. And I think there's a lot of predictions being made at the moment on flawed, flawed data. And but yeah, other than that, man, I think we've covered most,

Ryan Purvis  1:11:37  
so what do you think that what I mean, what do you think is the future, I

Stephen Russell  1:11:42  
think it's impossible to predict the future, because I think the data that we have at the moment is, is flawed data, right? This is a not not a usual situation, and to make any predictions about the future of work based on a pandemic, and I think that's silly. And so, but what I would say is, you know, a lot of the problems that exists now, and that people are concerned about now, when it comes to the forefront, already existed, you know, and, and they, and they exist, even when people are in an office and those things, you know, lack of efficiency, lack of alignment, and people feeling isolated, people not feeling like they've got autonomy. And I feel like those are, those are problems that we had before the pandemic, and they're problems that we'll still have, after the pandemic, whether or not people go to the office, go back to the office or stay remote, now remote might dial up the pressure at certain times, or magnify some of those issues. But I don't think those things necessarily going to change. What I do think will change is an I think it's something that sort of as a generation, and you and I will start at one end of this trend and see out the other end is the technical competence of people who are in non technical roles, and the types of roles that are required software. So I think the the kind of the no code and low code, and apps that are being invested in now will be will be really influential. And, you know, we've seen a massive explosion in robotic process automation in that industry, and but equally, just putting tools in people's hands, you know, air table, for example, and allowing people to create their own apps and their own data driven apps. that I think will will have a massive influence. But it obviously brings with it its own kind of challenges around security and that type of stuff. And I think there's there's some interesting stuff that will happen. But I think the ability to create automation to automate processes and create technical solutions, within departments without having to go to technical teams, I think that's something that we'll see growing. And I think also, if you looked at kind of where investment is going, there is this, you know, that Slack, kind of the classic example of creating products in ways that mean they can be adopted at the front line, and then filter their way back now, you can discuss the success of that or otherwise with Slack, right. So it's a fairly ubiquitous tool, but obviously had challenges in terms of enterprise revenue, and problems that Salesforce will have solved for them. But you know, that that methodology of building an app that can be adopted almost like a consumer app at the front line, and then sold into the enterprise, sort of in reverse to what used to happen. I think that's a massive trend. So those two things, I think, will dramatically influence the way people set up their digital workspaces and how they go about doing their jobs.

Ryan Purvis  1:14:39  
Well, that's as Ubers grown as well. I mean, you know, it's the it's the things you can install without having to ask it to install it. Yeah, yeah. So I mean, the amount of tools that have spun up by wimzie calls one Burroughs and other tools, you know, yep. Tells you probably would never have used because it was really I mean, barring yourself for me, I mean, yeah, you introduced me to mirror before was called me and it was real time board or something. That's right.

Stephen Russell  1:15:08  
It was Yeah.

Ryan Purvis  1:15:09  
But But you know, it was a very much a pocket thing, you know, you'd use it, that I would use it, but no one else would really use it because there was no need now that you're sitting at home, I mean, I'm in a different country than everyone else, you need a way to, to connect real time and collaborate and, and, you know, people are buying into it, because the tools are actually really good. I mean, for the most part, you know, that will work. And, in fact, has got to a point now, where if they, if they go down, we had a problem with figma the other day. That's what our designs are. And that wasn't working for a day, and you end that actually created panic, because we didn't have a backup yet. And now we now have a backup every day, but we're so reliant on these services, and become realized that because of our distributed working,

Stephen Russell  1:15:57  
yeah, and I think that yeah, I think that only but that's only going to increase, isn't it? You know, but I think I do feel that somewhere along the way, security. And the ability to adopt some of those tools in a way that's, that's compliant, and secure, will be really, really important. And, for example, if I could use up here, an air table, and some of these tools that I use, for building automations, myself, if I could use them with a client, and know that I was doing that in a compliant way, because there's customer data going through them and all that sort of stuff. And that would be game changing. That would be game changing.

Ryan Purvis  1:16:38  
Yeah, and I think you're right. Let's tap there. We can he'll get hold of you.

Stephen Russell  1:16:44  
And they can get me at Stephen with a pH like step 10. And Stephen russell@shumi.io, or via the shumi website as well. Mitch is just shoot me.io sh, m i.io.

Ryan Purvis  1:17:00  
What Why did you pick shumi as a name.

Stephen Russell  1:17:04  
So shumi is a Japanese word, it actually all comes back to kind of that obsession with the goal and with lean and understanding continuous process, optimization and all that sort of stuff. Shem is actually a Japanese word that means hobby. And now it kind of it resonated with me on a number of levels. So one is, you know, just a fascination and an interest in this topic, as you would have in photography or flower arranging. But also, you know, in life, as I understood it, and whether word was introduced, introduced him is assuming in Japanese, we say hobby, and we've sort of the thing you do for leisure. But in Japanese it I don't speak Japanese, I'm told this and it has more of a connotation with the thing that you devote attention to and devote your you don't you try to attain mastery. So it's all about the attainment of mastery, but doing that in a way that you enjoy, and that isn't, doesn't feel painful. That's ultimately kind of at the heart of what we're trying to do is give people the opportunity to attain mastery by breaking down their their performance at work into areas that they can focus on and improve on incrementally. So just continuously improve in a way that isn't top down. It's about them and enjoying their work and getting the best woman

Ryan Purvis  1:18:31  
interesting. I never I never thought was Japanese. I thought your big f1 fan or something? I really

Unknown Speaker  1:18:38  
I pre dice. Pre dates.

Ryan Purvis  1:18:41  
Yeah, fair enough. Fair enough. Great. Well, thanks for being on Yeah. And and we'll keep in touch.

Stephen Russell  1:18:46  
pleasure. Thanks, Ryan.

Ryan Purvis  1:18:51  
Thank you for listening today's episode in the big nose our producer, editor. Thank you, Heather. for your hard work on this episode. Please subscribe to the series and rate us on iTunes or the Google Play Store. Follow us on Twitter at the DW w podcast. The show notes and transcripts will be available on the website WWW dot digital workspace that works. Please also visit our website www dot digital workspace that works and subscribe to our newsletter. And lastly, if you found this episode useful, please share with your friends or colleagues.

Transcribed by https://otter.ai