What A Lot Of Things: Tech talk from a human perspective

Ian and Ash talk about how Microsoft Japan trialled a 4 day working week, busting Ash's myths about Japanese working culture and why technology people should care about design thinking, even for test automation.

Show Notes

Links:

Creators & Guests

Host
Ash Winter
Tester and international speaker, loves to talk about testability. Along with a number of other community minded souls, one of the co-organisers of the Leeds Testing Atelier. Also co-author of the Team Guide to Software Testability.
Host
Ian Smith
Happiest when making stuff or making people laugh. Tech, and Design Thinking. Works as a fractional CTO, Innovation leader and occasionally an AI or web developer through my company, craftscale. I'm a FRSA.

What is What A Lot Of Things: Tech talk from a human perspective?

Ash and Ian talk about interesting Things from the tech industry that are on their minds.

Ash:

I really like the twelve hours videos. There was, there's a sketch of the Simpsons called steamed hams, and someone Woah. Someone has done a twelve hour version of it. And someone had done a twin peaks version of it as well. Absolutely brilliant.

Ian:

But Deemed hammed.

Ash:

But there's a very dangerous world out there in terms of time. Start thinking about one sketch from one show, then you go and look at what people have done with it. You're like, wow.

Ian:

But you get to a kind of zen like state after twelve hours of that. I mean, you must be kind of you must be seeing new depths in it by that point. Yeah, absolutely. Even if you're kind of hallucinating them.

Ash:

Yeah. Yeah.

Ian:

That is astonishing. But

Ash:

but now I see steam pounces everywhere now. I know it.

Ian:

I'm not gonna turn around and look out the window because I'm too scared about what I might see.

Ash:

I know it's not. I know it. I just think about it more. But, essentially, every single time, like, I open Twitter or Reddit or something like that, there's some cultural reference to steamed hams. And I'm like, wow.

Ian:

No. You definitely have an observer bias.

Ash:

Yeah. Definitely.

Ian:

I I I have lived my life in ignorance of, of the Simpsons and steamed hams except insofar as you've talked to me about them.

Ash:

Yeah. So but now you won't be able to avoid it.

Ian:

No. No. No. No. I'm going I'm I'm exercising my very strong powers of forgetting now.

Ian:

Steamed hat. No. You ruined it. Hello, Ash.

Ash:

Hello, Ian. How are you?

Ian:

I'm very well. We're we're back.

Ash:

Back again.

Ian:

Yeah. Episode three.

Ash:

After a wildly successful launch.

Ian:

Wildly successful. Yeah. I think we've had, like, 30 listens.

Ash:

That's great.

Ian:

Yeah. And nobody's coming for us.

Ash:

No major copyright infringements.

Ian:

And, I look outside, and there are no people with torches or pitchforks. So we're doing alright.

Ash:

Or we're not doing well enough.

Ian:

Yeah. Good point. Very good point.

Ash:

We had a question, though.

Ian:

We did have a question, and the question was tweeted to our hilariously named Twitter account.

Ash:

Oh, yeah. That one.

Ian:

At what a lot of thing.

Ash:

Thing. Singular.

Ian:

Yeah. Because, you know, limits. The question was from our friend Lee Rathbone.

Ash:

Oh, of course.

Ian:

Lee wanted to know, are we gonna have guests?

Ash:

And what did you say?

Ian:

I said, yes, but probably not for a while. And that answer had a subtext. And the subtext was, we don't want any guests to find out how crap we are at doing this. And we don't want to make any guests have to do rerecording because I set the levels wrong on the little thing.

Ash:

That's never happened.

Ian:

That's never happened apart from two thirds of the time. So we might well have guests, but only when we're good at it. So ask us in, I don't know, eight episodes' time or something. Yeah. So we've done hello.

Ash:

Done. I

Ian:

think we've done the questions.

Ash:

We've done dog Tanyan and the three musketeers. We've done the question. We've done the perils of colonial treasure.

Ian:

So there's

Ash:

plenty to edit out there.

Ian:

Edit that out as well. Yeah. Right. Okay. So where are what we're gonna do now?

Ian:

Yeah. Okay. So let's introduce the idea that we may talk about things.

