August 15, 2023
Season 1, Episode 25
In this episode of Cloud Unplugged, Jon and Jay delve deep into the intricacies of product management and delivery management. They discuss the roles, responsibilities, and the blurred lines between product managers and product owners.
In this episode, you will learn:
Themes Covered in the Podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
[00:00:14] Jon: Hey, welcome to Cloud Unplugged. I’m John Shanks and I’m Shaw. Um, and I think we’re going to be talking about product management, delivery management and, basically, whether you do need them
[00:00:26] Jay: or whether you need them at all. Maybe you don’t just never need to deliver anything by end the podcast. Great. Thanks. Um, no, it’s a it’s It’s quite an interesting topic, isn’t it? It’s like, um, a lot of teams nowadays. There seems to be a bit of a like a thing that’s set in the industry. Like what a good team multidisciplinary team looks like with delivery managers or product managers, maybe both, or, like service owners, product owners, um, user research, all all of the things that go into building products. I guess we’ve in our own company. We’ve probably had our experience of this right going from one to the other and things like that. Um what? What are your thoughts on how to make delivery efficient? And actually, I guess there’s a difference between, like, building and discovering on a product like the different stages of the life cycle of the products. And then what’s right for each one, given that you’re sort of playing this role. Now what? What are your thoughts?
[00:01:30] Jon: Um, so this is just my experience. So I don’t know if this is the same as as as other people’s, but depending on the stage of the product. Um, until you’re getting good, like traction from and feedback on that traction really well and probably a little bit more in mass plus like data to start to inform decisions, then the vision is probably more important at that stage on what you’re trying to build until the point that you others can steer the product for you. And so I I’ve kind of felt as an inflexion point of which a product manager could do What would be classified as traditional product management, which is like user research and user feedback, doesn’t mean that you can’t test things and other things.
[00:02:18] Jay: But so you reckon the product owner is more important because, like set A and all that kind of stuff at the beginning of the journey?
[00:02:25] Jon: Yeah, I probably caveat that for like, there are other tactics you could probably use, depending on the type of product as well,
[00:02:32] Jay: because if it was like a really simple
[00:02:34] Jon: or something
[00:02:36] Jay: could be quite complicated to deliver on, depending on what it does. But I guess it’s kind of the complexity of the product and how many, how multifaceted or singular it is in that If it’s just doing, like, one or two things really well versus being a bit of a platform or doing lots of different things, of lots of different sort of pieces, then it probably involves, like, quite a lot of technical and vision setting and all that kind
[00:03:04] Jon: of stuff and the go to I mean, this is this is the issue because it’s commercial and the go to market also doesn’t have to be
[00:03:10] Jay: commercial. It could be an internal product.
[00:03:14] Jon: Yeah, so I mean, so I mean then, yeah, I guess what? What it is what it really is and then what it is you’re trying to do, because if it’s you know, if you’re gonna launch into being a free thing, then the expectation is quite different. So you might start with like, free and therefore people are OK to give feedback, but it doesn’t matter because it’s free as in like you just there’s no cost to use it or don’t Yeah, exactly. There’s no cost to them. Obviously, cost to use business if it is a
[00:03:39] Jay: business cost to them is adoption
[00:03:41] Jon: and time. And they’ve got to give their time up. Um, open source, where they can get to contribute it to contribute to it is then different because they also get to shape it so they feel more involved than maybe just using it. Um, they can use it and improve it. Um, and then commercial is obviously different again, because then it’s like another play where you kind of have to entice people in to want to use it, kind of have to do it.
[00:04:07] Jay: Then you’re almost like product marketing manager, you know, product market manager with a bit more of a marketing hat on, because you have to understand what the landscape is and you write messaging and all of that
[00:04:21] Jon: stuff. Yeah, exactly. There’s a lot to it that’s not just the product, but taking that away. I do think it’s important depending on whether you can or can’t get the feedback you need to set direction. Then whoever is set in the direction in the product owner, whoever is the vision is probably needs to be highly connected to what’s being delivered because otherwise people don’t really know what the scope is of the story. And, you know, when is it finished? And you know, what is the real feature really aiming for for this and what’s the experience we want?
[00:04:52] Jay: I guess. Could you do you reckon you can have enough process instead of having the roles? Because the, you know, ultimately roles are just doing a thing. Um, and obviously they have a skill set, but it’s like a really, it’s, um you bring people in that have certain skill sets and put them into a role and give them responsibility and stuff. That’s not to say that other people without that specific responsibility or or without the title couldn’t do it like facilitating.
[00:05:20] Jon: That’s
[00:05:21] Jay: so like, for example, in in agile teams you don’t have to have a delivery manager that is the scrum master. You might have a a lead developer. You might have just a normal developer wearing that hat. So in the same way do you do you think that, um, I guess product management could be done by a I don’t know, lead developer. In fact, when you when you’re working on, like, a tiny, tiny thing and that’s it. Yeah. Yeah, exactly. You might be playing lots of different roles.
[00:05:53] Jon: Yeah. I mean, obviously, I think anything is possible. Anything is possible. And people, I think it boils down to probability of characteristics in a person and then also what they waited for. So if if the developer likes engineering more than maybe the product thinking, then they might start favouring just shipping something, um, you know, because they just want to kind of kind of do it. Um and that’s the same even with people that, like, want to manage people
[00:06:19] Jay: Great, though, isn’t it, like, literally shipping.
[00:06:22] Jon: But maybe shipping is something they haven’t really thought through. But you want to get validated or, like, tested the hypothesis of or like, you know, So it depends if they’re biassed in action just to do the engineering because they’re excited. But the cost might not matter. I mean, it doesn’t matter, but, um, but it’s the same principle with, like, people that can be good managers and being a good manager and being like technical, being a good technical manager, you know, people might want to also do the code and contribute to the code rather than maybe favour management and other people might favour management over contribute to it like everyone falls in different places. So I definitely think it’s possible. It’s just where you’re waiting one more than the other and where one is more important than the other. I don’t know a timing thing,
[00:07:06] Jay: isn’t it? I guess characteristically people always kind of not always, but a lot of the time you see people just leaning into, um where they’re comfortable, right? Um, and what they enjoy what they enjoy, what they enjoy, where they’re com, because there’s momentum, right? You do what you’ve you’ve always done for the most part, and it takes a lot of, um uh, a lot of kind of foresight or or planning or whatever to to do something different because you’re a bit of a you need a bit of a catalyst to change. Um, so if you’ve always done it and now you’ve got a new role and you have to do something else, you’re still gonna kind of like when when you get promoted or something like that in a job, then you’re you’re still kind of doing your old job as well as doing a new job for a while, right? It’s just habit. Exactly. Um, so I I can I can definitely see that in terms of like man managers, technical managers just get the code
[00:08:05] Jon: and then product. I think the same applies with everything. Like, I’m sure there’s archetypes of businesses out there where they’ve all done a different. They’ve all solved it in a different way. And I’m not sure. I just know from first hand experience that, um depending on the complexity and depending on the stage, whoever’s stage of the product. Yeah, whoever’s got whatever it is in their head and if others can’t quite see it, translating something high level into very specific detail is, is, is hard with If you know, as a normal product manager, you can’t see inside your head. So you know, getting out what it’s supposed to be could end up being very like high level like epic, you know, themes. Not necessarily how anyone’s going to break that down, because it’s so ambiguous. It could be that, like I’m not even sure like what the ask is exactly like I know we need to do a thing, but like what actually is the thing we’re trying to do. It’s funny,
[00:09:03] Jay: because that is the role I
[00:09:05] Jon: know it’s the wrong, but but to to not have users to say Well, because you’re seeing how they’re using it or to not have some to start with very little and to suddenly be able to unless you’re from the domain and you understand it really well and everything else can be very difficult. Part of the
[00:09:22] Jay: process, though, right? Like there is a research that exists for a certain thing. And then it kind of depends on whether you have, like, competitors or you have things that are vaguely solving the same problems like you can’t read. I mean, you, you you absolutely could, um, go and try to solve a problem without necessarily know how anyone else is solving the problem. But you’ll probably waste a lot of cycles because development is expensive. Yeah, exactly right. So So there’s leaning on like a good way of doing this and understanding what you’re actually aiming for, Like what your US P might be in the in the thing that you’re trying to
[00:10:03] Jon: solve. But then do you sometimes think, though, like, you know, all the books, this book, all of the books, all the books which I think, read, read, read loads of them and then there’s, like, lean canvas and all these other things. I think I unfortunately like a bad realisation, especially me, is like I have to learn through failure. It doesn’t matter what I’ve read. I can read it and hear the theory, and I’m like it all makes sense. And then, for some reason, even though it made sense, I don’t adopt it right. For some reason, it’s like, Oh, I think I’m kind of adopting it. But I’m maybe not, um and then it’s only through the failures. I actually realise that I didn’t adopt it, and and it does now make more sense on reflection, because I failed at it and then, But now you kind of understand the detail of the application of it, and that’s quite hard because you can hear and everything’s like on paper. You’re like, Well, obviously like that makes lots of sense like it. It’s it’s pragmatic, but yet you can still not apply it thinking you’re kind of applying it. Maybe or like, your situation is harder to to find ways to achieve those things can be hard, um, without compromising things that I was saying, like maybe compromising a business model right where you’re like, Well, I don’t know, say, like you gave it all free and you don’t have a good monetization strategy on what you’ve done for free. And maybe you don’t have the next killer feature to hook somebody into something as an example. And the risk is that you’ve given the value all the value away for free, and you don’t know how to monetize it. Um, and a lot of people
[00:11:35] Jay: lean into support and you know all of those. Yeah,
[00:11:37] Jon: and then it’s a different business model. So it’s like, it’s hard to to do. Not like this. This topic I got off on tangents. Um, but we’ve I’ve kind of, like read lots and done things, But then I think probably process for me the importance of the process. But I’m a processed person, maybe, and I’m a structured person, is like, I like the discipline of things. So I don’t I feel uncomfortable when there isn’t a little bit.
[00:12:06] Jay: But then it’s quite a lot of discovery, right? Um, so being quite comfortable in discovery and curiosity is is normally not necessarily so process heavy because it’s it is exactly that as discovery. And I think maybe, like you might lean into that a bit more than, say, process necessarily. And then
[00:12:27] Jon: what the hell
[00:12:31] Jay: the world is here in this, Um, even if you go if you follow, like a set process of kind of discovering with the user what you might might be doing whatever, like sometimes it’s valuable to just lean into something because you have an idea and you’re curious to, you know, explore that idea and you’re unique in the way that it’s been that you’re attaching to it right or solving it or whatever. Um, so but
[00:13:02] Jon: I mean more like the things that we spoke about and you you like, standard stuff of like when is this actually done? When is this? When is when are we actually finished? You’ve spoken about a kind of feature, but that feature is like never ending theory because it’s such a huge, huge epic of an epic of an epic or something. It’s like When are we ever? When are we ever done with this feature? And like And then what are all the things that have to be done? Um, that allows it to be successful and not just the fact that it functionally did it the way that we thought it was, and that’s it. That’s all I have to worry about. But
[00:13:34] Jay: that’s it. You’re talking about a feature
[00:13:37] Jon: like the delivery management side as well,
[00:13:39] Jay: but that’s to say so. So products aren’t built with features. That’s an implementation of something they’re built on. Solving a user problem. Use a story right? That’s why that exists. So, like, even even in in the way that you’re kind of like it’s a it’s a mindset thing. So, like feature bugs features cool you can. You can put your hat on something like That’s what you might take offs in jira or or whatever, but it’s not really solving a problem. Like only using, uh, you’re you’re only solving a problem with a feature with a known thing that you’re
[00:14:19] Jon: you’re right. It needs to be a story of which you’re trying to achieve,
[00:14:25] Jay: and that might be done through a future
[00:14:28] Jon: very fair. Yeah. Um but even that I mean, I was just thinking more on the delivery management aspect of our product managers responsible for, like, the definition of Don. Is that more of a delivery management thing? And would you expect a product manager to be also worrying about like, like, are these all broken down into sizable things? We can iterate on this sprint, you know? Can the team’s velocity is it? Is the team velocity good? Are we story pointing like, How much can we deliver? Per sprint? Um, are we sizing things appropriately like, Do you think that’s a product manager’s duty Or and if it isn’t, Who’s is it? Yeah,
[00:15:05] Jay: I mean, it’s It’s a it’s a That’s a funny one as well, right? Because, um, like, uh, we’ve worked in teams where we’ve had, like, product or service or product managers and delivery managers and sometimes agile coaches all at the same time. And then it’s still the team that’s doing that stuff. Do you know what I mean? Like they’re they’re obviously the ones that have the domain expertise, so have to go through story points. And this that and the other and then maybe one or two of those roles are just responsible for facilitating some of those meetings. Uh, delivery manager. More kind of managing the delivery up to their stakeholders and saying, Hey, this is the reporting. This is the velocity of the team. We’re kind of tracking on target or it’s a bit to the right Or do you know what I mean? Like, that’s like project management. I know exactly. But like you say, the term and I mean it is it is a project, isn’t it? In the end, at the end of the day, it’s a project for it. It’s either a project or a product, and a product might have lots of projects
[00:16:13] Jon: in it. A product might have lots of projects in it. It’s getting quite
[00:16:17] Jay: so, Yeah, so, like you, you might, um, do like a short stint of a spike. You can almost call that a mini project. It’s just like names, isn’t it? It’s like you just like naming something, You know
[00:16:32] Jon: it. It just communication. At the end of the day, all you have to it just it’s literally just terminology and words at the end. Vibrations going into your ear, and that is all it is, just vibrations, frequencies. But honestly,
[00:16:48] Jay: like there’s obviously, um, a kind of preconception when you say Project or Spike or something like that, because you know, people are, like have an understanding of what that might mean. But in the end, it’s kind of the same thing, isn’t it? To a certain degree. I
[00:17:03] Jon: mean, that’s what I don’t know, because it’s all a bit. I mean, yeah, it’s sometimes it can be a bit semantic, but other times they were like there are real roles and definitions and and you can, you know, when you kind of go to the market and you look at lots of different roles and you’d be like, Right, go get your job description for, like a product manager, right? And it’ll be pretty much roughly the same. But you know, the way that business operates isn’t really the same. And there’s probably loads of things that weren’t on that job spec that they’ve probably got to do. Um, you know, just based on the culture of the business of roles that were missing or roles that aren’t missing, I mean, who knows? But nothing’s like exhaustive right, They’re not going to go through and, like, list every intricate detail and a job description. And I
[00:17:46] Jay: also don’t necessarily know the characteristics of the people that they’ll be directly working with. So then, like because each team has to be sort of balanced in what it’s doing or it doesn’t necessarily have to be. But a high performing team would be. So where, where someone has a bit of a weakness, you might pick that up. Um, and that’s not in a job description. Exactly.
[00:18:07] Jon: And if you think through the process, it’s like someone needs to know what users want. Who’s that person? Product manager, apparently. OK, cool, Right? So you’re a product manager. You’re supposed to find out what the users want and then, like, you can do that through user research, testing, validation, whatever you want to do, uh, market assessments, things, etcetera, etcetera. But then, like once you’ve worked out what they want, then the team, whoever the rest of the people are also have to figure out how to build that thing based on what they want. Isn’t
[00:18:32] Jay: the user research also describing kind of that?
[00:18:37] Jon: Well, there’s a prototyping, I guess which is the bit that you could do to go and validate whether what you think should be built is the thing that they might want to be built. But then somebody has to direct the prototype even of what it is. We think it could be, um, to go and get validation on. And then there’s, like all the kind of user research element of whether the feedback you’re getting is enough to give a direction of, like, whether that’s the thing you’re even wanting to build in the end. Like was that even matching? And it’s
[00:19:06] Jay: an art form in itself, like asking the questions in a way, so to not lead them down like a a answer.
[00:19:12] Jon: And then maybe there wasn’t anybody with a vision of it. So actually, what you did come up with wasn’t very visionary, right? So it didn’t challenge much of like what was there already or it wasn’t differential enough or it didn’t rethink the problem through and come up with a different solution to the problem. So many permutations of it, which is then, like so who was responsible for that bit? Was that supposed to be the product manager to also come up with, like, really good ways of, like doing it as a team autonomous And then then you got the delivery aspect over the other side. So I kind of feel that there are two distinct roles because if you’re doing a lot of that discovery working it all out, you probably don’t have time to, like story point and do the ceremonies and do all the other things and do all the check ins. And because you’ve got to also you might be, you might be in other meetings. So then you’re like, Oh, I can’t attend But there we go. Managers are too busy. I
[00:20:09] Jay: think you’re You’re, um, kind of joining the product owner and product manager role because you’re talking about
[00:20:17] Jon: Tell me what I’m doing. You accusing me of just using a product version,
[00:20:25] Jay: the product, but to to to a certain degree, because, like vision and all of those things aren’t not, um, to describe something and to have that kind of acceptance criteria and to, like, accept that something is done and the team can start working on something else isn’t that role well product owner and product manager, those two definitions get mixed up a lot. Um, but But I
[00:20:50] Jon: did kind of distinct depending on the autonomy of, um but yeah, III. I totally agree. So but I still do believe actually, product managers and delivery managers are quite different. And I don’t I kind of think if you if maybe it’s possible for, like, a lead of a lead in a team to become like a delivery manager. But I also think, would they partially choose their own stories with bias? Everyone, This is really easy to do because I know exactly how to do it. And they’re like, I’m going to bring it in this because I think it’s going to be quick. And then suddenly they’re like biassing.
[00:21:27] Jay: Suddenly, it’s like 50,000 story points. Exactly.
[00:21:30] Jon: They’re biassing it all, all the all the things that they think should be done in the
[00:21:39] Jay: I’m the delivery manager. It’s fine.
[00:21:40] Jon: Yeah, which I think that’s the conflict. So I think there’s too much of a conflict of interest there, and yeah,
[00:21:45] Jay: you’re probably right. And and and actually, if you separate the the roles, then the value that you get from it is not as distinct from the team, right? So obviously the the value is very much linked to how the team is doing. But you can measure it separately. Whereas if if, like a Dev is doing the delivery management role, how are you measuring that? That that person is even successful in what you’re doing? Like there’s too many
[00:22:14] Jon: hats because I’ve got to converse. I have fluctuated on the value of a delivery manager where I’ve not necessarily seen the value as much. But maybe that’s when I was in teams myself.
[00:22:27] Jay: It’s such an engineering mindset, right? And then But you’re just asking people what to do. Like you’re asking people if they’ve done something or what to do or when, when they’re going to do it or something like that. So, yeah,
[00:22:38] Jon: maybe if you’re a bit if you’re if you’re a bit of a hybrid type of person, then you can also plan and you don’t find that very hard. Yeah, and you’re like, I don’t really get what we’re getting out of this. Like, um, especially if you’re a lead who maybe can is a bit multifaceted, but actually, um, in truth, I think having somebody who, um is neutral in that team also probably helps other people facilitates, facilitates well so that everyone has a voice and that the dynamics don’t shift accidentally where somebody that might have might be multifaceted, even like myself, doesn’t dominate by accident or doesn’t have ways of, like, getting things through. That may be jokes I
[00:23:23] Jay: could be saying here, but
[00:23:25] Jon: maybe just but yeah, so that then it’s getting the balance of the team. Right? And I and I hadn’t necessarily clocked that before were of like recognising the softer side of definitely being neutral and actually the be benefit of some, like a Democratic way of
[00:23:43] Jay: because delivery management, I guess, is bringing the most out of the team,
[00:23:49] Jon: not individual people, which, if you are a person in the team who’s also doing the delivery
[00:23:55] Jay: to be very selfishly driven
[00:23:57] Jon: by, even if even if you were, like thought you were very democratic and thought, actually, you know, I no, I I’m definitely that person who would accidentally get my own way. Kind of. Yeah. So yeah, so, um yeah, I think actually, delivery managers and product managers, I think are probably necessary in my conclusion. What do you think? Who do you think?
[00:24:25] Jay: Um, I. I think it is very much down to like like you said, the the the time, um, and life cycle stage of the products, you know, whether you’re kind of discovering and then growing and then like, gaining type of thing. So you are, um I don’t
[00:24:44] Jon: know. What’s worse is the fact that you’re always talking about it. I’ve never once listened to you. Wow. Um, which is really bad to admit, but I don’t know what graph you’re talking about. Wow. I really I don’t know which one. You honestly, which is really bad. What is so so
[00:25:05] Jay: basically, there’s, like, three stages of a, um, of, of, of any of, like, a company of a product of of whatever, Um the the first stage is always, like, kind of discovering what it is you’re doing trying to get to some level of, um, validation, right? So whether that is, you probably don’t have like, um, market fit, product market fit or something like that. And then the next stage is growing.
[00:25:39] Jon: I remember exactly.
[00:25:45] Jay: And then, like, the last stage is like getting as much as you possibly can out of out of it. So, like, if you’re if you’re in that sort of early discovery stage, um and you don’t have domain knowledge of the problem that you’re solving, then there’s probably little value that maybe I don’t know, Uh, a product manager with little domain knowledge you’re gonna bring or a, um you know, if the if the team dynamic is quite well organised and they you know, there’s like, um uh they’re quite democratic in how they’ve organised themselves or it’s a small team. Then maybe you don’t need a delivery manager. Um, because you’re in that discovery phase and the budget or the funding for your thing might not be huge. Um, but then I think as you grow, then, um, you lean more into process because that’s the only thing keeping you keeping you, you know, going, um so you probably are right. You might need both, I think
[00:26:50] Jon: because it’s slightly different skills that bring different things to the table. And I suppose it depends on what you’re wanting in the team. What outcome? I suppose if you got the outcome you’re striving for as a business and what’s the team dynamic? You think will yield the best result. And if, like the things we’ve mentioned are going to be problematic. If there’s like a John Shanks in a team who’s also a delivery manager and maybe a product manager who’s gonna favour all his own ideas and get everything, is that what you want? So I guess if it isn’t then you want to make sure that you avoid those traps by accident. That guy already, what does it take? What does it take to get rid of that guy? Because I would buy us a lot for, like, simplicity, smaller teams, leaner teams, maybe, like wear a few hats. You know it’s OK. And then it’s only really if you kind of challenge it and put the lens. I don’t know if that’s going to get the best result in the end. When you do it, it’s more cost effective. It’s definitely probably, you know, makes it a little bit more efficient in terms of like time, because
[00:27:57] Jay: every person you add to the team costs you right most of the time. Well, what is it? Is it Is it Dunbar’s law where they talk about the size of the team there’s always there’s always some law that I I like, miss uh um, like a paraphrase or or just, like create a
[00:28:17] Jon: bars, I could be wrong. Obviously, Conway’s law is the way you reflect the business system reflects the business and then done. But one of them is like where the worst possible thing that can happen does happen what that is, and I don’t know what dumb bars is. II, I
[00:28:31] Jay: thought I thought one of them is, like, um, talking about the,
[00:28:37] Jon: uh, a book of laws. We need some. It would be so
[00:28:42] Jay: useful. Honestly, Yeah, exactly. But, um, one is about like, um, like, how many relationships you could have, Um, And like, you know, there’s like you can have high five high performing
[00:28:59] Jon: The optimal thing, like 100 people is when you start to see society, even society works by those
[00:29:08] Jay: exactly exactly that. Right? So So, like, um, a team of five is kind of considered the perfect amount. And then you have a kind of wider team of, say, 15 or something like that and it grows and it grows. It grows. It’s referred to in like team apologies and a bunch of other kind of, um books, uh, in and around the same topic. So I’m hoping I’m getting that right. But, um uh, that kind of high throughput information can’t. Doesn’t scale. It can’t. That’s the whole point. So when you need to maybe communicate with more people and and you have, like, a a potential bridge to those people and that might be the form of a delivery manager, it might be the form of, like a product donor, because that’s that’s doing other things that they’re managing up as well as managing managing the delivery, it might make sense. Um, yeah,
[00:29:59] Jon: yeah, optimal team sizes before it exactly. But you can fit them into feature teams. You could? Yeah. You can always keep lean teams like but
[00:30:08] Jay: component teams.
[00:30:10] Jon: But it is an expensive thing to have somebody managing processing people all the time for each team. I mean, it might might yield the best results. Um, but it’s also quite
[00:30:24] Jay: quite expensive. Like everything you do is expensive, right?
[00:30:27] Jon: Everything I do is expensive.
[00:30:29] Jay: Totally. Everything you do is expensive, but in general, in general, like this, like technology, um is just gone ridiculously expensive. I think maybe in the industry.
[00:30:42] Jon: I don’t know if the bubble the bubble has kind of burst a bit. A
[00:30:45] Jay: lot of redundancy. It’s
[00:30:47] Jon: like not as it was. It was crazy
[00:30:51] Jay: in the last. It is obviously covid. People have obviously hired been been a bit nuts,
[00:30:56] Jon: right? Yeah, That was like another hype within the hype, because before covid, it was already hyped massively and then Covid was a different type of hype. And it’s fear, fear and hype at the same time, because different businesses also didn’t survive, obviously, depending on what the
[00:31:10] Jay: business was. And now we’ve just returned to the 2000, 2021. So we’re still hyped because it’s still Yeah,
[00:31:18] Jon: it didn’t go back to what it was prior, which is
[00:31:22] Jay: still, it feels so insane. But everything is technology. Now we’ve massively digressed.
[00:31:30] Jon: Yeah, maybe we can talk about that in the next episode where we’ll go over what it takes to hire the right capabilities and train people up and get them in the market. And if you need to have maybe existing technical skills or non technical skills, what do you favour soft skills over tech or tech skills over soft skills, et
[00:31:48] Jay: cetera. And maybe, like what? What type of characteristics fit roles? Yeah, that’d be quite cool to
[00:31:54] Jon: explore. And let’s not forget. Also, we do have a new website for card unplugged IO. And there’s also the YouTube for carded and, um, LinkedIn, twitter, et cetera, which has all been done rebranded. So here, just putting that out. So you know of you and I looking like two people that didn’t quite make the cut from a boy band in the early nineties or
[00:32:19] Jay: something? Definitely got the haircut for it. So I don’t
[00:32:21] Jon: know. I’ve had this haircut since the since I got rejected. I That’s it. Before it was X factor. So you didn’t make it on I? I didn’t. I didn’t. I’m pretty bitter, but luckily our dreams come true
[00:32:38] Jay: for me. And if you didn’t read in between the lines here, we’re looking for three more people to join our boy band.
[00:32:45] Jon: Check out the new things and thanks for listening. Thanks. All soon. Bye.
Part of the Appvia family.