August 15, 2023
Season 1, Episode 15
In this episode, Jon and Jay dive deep into the State of DevOps Report for 2023, discussing the evolution of DevOps, the rise of platform engineering, and the importance of metrics like deployment frequency and mean time to recovery.
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:00] Jon: Hello, welcome to Cloud unplugged. I’m John Shanks and I saw and we are going to be talking about the state of DevOps Report Platform Engineering 2023
[00:00:12] Jay: to talk
[00:00:12] Jon: about a report. We’re going to give people the facts and the data like real skittish ins in the industry. It was obviously there’s been a state of deviltry parts that have come out year on year. You know, how
[00:00:28] Jay: long they’ve been going for.
[00:00:29] Jon: I don’t actually know how long I’ve been going for, I
[00:00:31] Jay: think more than 10 years or so. I mean,
[00:00:36] Jon: I guess, you know, yeah,
[00:00:40] Jay: I’ve
[00:00:42] Jon: read several years but I’ve never gone back in time to read.
[00:00:46] Jay: So like maybe we should contextualize like Puppet and devops and then the report platform engineering because there’s a real kind of link in who’s creating the report, why they’re doing it, you know what it means, etcetera. You know, just to kind of contextualize that puppet. I’m not sure if you know, is a configuration management tool. Yeah. You know, back in the day before all of this immutable infrastructure stuff, people used to have these vms and machines that they would have to manage and control the state of and you know, have configuration packages, things that were installed in those things. And you’d use configuration management tools like puppet chef fans for to manage that across an estate, right? Obviously, that’s a devops E type tool, a tool that you would use. So they’ve obviously got a vested interest in this area and understanding and educating the market about it. Hence, they’re doing a report, but it’s not 10 years.
[00:01:46] Jon: I would never have thought it was 10 years. I thought Google was involved in one of the reports before. Remember that there was a door,
[00:01:52] Jay: A one, I think there are two different reports.
[00:01:54] Jon: Yeah, I get a bit confused but yeah, I know there’s been releasing, I’ve only known them from Puppet but I haven’t really read every single one every year for like the last 10 years. Obviously, I wouldn’t have known, but I think it goes back in it from 2018, maybe it’s like a graph in the report 18 up to 22. Potentially, I think and looks at like the change of like performance of teams.
[00:02:20] Jay: There’s a section in the report where they’re like self diagnosing, whether they are a high performing team, and mid performance team or a low performance team, whatever. And what they’re saying is there’s a steady trend up in the high performers, well, self reporting that there are high performers. So
[00:02:39] Jon: Are you distrusting these self assessment of,
[00:02:42] Jay: Well I mean, I don’t know? Really? Well,
[00:02:47] Jon: I am really good. Thanks for asking. Haha. Okay. That’s 20%. That’s really good. Yeah, I think that that’s almost part of that. Is it? Not because, well, yeah, I mean, they can’t, they’re never going to go in
[00:02:59] Jay: because there’s no, like, how can you, like? No, we’ve taught, you know, even the last episode we’re talking about metrics and measurements and things like that and I’m sure there’s some industry standards like Dora metrics and things like that. But like you’re now kind of giving it to the team to self diagnose whether they’re high performing.
[00:03:19] Jon: I don’t think they do. I think they ask questions like how often you release into production these and I think maybe they’re giving the door a framework unless you’re asking those of people in the business, you probably might ask a team that the one team could. I don’t know if there is obviously like anything when you get data, it’s all got a bit of fallibility in it. So, but the point is that this is a platform engineering one. And then they’ve kind of said in it like basically if you want to be better, if you want to have better devops success in your business, that
[00:03:51] Jay: sounds like a thing I want,
[00:03:52] Jon: you want success. You want high, medium or low mentioned in no way wasn’t mentioned in it. But I saw anyway, what
[00:04:05] Jay: about like gold, diamonds,
[00:04:07] Jon: Platinum, Gotta subscribe $20, a month. So obviously ranking based on the door of metrics, deployment frequency, mean time to recovery, all those change rape. We’ve spoken about episodes. You want to listen to those, but I think they must ask the questions to assess and then they’ve seen a trend up and they’ve also worked out like more of the how and I think the report’s been very much on the what now? They’re actually maybe if you’ve done platform engineering, what’s the impact of platform engineering ways of working over devops? Plus there’s a
[00:04:40] Jay: bit of a trend in the market, right? Obviously, that’s kind of part of this report being even published and using that term. So it makes sense to summarize it. Like just that top line,
[00:04:54] Jon: basically, you’re just better, just better engineering, which I think makes sense, makes kind of pragmatic sense you’ve engineered in one place and
[00:05:06] Jay: essentially enabled developers to operate in a, you know, efficient way to do things, the clarity of lee.
[00:05:15] Jon: And therefore because of that, you end up the principles of develops around how quickly people are moving things into production and how quickly things are reliably scaling and fixing themselves. Then it’s like, yeah, because you probably put a lot of that in one way of working essentially, which then meant the probability of it succeeding was higher than being disaggregated. So I think it just proves that disaggregated versus central model and then engineering in one place, what they mean by platform engineering is left a bit ambiguous around its self service principles and do kind of talk about it. It’s got your favorite term cognitive load. There’s no door, a metric for cognitive load yet. So are you frowning? You’re frowning quite hard. I’d say that was a high, that was a high frowning cognitive load on your looks like high cognitive load, cameras, assessing people’s faces
[00:06:17] Jay: just. But
[00:06:20] Jon: yeah, so it mentions that which really, I mean, I’m not a fan of that. Sorry. It just wind me up, develop productivity, but
[00:06:29] Jay: productivity is a measure, right? But the fact that you have to context which understand all of these things, it’s part of it cognitive load because it’s a known term, you
[00:06:41] Jon: could say that about literally everything and anything, which is what makes it very specific operating model. Obviously things operate,
[00:06:52] Jay: they’re
[00:06:52] Jon: all just things that are very ambiguous.
[00:06:56] Jay: Exactly, which is our part of the thing that we’re doing. Hopefully this podcast is to help, to keep saying ambiguous terms. haha . is to help reduce the ambiguity to demystify.
[00:07:08] Jon: If you’re wanting to adopt the purpose of platform engineering is to make things better cognitive load or not, you’ll be more productive and you’ve got better velocity or you don’t. Now if the velocity is high, I’m going to just naturally assume that, you know, I mean, I could make an assumption about culture or maybe it doesn’t even matter, didn’t factor into it because you were still operating faster and the velocity was quick
[00:07:34] Jay: but faster. That’s it. It’s relative. The point is it’s relative cognitive load. And how do you measure cognitive load again? Relative, how would
[00:07:42] Jon: you measure it? How are you going to go into a business today to say, I want to assess what the cognitive load of my development
[00:07:48] Jay: into. But you can, you can as in, you can’t like quantitatively do it. You can obviously look at what they’re doing, have a bit of an audit of their practices and then say, oh wow, okay. It really feels like you’re trying to solve the world here. You’re trying to your full stack engineers, you’re doing some infrastructure stuff, you’re developing your having to do like business, eh, my reporting, all this kind of stuff, right? Like if you’re doing all of those things, you’re not going to be efficient. Like there’s no way that you can be efficient and be brilliant at all of those things. You cannot, I mean, I’d love for people to prove me wrong here. But my thought is that it’s just, it’s just not possible. So
[00:08:27] Jon: well,
[00:08:28] Jay: maybe,
[00:08:29] Jon: maybe I guess the point is, is like, I mean, that’s kind of a little bit of a facetious thing, but also maybe there is something in that, in which case, there is no cognitive load for the development is also still not a good use of the time. So irrespective, I guess the point is being productive is different from like a cognitive load experiences.
[00:08:48] Jay: Activity is probably a measure. But how can you measure productivity? That’s it.
[00:08:51] Jon: That’s what the door is supposed to be there for, isn’t it?
[00:08:53] Jay: That’s not really products like, that’s different because that’s more aligned to an outcome. Yeah, exactly. But like, developer, like how quickly you can make changes and keep. Yeah. Yeah, that’s, that’s what I’m saying. So, like, that’s one sliver of that. really?
[00:09:13] Jon: Yeah, but it’s probably the most important one to look at
[00:09:17] Jay: productivity isn’t about say how you’re meeting your user’s requirements, whether that business is succeeding or not, it doesn’t have anything to do with
[00:09:25] Jon: it. But when it comes to platform engineering also, that’s not something you would be responsible for anyway. So it’s like why would that matter at that point? It doesn’t impact, you know, I guess you’re not going to be involved in that as apart from engineering team about user research
[00:09:39] Jay: say cost, right? Dora metrics nothing to do with
[00:09:42] Jon: cost shocking
[00:09:45] Jay: but like cost of your cloud stuff or cost of the team. That’s totally agree,
[00:09:50] Jon: right? So like that should be correlated with the productivity, right? That’s what I’m saying. So the two go hand in hand, I’ve never heard of a business ever mentioned cognitive load in my life about a measurement or something that I get, I understand the trend of it’s not a helpful thing when it’s high. Obviously, I get that, but I’m not sure it’s the thing to get. So hung up on to the point of the marketing materials of what’s going on, the industry. That’s what I’m saying. I’m like, I have all the things to have spoken about. I wouldn’t have ranked it quite up there given the amount of marketing. But hey, that’s just me. So I just feel for a business, you know, there’s things in there that are saying really, really good things to be fair that centralizing is obviously there’s some additional things that you’ve already pulled on where they didn’t ask about cost, they haven’t asked about the number of projects or the application. So there’s no, again, no real correlation to a business metric to say, Yeah, I mean, we went, we are high performers and it’s costing us £300 million pounds to be high performance, right? If that’s the case
[00:10:53] Jay: and now we don’t make any money anymore. So we’re out of business
[00:10:57] Jon: business now because we’re more being a high performer, then we actually could deliver,
[00:11:04] Jay: you know,
[00:11:06] Jon: I’m free and on the market, a high performer. So it was, that’s not contextualizing value because it’s got value from a metric perspective, but not value from a financial perspective at the moment until you can see it. So I think there’s a bit of a missing piece of the puzzle which would have really helped to say, well, you know, what’s the ratio even of your platform team to developers how many, what does that look like? How many is it taking to underpin the delivery overall? And what’s the cost of that team? And what was the cost of the hosting? You know, all those things are really important? Exactly. No mention of that. Literally
[00:11:47] Jay: just about to say that, right? Like that. Yeah, that was really creepy. The thing that I was about to say was that that cost a bit. So you know what the cost is of your platform and infrastructure teams, cloud infrastructure team, whatever and the developers, the cost more so than the number of people. So we talk about chat DPT and all of this like really high, all of this knowledge is out there in the world and it is being kind of commoditized and hopefully product IZED to be commoditized, which means that you can now operate potentially with lower skill sets, more junior people, whatever that that don’t mean you have to have, you know, eight senior platform engineers to build a platform, you can just have like a few juniors to keep a lead. Exactly. So to come
[00:12:41] Jon: back to the report, it’s also saying which is controversial that people are investing in product managers for the platform teams. Do you reckon
[00:12:54] Jay: that product management
[00:12:56] Jon: going to use the research to get the requirements of the platform they’re building? And the question is okay, like that feels quite like that’s a high investment. Now at this point, maybe it’s valuable, but it’s like you’re now going down a path of more role types on top of something that you’re really committing to this platform, internal platform at this point.
[00:13:20] Jay: And it’s quite niche like product, product management obviously has been around for a little while now. Although in a lot of businesses, it still seems a fairly new concept, right?
[00:13:29] Jon: Some traditional
[00:13:30] Jay: businesses, traditional business and stuff, I think what really seems like a stretch is having products managers for the cloud and devops C type space. How mature do you think that is overall in the market? And then because obviously what the report is calling out is that they should invest. Yeah,
[00:13:51] Jon: it does really lead you to that. People feel that there isn’t an investment in it and it isn’t prioritized that was in the report. But also it’s like, well, that’s because it’s not a product you’re selling. Exactly. So why would you be investing to that extent where it’s going to be the ROI and this investment for the business overall? And if you haven’t done your due diligence and attaching to the money anyway, to prove out that this platform you are building is returning R O. I didn’t bother you just looking at Dora, then why would you be and why would a business invest in such a high, you know, such a high set team unless you could prove that we’re going to get it from A to B we’re gonna drop whatever it is, we’re gonna have faster revenue or whatever it’s gonna be, it’s gonna pay for itself this team because we’re going to do these things and these are our goals and these are metrics, this is the team, we’re going to need to do it. And actually, you know, we’re gonna smash it and new markets and, but I never hear that. So it’s like, I don’t see where probably our businesses, maybe that do do that and have got good business plans around why they’re justifying the platform team. And I’m sure there are organizations that do do it. But I’d say that was an exception to the rule rather than the rule. And it doesn’t suggest you do do that in the report either. When you’re saying to advocate for a platform team, it’s very siloed, it felt like a very siloed report and it’s a bit frustrating because devops was already kind of a little bit siloed, which is an anti pattern to what it was supposed to be embedded. It was supposed to be getting the right behaviors for developers better velocity. And it’s like you are technically getting that, but it is still a siloed way of thinking and not necessarily matching the business requirements and what the team cares about. The
[00:15:37] Jay: the thing that you just said though, which was quite good is platform team versus platform engineering team. And just like to pick up on the nuance of that like platform engineering feels like your engineering something and building something which might then mean that, you know, having a product manager against the thing that you’re building makes sense. Platform team is probably more aligned to like what your function is like cloud platform team in the business, right? And then it doesn’t necessarily dictate or imply how you should achieve that outcome, you know what I mean? And like I’m just wondering about like the what this industry is doing in terms of like how they’re using the words to imply and infer that you should be doing
[00:16:25] Jon: loads of engineering? Exactly. Or are you going to find the right things within the team? That means you are platform centric exactly without doing loads of engineering because they are very different and you’re going to hire loads of engineers mean you’re planning to do those of engineering. Yeah, I mean, that’s definitely true. So team platform doesn’t necessarily mean that it’s doing those of engineering necessarily do. It doesn’t mean you have to be specializing so much in platform engineer is an outcome.
[00:16:53] Jay: It’s not the way you do it.
[00:16:55] Jon: Yeah, exactly. Accountability to
[00:16:58] Jay: accountability, responsibility. Maybe given we’ve sort of defined what platform cloud platform engineering teams are supposed to do. Make sense. So, yeah, what else does the report say? That’s interesting, pretty much
[00:17:13] Jon: from the top, from a high level without getting into the details of the percentages of improvement and all these other things that was kind of the take home. So it kind of frames what I think is for people that maybe didn’t know about platform engineering too much. So it’s framed what it is. It’s starting to frame why it’s important. But under the lens of devops, obviously, it’s the state of devil’s report. I don’t think it’s helped what’s kind of oxymoronic in some ways for the report is it wasn’t in line with the methodology of devops in some ways because of the missing information that wasn’t in it the same as Dora, but the metrics of which are surrounding diva are not all the metrics, not all the right metrics you need when it gets to a business. And so it still feels if your methodology is about bringing business value for developers to and getting the right behaviors for developers to attach to business develops as a methodology even still was slightly siloed from the organizational elements because it was more focused on, I feel a more detailed orientated problem of like, you know, this team and that team in the silo in the bridge. So it started off to try and fix the silo, but it still left itself kind of slightly siloed. It’s really weird on the way that I
[00:18:34] Jay: think about it is like devops is a philosophy or culture, platform engineering or platform teams, whatever is a practice, right? It’s like this is how you would embed this philosophy or culture and achieve in an organization efficiently with like a
[00:18:53] Jon: thing. The philosophy was about collaboration as well as collaboration means that you’ve got to be collaborating on some common value in the business and the common value of business would be a business goal. And that in itself when you stem it down isn’t just deployment frequency, of course. And I feel that there is exactly. And therefore I felt there’s some missing metrics a little bit, all of them.
[00:19:17] Jay: Like they’ve done obviously a good job, you know, it’s relevant, we talked about it and things like that. It’s also probably quite hard to get all of this data across the, you know, the major kind of industries and verticals that do this. I’m
[00:19:32] Jon: not saying it’s bad, you know, I know it sounds just because I’m picking on a specific bit of it, the rest of it’s really good. That’s what I’m saying. And also platform mentioning really good. I think it leaves a lot of ambiguity still sometimes. And if I was a senior leader, you know, CTO or somebody, and you’re like talking about advocating for devops, I have to show value. That’s my job. There’s financials, I’ve got a report on these things. Does it help me as a CTO do those things? It will do elements of it, but I have to attach to the money somehow and that maybe is the job of the CTO to also do
[00:20:12] Jay: business case
[00:20:13] Jon: as to why to do it to contextualize it. Maybe it’s not the thing. But what was interesting is you talked about philosophy and a way of working and I’m not sure that this report picked on that when you read through it, not necessarily know it was more about performance and principles and self service and all these things over kind of philosophy per se. Maybe, maybe it’s a shoot.
[00:20:42] Jay: And actually, right at the beginning of the report, I remember it saying that they no longer use the term devops recommend using because it did mean something and now it’s been like over used in the industry and
[00:20:59] Jon: cognitive
[00:20:59] Jay: load. So it’s, it’s like changed, it’s just made super ambiguous and people mean different things by it. Sometimes it’s a role, sometimes it’s a culture, sometimes philosophy, sometimes it’s like a product as your devops.
[00:21:16] Jon: Yeah.
[00:21:18] Jay: Yeah, we do, we do as your box. Exactly. Exactly. So it’s just like all of these terms have not helped to make that thing a well known thing that you could just point out and everyone knows what they mean. That’s what language is supposed to be reduced, the ambiguity and not add to it.
[00:21:37] Jon: But we’ve spoken about like okay our objectives, key results and measurements and those things like if irrespective of the philosophy of it, what matters to the business is like stitching the results back to an objective, right? And that’s why you’ve got okay, ours, for example,
[00:21:54] Jay: that the alignment of, yeah,
[00:21:57] Jon: then you, you can then measure like the effectiveness of what you’re doing. That’s the aim, right? So irrespective of like philosophies and methodologies, they’re like approaches to achieve it, right? So it’s like, yeah, go and research, get your trade, understand like ways of working and things that you can do to achieve like any discipline. And so like engineering has disciplines within itself, the more granular level from unit tests and all these other things and all that and that goes on for all different disciplines. So I get it like, obviously learn their trade and have the principles and understand it. But from measurements perspective, it’s still, I still feel it’s, I don’t know, just like the results are important ones. And then I think there needs to be more overlaid over the top to actually say like, did we meet the objective of the business in line with what we expected? That’s all because who else is this report for? If it isn’t for the business, who else is adopting devops, not consumers? So it’s like, you know, it’s not like it’s just the average Joe at home being like at home, it’s like it has to be for companies. So it missed a little bit of a trick I think to have given more data points which have been really that that report would have been so amazing if that lens was put over the top of it because it would have really helped contextualized, maybe the size of the businesses and the cost that they’re investing over all those extra, additional data points would have made it really more tangibly understandable of the value. And then
[00:23:32] Jay: I think, I think it does some way of describing or talking about the investment or areas that their businesses are worried about. So whether it’s like security or investing in self service or
[00:23:47] Jon: prioritized, observe ability and things like that.
[00:23:50] Jay: Exactly. But then I guess I’m just tying them to, like, I just think
[00:23:56] Jon: There’s a reason why you need those things and it’s not necessarily explain the reasons. I mean, we can assume the reasons but it’s like, I just still don’t, is having 75 people, You know, with a 1-1 ratio, developed 75-75. Yeah,
[00:24:13] Jay: I mean, I know of a place with similar that’s set up in a similar way we’ve spoken to, obviously lots of different
[00:24:23] Jon: companies and just not just not sorry, work who’s
[00:24:29] Jay: making these decisions,
[00:24:30] Jon: not be engineering so much that even some of the things that they were engineering, there’s tools out there to pay for them. Yeah, I’ve already done exactly what you’ve just engineered better. Everyone,
[00:24:48] Jay: you don’t have to come into a place,
[00:24:50] Jon: really don’t need to do it again. Reinvent the wheel. You
[00:24:55] Jay: get a lot of that. Right. Like, it’s like people with a hammer, everything is going to be a nail it’s like if you hire a bunch of engineers and maybe that’s part of the thing that they’re trying to articulate as well. Right. So, like, if you’re gonna hire a product manager, then they’re thinking about building a product, building things. If you’re doing user research, then hopefully you’re leaning into the problems that you’re actually solving the value that it gives. You should definitely do that, like, do some research within your organization that even the wider sort of business trying to figure out what it is that you’re actually
[00:25:35] Jon: definitely, definitely agree with that product manager or E thing, which does this kind of needed. Really, you’ve got to know your users, you’re building things for and you’ve got to invest, the developer would have to be involved in a lot of this to know you, what you’re doing is actually helpful to the
[00:25:51] Jay: roles, sorry, maybe not a job specifically that someone because it feels like a really weird thing to invest in without really truly understand the problem. So it’s like a role that someone wears continuously wears to make sure that their
[00:26:10] Jon: developers get feedback, do surveys on them, make sure they’re happy with the tools
[00:26:14] Jay: and then also like documentation and things like that. You’re always going to have documentation in an organization or should because you want to understand like what the choices and principles that you’ve aligned to and why you’re doing
[00:26:28] Jon: cognitive goes up contribute to before you know, it’s a
[00:26:36] Jay: problem. So it depends,
[00:26:40] Jon: just wondering because it’s such an issue. Apparently engineering that I just wanted because you like it so much. I was like when you’re doing good documentation,
[00:26:48] Jay: you reduce it because you know how many
[00:26:52] Jon: lines like that? I
[00:26:56] Jay: love these questions really useful. What
[00:27:00] Jon: I would love to have seen though is operating costs, operating costs on that team and in context to the revenue of the business that is that they were supporting that I would love to see, I love to see that information just out of intrigue just because I don’t really and I, I wouldn’t know, honestly, obviously, I mean, we were Christians, but I would never know. And I’ve got some assumptions, but I’d love to just, I don’t know all the numbers even for all these businesses, you never get it necessarily. But it would be so interesting to see.
[00:27:35] Jay: So in terms of like how, how businesses do this right? There is a thing, it’s called cost of goods sold and you know, you good old. So you’ve made X money and it has taken you something to deliver that value and get that revenue, that’s cost of goods sold. And that means all of the things. It’s like operational costs, overheads. But you know, the people that in this situation, it could be like your cloud costs, the people that you have in your teams and licenses all of that stuff. I would love, love, love to see the related to devops and platform engineering for the cost of goods sold like that so good. And then maybe even broken down on a person, sorry, like people resource kind of employee perspective and then like a license and operating costs, like compute and all that stuff. I’d
[00:28:34] Jon: love that would be so cool. I know. I would like to see that. So intrigued because it’s, the principles are correct and the methodologies are correct and those things, it’s not like that’s bad. It’s just you never get the rest of the picture to correlate it to something and it’s always a bit hidden and you never really see it. And if you’ve seen it in businesses and I’ve obviously worked in places and kind of known sort of the operating costs of the team and things like that firsthand. But that’s just in one org and I’ve never managed to compare to another, maybe someone’s gonna really much better job. And you’re like, wow, that’s phenomenal what you’ve managed to achieve.
[00:29:12] Jay: Exactly. So, I’m just thinking about the report in general and data in the report being actionable versus non actionable. So the actionable things in that report are, if you’re trying to do and, you know, roll out those kind of principles and philosophies, then platform engineering that’s known, right? Like that’s, there’s data that report shows it, that’s the way to do it, the other stuff which is not actually the stuff that we’re talking about, that kind of articulates some of these questions, whether it’s the right investment, the right mix of investment in that team and how you
[00:29:49] Jon: should really what you’re benchmarking against though, if you don’t have the other stuff. Yeah. Well, well, how do I know for that business? That was right, because unless I’ve looked at enough businesses of similar what centralizing? Not that, no, I get that I could still do the centralizing badly. So that’s what I’m saying. It could still central east and it might be really expensive and I still could get the right metrics. But until I, until I benchmark since being like, well, these companies have done it at this price and I’d be like comparative comparatively. Maybe I’m like, oh God, man was way higher than now. It just helps you be better because you’re like, you drive for a different, you want to speak to them to see how they did it, help share knowledge and information that would help the business. So without it, it’s like, you know, you can centralize and your team’s doing it really well, 100% it’s just you don’t know who they are and like what well really meant outside of those things, which feel it was just really cool. If you could be like, man, you smashed it that you managed to deliver all that value at that price point. Absolutely. Nailed it like go and post the team. No, but yeah, I just find it, but I’m an inquisitive person. So I kind of like to see the full picture. Yeah, rather than a partial slice. Yeah, but that’s just me. So anyway, that was the state of devil’s report. My, we should put a link. So,
[00:31:31] Jay: findings, we’ll put a link to where you can find the report as well.
[00:31:39] Jon: Yeah, that’s a really good idea. Definitely. Yeah, and as always we’d love to hear from you. So, like, comment,
[00:31:56] Jon: subscribe. Cool. Cool. bye
Part of the Appvia family.