Ash:

Okay. So I can do that.

Ian:

Okay.

Ash:

So we've got two things to talk about today, and I believe I'm gonna go first.

Ian:

You are. Right. What's your thing?

Ash:

So my thing this time is the four day work week in Japan at Microsoft.

Ian:

That's narrowed it down a bit. I was I was hoping for a four day work week myself.

Ash:

Global four day work week. Yeah. Maybe not there yet. So the reason it piqued my interest quite a lot was that it was in Japan, and I have deep impressions of Japanese working culture. That is their they work a lot.

Ash:

They work many, many hours and sleep at their desks and all kinds of things. I realize this is probably fed by lots of weird western cultural misrepresentations of Japanese culture.

Ian:

Yeah. I'm sure that's right.

Ash:

But that's why I noticed it, and that's why it seemed like a really good thing to talk about. Yeah. So it was I think it was a five week trial of a four day work week, and it resulted in just about 40% increased productivity Woah. Which is quite a lot.

Ian:

Yeah. Well, that's, I guess, 80% of the time and almost half as much output again.

Ash:

Yeah. Yeah.

Ian:

However you measure output, which is an interesting

Ash:

Yeah. Tough question. Yeah. I mean, it doesn't really go into how they measured that. But and they thought that a lot of it was thanks in short to shorter, more efficient meetings as well.

Ian:

I guess people have the feeling that they've got less time so they don't hang around so much.

Ash:

Yeah. Yeah. Absolutely. Or going

Ian:

on for hours.

Ash:

Yeah. Absolutely. And then also, the article that I saw this in is a bit vague about this, but it says reduced, like, the time off that people took as well. It doesn't specify whether that was holidays or sickness, but it just said that there was, like, 25% less time off taken in those in that five week period. So I don't know how much to read into that.

Ian:

That's interesting, though. Mhmm. It kind of makes me wonder. It's one of those things where okay. It's it's a five week experiment.

Ian:

It's not Yeah. Academic studies with controls and all that kind of thing. But it makes me think, if I was a CEO of something and I thought someone showed me a way to get 25% more productivity, then I'd kind of leap at it. Yeah. And you kinda wonder why isn't everyone trying this.

Ash:

Yeah. I think there's a lot of deep seated cultural thinking and bias around, you know, how much time you spend doing something versus how much output or how effective you are at doing something. So I think I know what you mean, but I think probably a few CEOs who might turn around and say, well, I value seeing people at their desks from nine to five, Monday to Friday. Yeah.

Ian:

Because that's the important thing.

Ash:

Yeah. Yeah. Absolutely. But I think from experience, I've identified a few a few few places I've worked, a few people who've been very much of that mindset, who've celebrated how many hours people have done.

Ian:

Yeah. And you you kinda get people walking around boasting about how they haven't had any lunch today because they were just been so busy Yeah. To work through their lunch.

Ash:

Yeah. But the whole reading about this and and digging more into it reminded me of a book that I read not too long ago called Utopia for Realists by Rege Bregman about how in the last hundred and fifty years or so, all the economists have been saying things like, well, we're gonna need to find a way to use all the spare time that we're gonna have through automation. Yeah. Yeah. Absolutely.

Ash:

But it hasn't worked out like that because we've actually turned out that we want more things rather than more time, which is kinda strange, isn't it? But, you know, you kinda see it around you all the time.

Ian:

Well, I I think that's actually been on purpose, and this whole thing of continuing economic growth has been centred around the idea that having more things will make you happy. Yeah. So actually, I think that it's probably true to say people want more things, but I'm not sure it's true to say that, well, it's definitely isn't true to say that having more things makes you happier. So Yeah. Yeah.

Ian:

I mean, I'm speaking as someone whose house is full of things.

Ash:

Doing a podcast about things.

Ian:

Yes. What a lot of them there are that we might say.

Ash:

I I think the other idea in that book as well, which is kind of more to the point of this, is that a lot of work is actively seen as, like, purposeless, as fairly useless. And and a lot of us acknowledge it as well.

Ian:

Bullshit jobs.

Ash:

Bullshit jobs is the is the phrase, and it's just like, well, a lot of us acknowledge that at least some of our our jobs and our role, if not all of it, are superfluous to a genuine purpose, whatever, you know, you determine that for yourself to be. Yeah. So it shouldn't be too much of a surprise that when someone if you you cut down the working week and suddenly you're a bit more productive and a bit happier because you probably naturally start to select the parts of your role and the work that's done in your organisation that make the most difference. Do you think that happens?

Ian:

I'd like to think that. But, I mean, this whole thing of bullshit jobs, I'm gonna have to bleep all these out now, aren't I? We've said we're not Yeah. We said we're a non explicit podcast, but this whole thing about bullshit jobs, give myself some more work now, is is something that's gathering momentum because it's actually seem to be better to be doing something pointless Yeah. Than to be doing something that's maybe not economically productive that has a purpose.

Ian:

And it's probably a bit of a flaw in the way society thinks, isn't it?

Ash:

Yeah. Yeah. I mean, if you translate it to, like, the world of software development.

Ian:

Oh, bloody odd.

Ash:

If your team built a a thing that made millions upon millions of pounds and it took a limited amount of time to build, and it meant that you hit all your targets for that particular year or whatever, shouldn't you just say, well, fine. We're done for a bit.

Ian:

Yeah. Let's do something to make the world a better place.

Ash:

Yeah. Yeah. Absolutely. And also, in terms of finding out what is the right thing to build, you know, really looking and experimenting and studying to see what is the right thing to build at that time, rather than just building enough stuff and seeing what sticks, even if you don't really know what sticks. Because I think this always reminds me of over the course of, like, your career when you build stuff, only really 10 or 20% of that will ever be used on a regular basis.

Ash:

Most of the stuff that I've ever built has probably never been used on a regular basis or never at all. So the real trick is finding that 10 or 20%. So imagine if you could do a shorter working week working on that 10 or 20% of stuff that makes the biggest difference. That sounds like purposeful work to me.

Ian:

Yeah. It absolutely does. And I think what's interesting is you you hear a lot more of the term social enterprise now.

Ash:

Yeah.

Ian:

I attended an event put on by the RSA, which is the Royal Society for the Promotion of Arts and Manufacturers and Commerce. She's a That's

Ash:

not what RSA is.

Ian:

That's why we call them the RSA because, their full title takes about half an hour. But I went to an event in, in Bradford, a few weeks ago, which was held at a co working space that's targeted at social enterprise. And there was a lot of people doing things that might or might not make them reasonable amounts of money. But actually, the main purpose is to make the world a better place. Yeah.

Ian:

And I think that as a driver, that's really, really increasing in popularity. And maybe that will be a great thing, you know, to get rid of or to reduce the number of so called bullshit jobs.

Ash:

Yeah. So drive it like the other way around. So let's make sure that we build something meaningful and build what people will actually want. And then you spend less time doing that work because you're actually selecting the right things to build. So I think this probably needs to be a bit of both.

Ash:

There needs to be a bit of a transformation in the way that we think about, like, the working week, for example, and how long it is and what hours mean and what effectiveness means. And then also looking at how we build software as well, as in stop coming up with giant list of requirements.

Ian:

Yeah.

Ash:

Most of which are not requirements. They're just people shoehorning things into documents to try and get them built. And then experiment to pick the right things to build, which take up less time but are more impactful. That sounds like pretty purposeful work to me.

Ian:

Yeah. Yeah. Completely agree. And adding this concept of stakeholder value on top of shareholder value. Yeah.

Ian:

So the things that you're building, the significant things that you're building aren't just targeted towards making more money, but actually toward value for all the people involved in in the, in the process Yeah. In the in the outcomes of the thing you're building.

Ash:

Yeah. Absolutely. And I think on that note, one of the one of the key questions here with a with a shorter working week or a differently structured working week or or whatever, however you want to describe it, is will it be will it be equally distributed for all? We can talk about software development context where you can a lot of the time, you can work remotely. You can work from wherever you are.

Ash:

You know, you can work whatever time you like. But there are other industries too. How would you spread the benefits to service and retail and places like that?

Ian:

Yeah. And, actually, it's a I mean, a really good question. I mean, even in software development, if you're running a service, it should be very hard to force incidents to only happen on Monday to Thursday or whatever days that of the the four day week Yeah. Sits. And productivity in that context is about how quickly you restore service or fix what whatever the problem is.

Ash:

Yeah.

Ian:

And, actually, you probably don't get a 40% uplift in that. No. And, actually, what you get is to have the same coverage, you probably need to hire more people.

Ash:

Yeah.

Ian:

So I guess the the benefits are uneven. And when you're talking about service industries as well, retail is a great example, isn't it? Are we gonna train ourselves to go shopping only on four days a week? Would I mean, I guess, they'd be a different four days, would they? I I but in terms of high street retailers who are, you know, maybe small shops, that would increase the amount by which Amazon is more convenient than

Ash:

Yeah. Than

Ian:

going out because you could just order something online. Whereas, if you're looking around for, well, you're not open today. Well, that's why Sunday opening came from, isn't it?

Ash:

Yeah. Yeah. Absolutely. So it could absolutely have side effects. And if it does get adopted wider, it will have side effects that we can't we sort of can't fathom at the moment.

Ash:

Yeah. So it can fundamentally change society as well. I think one of the things, well, just popped into my head was about rather than thinking about full time jobs, we even, like, measure the the, you know, the phrase full time equivalent. Yes. Often, we even measure things by describing roles in that way.

Ash:

Yeah. In tech, I have very rarely come across jobs which are available for job share, for example.

Ian:

Yeah.

Ash:

It's so rare. It's incredibly rare in technology, and even flexible times and hours, etcetera, I think it's still very, very the provision for that is still pretty basic.

Ian:

And it's very hard to sort of manage unless you're a large organization where if you've got 50,000 people in your organization, it's easier to smooth things across that number of people than it is if you got three or five or or even 10.

Ash:

Yeah. But I think it's really beneficial because imagine if you've got a a role for, say, I don't know, a quite influential role for, like, a principal engineer or a principal tester or whatever it is. And you can get two really great candidates to share that role and bring all that benefit to you or all that experience and skill to your organization, but you're just not set up to do that. Yeah. I'm not saying it'll work perfectly every time, but imagine the power of that.

Ian:

Yeah. That'd be a thing about alignment. Yeah. You know, having being able to agree on one technical vision or whatever it might be. But you're absolutely right that if you could if you could make that work, if there was that alignment, then you've got double the experience Yeah.

Ian:

Pulling towards it. For those kind of roles, that can be incredibly powerful. Yeah.

Ash:

Yeah. Absolutely.

Ian:

That could be absolutely amazing.

Ash:

Yeah. But we just don't seem to be it doesn't seem to be considered.

Ian:

No.

Ash:

I think, you know, as a as a person of who's been in that sort of role before but also has other interests outside of that organization, a job share would have been absolutely amazing. Yeah. It really would have been. So it would have given me personally time to do other things that I'm interested in, plus also help that organization and, you know, influence their strategy.

Ian:

And that kind of, I guess, leads to to freelancing because that's the way that you can get some kind of control and flexibility Yeah. Yeah. Without being employed. If employers could do it.

Ash:

Yeah. Yeah. So you go free so you go completely freelance because you you don't want to be within the constraints that exist within organizations. But isn't there another way of doing it?

Ian:

Yeah. Absolutely. So short

Ash:

of working weeks and different ways of thinking about how how work is done, I think would be really powerful.

Ian:

Come on, organisations.

Ash:

Yeah. Time for you to step up. Yep. Give us what we want.

Ian:

Yeah. When do we want it? What do we want? Cool. Okay.

Ian:

So I have a thing too.

Ash:

Ian, tell me about your thing.

Ian:

I actually meant I have a thing also, but it would be true to say it's a thing too.

Ash:

It is a thing too and a thing also.

Ian:

Yeah. So my thing is actually about design thinking, which is something I became fascinated by and, learned a lot about Yeah. When I was at, IBM because they adopted it in a very big way. Mhmm. It's a tool set that lets you that that is stolen basically from from designers, Stanford d school and IDEO, the the sort of, design consultancy.

Ian:

I hope I'm gonna maybe I should call them the creative consultancy, but they kind of codified what design thinking was.

Ash:

Right.

Ian:

Suppose I should go on Wikipedia and find out that it was probably somebody else that invented it, but they certainly popularized it. Yeah. And the great thing about it is that it's from design, and it's used extensively by designers. But, actually, you don't have to be a designer.

Ash:

No.

Ian:

And I think that it's really beneficial for actually many, many people to have some kind of understanding of it and technical people as well. Yeah. There's a great quote about design, from Steve Jobs. And I realized that by mentioning his name, I've alienated, like, 85% of the audience. I don't care.

Ian:

I'm gonna look at my Apple screen and read the quote from it.

Ash:

We are surrounded by Apple's back catalog here. So

Ian:

Yeah. Sadly, back catalogue rather than their current catalogue, but, yeah, can't have everything. The quote is that most people make the mistake of thinking design is what it looks like. People think it's this veneer that the designers are handed a box and told make it look good. That's not what we think design is.

Ian:

It's not just what it looks and feels like. Design is how it works. And technical people from all sort of disciplines within that, we're all about how things work. Yeah. And so it kind of makes some sense that design thinking will be something that technical people will be able to use and embrace.

Ash:

Yeah. Yeah. Absolutely. I think often I've seen that that divide in the workplace as well where designers have been grilled off into a corner and we've built a a thing which may or may not meet a need and then the designers have been asked to make it good.

Ian:

Yes. And I I

Ash:

think I've heard myself saying that sometimes as well. So rather than seeing it as like a unified process, if you like.

Ian:

Yeah. So designers and testers stuffed in at the end. Yeah.

Ash:

Yeah. Yeah. I'm familiar with that that particular process too.

Ian:

I think design thinking certainly is something that is very much an upfront thing. But it doesn't have to be just about product design, and you can apply it not just to external end customers, but to internal things and processes and stuff as well. I always think if management comes along and says, right, we're not doing any test automation. We should do test automation. Then, actually, you can use design thinking to dig into actually what should that look like in this organization.

Ian:

Yeah. Who who are who is it that we're doing it for? Whose life is made easier by it? And how can we make sure that their lives are made easier and Yeah. You actually get get the benefit?

Ash:

Yeah. I've actually had discussions. I was about to say arguments, but discussions well, both actually about things like that before where people have talked to me about test automation and wanting tons and tons of user interface based test automation. And I've said, well, what problem does it solve? Who is currently hurting?

Ash:

Who is currently being hurt or, you know, value being eroded by us not having tons and tons of this sort of test automation? And it's been like, no one's been able to answer that question for me. Like, well, point me at at live service impacting issues, which would be helped by having these tests. And I'm like, well, there haven't been any. I'm like, right.

Ash:

Okay. So where do we go with this? Yeah. But that felt like a similar interaction. I was trying to get to who's this for and what problem does it solve?

Ian:

Yeah. Exactly so.

Ash:

So right, but I didn't use the design thinking toolkit as such. It was more like just questions, about, like I say, who's it for and what is the purpose of it.

Ian:

So those are actually design thinking definitely does ask those questions. There's another quote that I like, which is, from a a luminary. Oh. Like that word. That word deserves more air flow.

Ian:

A luminary of the design world called Don Norman. And, he described design thinking. And he said, designers don't try to search for a solution until they've determined the real problem. And even then, instead of solving that problem, they stop to consider a wide range of potential solutions. That's really good because often from a technical perspective, we already have a solution in our mind and we focus on that.

Ian:

But, they stop to consider a wide range of potential solutions and only then will they finally converge upon their proposal. Yeah. And he says this process is called design thinking. But it's got this whole concept of of divergent and convergent thinking. Yeah.

Ian:

So you start off by by thinking very broadly and thinking of as many ideas as you can or thinking, as widely as possible, and then convergent thinking to zero in on on what the solution is.

Ash:

Yeah. I I like that the thought of not sort of solutionizing too early. I remember using a technique once where I was getting a team to come up with ideas about a particular problem, and we went we we came up with, like, 20 ideas. And even though there were, like, some of them were, like, ridiculous, but we kind of stretched. So we we did about 10, and then the next five were just silly.

Ash:

But then we actually got to the next five were actually really good ideas after that. Because we'd gone, like, beyond the obvious into the ridiculous, and then started to sort of coalesce around a a few ideas that were actually really good.

Ian:

That's great. And, actually, when I'm facilitating design thinking sessions, I quite often say to people, you must come up with a silly idea. Yeah. At least one silly idea. Because when you start seeing silly ideas from other people, they can spark well, actually, that is silly.

Ian:

But and then you can see some grain of real value in there Yeah. And add it to something else that was already in your head and come up with something great. And it sounds like that's what what happened in your example. Yeah.

Ash:

Yeah. Definitely.

Ian:

So that whole idea of divergent thinking is really, really great when it comes to having ideas and just trying to scan the horizon of ideas

Ash:

Oh, nice.

Ian:

For miles around rather than, you know, being too focused on what whatever might be in front of you. Yeah. But actually before that is interesting as well because that that thing which he describes as determining the real problem, design thinking really puts a lot of focus on empathy. Yeah. And so when you are solving someone's problem, there's a whole set of things you can do to to really empathize with or gain a shared understanding of what that person's world is actually like.

Ian:

And you create something called an empathy map, which sort of focuses around the observable things. So what do they say and what do they do? But also non observable things. So what do they think? And importantly, how do they feel?

Ian:

Mhmm. And then you sort of getting into a scenario of how do they achieve this thing today. Yeah. Then you're looking at in each of the steps of that. How do they feel and what are they doing?

Ian:

And you end up with something that lets you really identify where the pain points are. And I think that that really then informs the ideas that you're having because you've got a shared understanding of these are the pain points and this is what we have to solve.

Ash:

Yeah. And then often, when you're trying to transform something in an organization or introduce new ideas, there's gonna be resistance. So you need to have that empathy too and find out how people different people feel about what the proposed change or the proposed new approach. I think you I think and that I think it gives stakeholders a chance to actually express those feelings rather than internalizing them and then sabotaging your efforts later

Ian:

on. Yeah. Definitely.

Ash:

And I think that's something that I could have used probably. I could I can think of a few times in my career where it would've where it would've been a really good idea to do that.

Ian:

Yeah. It's interesting because I guess it's a bit of a journey. Yeah. And what you can't do is get to the end of the journey and then go and tell all these people this is this is it. This is what we're doing now.

Ian:

You have to make sure that people come along on the journey with you, and you have to do frequent playbacks of all the different stages. And you have to do it to all those people so that they can have the chance to say, hang on a minute. That doesn't that you you may think that helps me, but actually, it creates all these other problems. Yeah. So that you involve them and they come along on the journey.

Ian:

Yeah. So that at the end, they're not surprised by the result. And in fact, they're bought into it because they contributed to it. And that's why it's really important, you know, particularly if you're doing something, I mean, that maybe the test automation example. If you just focus on what the highest paid person's opinion Yeah.

Ian:

The Hippo. If you just focus on on that, they might have a a problem that they identify, like this cost too much or something like that. But if you don't if you haven't got the people on the ground who are using the thing or trying to do this, whatever it is, then you're gonna produce something that that doesn't solve their problem. Yeah. Whether that's involving software developers and testers or someone up there might say we would need to do test automation.

Ian:

But if you involve all the stakeholders, all of the people who will benefit and use that Yeah. Then you're gonna get a much better solution. And that seems like a no brainer. Yeah. But and maybe, all you're doing is dressing it up and saying, oh, this is design thinking and therefore it's magic and you should

Ash:

But it's the it's the tools and techniques that you can use in order to facilitate those sessions, you know, like an empathy map, for example. Yeah. That's that's the the sort of the the difference, isn't it?

Ian:

Yeah. Exactly. And if you try and find the design thinking process on by googling, the Stanford d school executive education slide that you can well, that comes up when you do a picture search. Yeah. It's got the stages of empathize, define, ideate.

Ian:

That's a word that should have less less airflow. Prototype, test, and assess. So that's, a really great kind of set of steps and, you know, prototyping and then and then looking and and seeing where you are. But what that doesn't reflect really is the iterative nature of things. And, what I I really like IBM's and I used to work there, so I suppose I should declare an interest in

Ash:

and this

Ian:

is how I originally learned it. But they have an infinite loop model, an iterative model for design thinking that has

Ash:

Yeah.

Ian:

It's basically broken down into observe, reflect, and make. It's suggesting that those things are loop and are iterative, and I think that's really, really important. Yeah. And, actually, how it kind of then can feed into agile software development and the make part of that loop might start off being paper prototypes. Yeah.

Ian:

And, actually, paper prototypes can be brilliant if you're trying to illustrate something. And there's a great Google video about how to do them, which I will, include a link. But after all, a few iterations, you're gonna be building real stuff, and that's that's how the design thinking loop kind of fits into the agile loop. There's something more to explore there, I think, but it's really, really interesting. IBM is interested in how you build the technology and Yeah.

Ian:

And how it fits into DevOps and Agile, all that kind of stuff. So that that, you know and they've designed it so that it does.

Ash:

Yeah. Yeah. It reminded me of something called an inception deck, which I used years and years ago. This was such a long time ago to to talk about, a new product that a company that I was working at was building. And essentially, it was, just a lot of exercises together about stakeholders and what the upsell for the product was and what the elevator pitch was, you know, all those sorts of things.

Ash:

So that that just popped into my head as well. So that's there's a book by a chap called Jonathan Rasmussen, which we can also link to. Yeah. So that's he's he's a an agile delivery person. But it sounds like those sorts of techniques would be at least conversant with design thinking as well.

Ian:

Yeah. I think so. I'd be keen to say that design thinking is just I mean, you still need architectural thinking and technical thinking and Yeah. And business you know, you need you can't it's not a magic bullet that solves everything. Yeah.

Ian:

But as a way of engaging people into a direction of travel and tapping into their creativity and having them and and being able to be solving the right problems, I think it's a fantastic option. Yeah.

Ash:

Definitely.

Ian:

So, obviously, we've referred to a few things in that.

Ash:

Yep. And

Ian:

there will be links to those things in the in the notes. So I think we're done. That's two things, isn't it?

Ash:

Two things talked about.

Ian:

So we'd like to know your thoughts. You can tweet at us to our our Twitter account, which is what a lot of thing.

Ash:

Please get in touch.

Ian:

And you can email us

Ash:

at whatalotofthings@gmail.com.

Ian:

And another option that occurs to me is that you can make audio recordings of your responses, and we can potentially include them in the podcast. Yes. So one thing we could do is have a follow-up section where we can, deal with audio responses, treat them with the reverence they will inevitably deserve.

Ash:

Absolutely.

Ian:

And I think if you go to our anchor.fm slash what a lot of things homepage, it might be something that's available there. I'm going to turn the switch on to enable it, but I don't know how it will manifest itself.

Ash:

So So, essentially, we promised to do a thing, and then we don't know how that thing will work. So we'll see how that goes.

Ian:

We could just cut that hole that whole bit.

Ash:

Well, you know, we we do work in software development. We're in the business of making promises that we can't keep

Ian:

Yeah. Just for another couple

Ash:

of days of quiet time so the stakeholders will leave us alone.

Ian:

Yeah. Yeah. But it's gonna be really great. So if you can find a way to leave us voice messages, then do that. We might include them in the next episode.

Ash:

So much hedging.

Ian:

The other thing I guess it's worth observing is that almost at random, we are now publishing our podcast every other Tuesday. So we are like an alternate week Tuesday podcast.

Ash:

So we have settled into a cadence which may suit us. Yes.

Ian:

Obviously, what I'm really saying here is that if it's every other Tuesday and there's no podcast from us, then, you know, basically, abuse us on Twitter.

Ash:

Yeah. I'll just check that we're alright. Yeah. Yeah. It doesn't have to be abuse.

Ian:

No. No. But it helps.

Ash:

The only thing we pay attention to.

Ian:

Yeah. That was all a joke. Okay.

Ash:

Okay. Thank you, Ian. Thank you, Ash. And thank you, everybody.

Ian:

And we'll see you all in it will take two weeks.

Ash:

Yeah. See you soon. Bye bye. Bye.