August 15, 2023
Season 1, Episode 22
In this enlightening episode of Cloud Unplugged, Jon engages in a deep conversation with Colin Humphreys, the CEO of Syntasso. Colin shares his extensive experience in the platform space, tracing back to his roles at VMware Tanzi, Pivotal, and Cloud Credo.
In this episode, you will learn:
Themes Covered in the Podcast:
Quick Takeaways:
[00:00:00] Jon: Welcome to Cloud Unplugged. Thanks for being here on the podcast. I don’t know if you want to introduce yourself. Tell you a little bit
[00:00:04] Colin: about yourself. Awesome. Yeah. Thank you. My name is Colin Humphries. I’m the CEO of a company called Makes an open source framework called here today. Some free advertising there. Yes. It’s an open source framework called critics that we make. It’s to help people build platform products. So it’s a framework to help people build platform products. And I feel like every kind of word in that sentence needs to be decomposed and unpacked. We need to work out, that is, But that’s what we do at SSE. We build tics, Framework building platform products personally founded the company two years ago. Prior to that, I was chief technologist at VMware Tanzi. Prior to that, I was cto at pivotal. Prior to that, I was CEO of a little country called Country Company. An entire country called Cloud Credo and the team at Sys. So were the leadership team we had at cloud credo, and they’ve been through the pivotal VMware journey as well. So we’ve seen a huge amount of platform space over the last 20 years or so. So we’ve seen and done a lot of the wrong ways to do things. And we’re trying to now start doing things you know, and I o to better keep learning from our mistakes. Keep adapting. So we’re trying to just improve how we help people build great platforms.
[00:01:13] Jon: OK, so by platforms, because it’s quite a, I guess, overused term, but in lots of different contexts. So some people, you know, like I speak to somebody before and they might have like a they might classify their application as a platform because it’s got loads of components on it. So by platform definition, you kind of for developer like developer elements of enabling kind of developers to ship code and ship applications. Or I guess that’s the context. Yet this is
[00:01:38] Colin: a great question, by the way, because every term we use in our industry seems to be so heavily overloaded, the platform is a good one. Services, I think, is the term that’s banned because I talk about services in the past and someone would say, Do you mean services? So I’ve got, like, my data base and my cash or do you mean services like professional services like services just means so many things to so many people like it has a service platforms massive, heavily overloaded. So you do have to define the term. But also, even then you spoke about like, four developers. And I think it’s one of my kind of little bug bears because, like on the podcast, I want to bring my my real self here. And when you see my real self, I immediately start thinking this thing annoys me. That thing annoys me. So let’s just get this first thing out right now. So I think often people use the term developer to mean somebody who works on a team typically building an application that drives business value and makes money. And then they talk about somebody who works on a platform team almost synonymously with like operations and operators. And my real passion here is arguably far more like platform development. So I think an application team should have developers or people doing a development role. People doing an operations role, people doing product management role like design roles, a whole bunch of like responsibilities on application teams and a platform team should also have developers on it. So you’re saying it’s a platform for developers and I’m like, Yes, it helps people doing development at the application team level. But at the platform team level, they need to have their own developers, operators, design product managers. They will roles within a platform team.
[00:03:03] Jon: So that kind of rephrase and so the the consumers are the users of this platform downstream user. So they do like user research on what it is they’re building. The user research it be performing for the platform team would be for the developers to find out what it is like, how they want to work, how they need to do things so the user downstream user would be of a developer for platform. In this
[00:03:24] Colin: case, I think there’s developers on the platform team, and I think on the application teams there’s developers, but also the people should be operating their applications. A really good vernacular, I think, has been tremendously effective. I can’t speak highly enough about his team. Topo. I don’t know if you’ve read the team apologies book, but thoroughly recommend that people on the podcast I’m not I’m not on a kick back But after saying this, I’m going to try and get a kick back. So Team Topology is amazing book. It provides a very simple vocabulary for how we describe teams and they talk about four team types. One of those team types is platform teams and another one which I’m saying application teams. But effectively, what’s with that is streaming align teams. That’s how they describe it. And the stream align teams is is the teams that drive the flow of the business and get the business value delivered. So the role of the platform team is to make the stream aligned teams lives easier to be specific about that. So they talk as well about this concept cognitive load. How can we make life easier for the stream aligned teams? How can we mean that they have to think about fewer things while they’re delivering business value so they can be more efficient, high performance, be more secure, all of those kind of things. So I think the thinking about it in those terms is a very good way to look at it, so that also gives you the context by which to look at a platform team. What that platform team delivers could be all manner of things. It could be just technologies. Could be tooling. Could be guides could be just so many things that they could deliver. But their criteria for success is to what extent are they making life easier and lowering the cognitive load for those stream aligned teams? I tend not to say stream aligned teams unless you’ve read the book. It’s a weird concept. I tend to say, application team, platform, team. But yes, so that’s why I had to unpick so much there to back when I’m talking about platforms. It is this team who are, or multiple teams who are helping out those application teams to make their lives easier.
[00:05:09] Jon: Yeah, so I’m gonna be quite unpopular because I do love teams apologies. But I don’t like cognitive load. I I don’t dislike it. It’s like one of those things that does that’s so immeasurable. It kind of is meaningless because I get it. It’s like, but I’ve never gone to something like your cognitive load looks really high right now, and so it’s like it’s such a difficult thing to rash what you’re measuring against when you say it if you see what I mean, whereas like productivity as a measurable thing. And if cognitive load is an impact of productivity, then just say productivity. I
[00:05:36] Colin: like that, John, By the way, I think a big fan of the whole. If you can’t measure it, you can’t move it. And therefore, cognitive load is tough to measure, but I think when we lower it, we can observe certain outcomes getting better. So I often think a good way to talk to the platform teams. I mean, Dora Metris on the application teams are a good way of looking at it. So if you look at those, how can we help them drive better doom Meric. So when their cognitive load is lowered, they will be able to be more productive. And then we will see these things get better.
[00:06:01] Jon: But it feels like productivity is the thing, because it could be that they’re just not highly skilled in that job, and therefore the cognitive load is high, and it’s nothing to do with the platform. It’s just that they don’t have experience with the technology, so it’s very difficult to be like, Oh, well, if we solve this but It’s like, Well, how do you differentiate? I don’t know. It’s quite a child thing. I’ve kind of like it conceptually, because it kind of makes sense. Obviously, you know, in lots of different contexts, like having just a high cognitive load, no matter what it was. Whatever you’re doing cooking, if it’s a complex recipe, whatever it kind of is, it kind of makes sense, but it’s quite an immeasurable I I don’t have an issue with it conceptually, just an issue with it. In terms of like business value recognition. It’s like it can’t measure it. I’m like, I don’t know, I just stick with productivity. That’s how I feel. I was a bit a bit of a I could be proper, massively unpopular people like, cos people. I’ve heard people use it a lot. I like a bit of an
[00:06:46] Colin: outlier. Call it as you see it. Definitely like, say, this is this is just us having a chat on a podcast. So I call it as you see it, I do. I mean, what I can say maybe to empathise with you is that I definitely have an internal look up table of team topology, vocabulary to things that I would say to people in general, unless I know they’ve read Team Topo. So I have to have this, like look up. So I, I tend, generally tend to pull out like cognitive load, and I chat with someone who I know isn’t familiar with the concept I’ll talk about like their job is to delight. The platform team’s job is to delight the application team to make their lives easier. How can we help them like get to value faster? How can we help them have fewer failures? I might start almost enumerating the door of metrics or talking about being helpful, And I think all those things are repercussions of lowering the cognitive load. Yeah, I think just making life better for those teams like is a very easy way, a very easy way to get to that. Then you talk about how do we measure that and how do we move those needles? But I also just want to come back to you saying about the word platform being so heavily overloaded, a number of people we have, where the we were working with, we have a platform team. But the stream aligned teams Organisation are also building a platform and it gets very complicated. And also, I’d say the majority of people I’ve been speaking to maybe the last five years have platform teams as I would identify them and don’t call them platform teams. They typically call them S R E Teams or Dev ops teams or support team or something else. Yet to all intents and purposes, they’re what I describe as a platform team because their job is to make life easier for other teams in the organisation. So it’s been very interesting to see that. And I think S r E teams I’ve never seen outside of Google an S R E team that s r E as per the Google Book and has error budgets and the page is passing across. So I think nearly all S R E teams are actually platform teams or even just operations teams, and nobody I’ve seen outside of Google is doing r E in the right way, with the error budgets and the page of passing responsibility for the APP passing across based upon the down time of the application and its availability and
[00:08:34] Jon: doing engineering on the application itself. because I think in Google they actually fix the problems to improve in the APP itself, being responsible, like for the scale or reliability of it, so they’ll be able to contribute. Whereas I think you’re right. I think most of the time you just see embedded devs in an application team kind of performing operational tasks, but not necessarily being true. R e. And yeah, that does definitely
[00:08:55] Colin: see that. I think just to agree with you that I think how useful vocabulary is it’s tough to communicate, isn’t it? It turns out it’s so
[00:09:01] Jon: tough. I probably walk away thinking everyone’s understood me and probably everyone’s been just equally like. I probably confuse more people that I’ve probably had sensible conversations, but in my mind, I said, Oh, that went well and they’re probably bamboozled by the time I’ve, like, walked away and probably like no idea what was going on about all these
[00:09:14] Colin: different terms. I think we try to because I’ve done that. I’ve bamboozled with so many people. I’ve been taught and tried to do a reflective listening. I repeat, back to you, I grew up and those things become like cyclical where like you reflect back and they’re like, That’s not quite what I meant, But let’s try this out. You end up in like, a circle of misunderstanding where everyone’s trying to reflect everyone else. But it never quite closes the face, the situation.
[00:09:32] Jon: So I guess then. So the platform framework, which is for them platform teams. So I guess the team that’s made up of like a multidisciplinary team is what you’re saying. Who wants to build a platform product? Is that what you would classify as, or just a platform? What was the classification at the end? I suppose when you use the framework, what does it
[00:09:51] Colin: give you? So I think you could call it a platform product. That’s interesting to describe it in that way. I think looking at a I mean, most people start with something they like to describe as a platform, and then hopefully you’re evolving towards a better platform. I think the product element gets super interesting to discuss, so I’m going to make some controversial statements here on the podcast. Why not? So platform engineering is currently a very fashionable thing. I’m a big fan of platform engineering, but I see it absolutely as necessary for building a good platform but not sufficient for building a good platform. For all the reasons, I just enumerated so in the same way that if I had a team and it was 100% engineers and I expect him to build something that was awesome, really delighted all my users. I mean, what’s going to happen next because they’re going to be lacking the skills around product management. They’re going to be lacking design. They’re going to be lacking the components of what I call a balanced product team. So whenever we talk about platform engineering, it’s great. Let’s do some platform engineering because we’re going to need some engineers to build a good platform. But we’re also going to need product management to help us understand, like the use cases, et cetera, designed to help us have that empathy with the users and think about the experience. We’re going to need to talk about all the parts of a balanced team. So I think platform engineering is just the first step towards platform as a product and having a product mindset so that we are building platforms that are there to address the needs of the users back to what I said in terms of like, thinking about our streamline teams, our application teams as customers, you know, they’re the customers of this platform, and we need to have that customer focus a dedication to delighting them all those parts that make platform as a product. So I see platform engineering the current fad as just one sub component of platform as a product, and the other sub components are obviously product management and design. And I think that the platform layer product management and design are incredibly neglected disciplines. And nearly every question I get asked about platforms in terms of them not going well is you know, things like, I did a two year chart build my platform. I spent 10 million quid on it. I bought the platform and nobody used it. And it’s like, Did you get fast feedback? Did you work in small batches? Did you do any kind of validation with your users? I basically described design and product management in terms of a series of questions to the people that have built these platforms, and it’s just like No, no, no, no, no, no, no. We sat down and did two years of engineering and no one’s using it. And the business says it’s a complete waste of money, But we think we built the world’s best platform. It’s the most amazing thing. So this is why I think platform engineering is great because you know you want to build actual value. But in the absence of platform product management and platform design, it’s going to be a wasted effort. You need to do small batches, fast feedback you need to learn with your users. You need to empathise with your users. You need to focus on your users. The two year chart of spending a huge amount of money on loads of really, you know, building an amazingly fancy spaceship like those days are gone and and good riddance to them. And do
[00:12:34] Jon: you think then, because we’re in the same space? I suppose in some ways I’m not doing myself any favours, But I got to say this, but I can kind of understand, like, I suppose, the investment cost if, like from the business side, if I was to wear, take our hat so and then pretend I was like a customer and put that hat on. You’re probably going to yield some cost benefits and cost value, obviously, from doing platform engineering. But it is then a constant cost centre because you can never resell it. So like other products investments, the aim is that it drives a revenue stream. So having a multidisciplinary team kind of makes sense because it’s going to be like, potentially on most businesses. It should be revenue driven, I imagine, because it’s gonna be kind of the business. A platform isn’t directly revenue driven. It’s revenue connected, but it’s always then gonna have a cost to it and an investment cost to it constantly. So I can imagine people not. You might not necessarily see it in such a way to think of it in the way that you’re saying, because of that, to kind of want to work in that way cos you’re like, Why do we need so many people to facilitate the like the rest of the business, why I am going to make money for those products and why are we treating this as if it is the same? And it isn’t the same if you see what I
[00:13:42] Colin: mean? Thanks. That’s a great question, by the way, I really appreciate that. And I think talking about the business case, I think that’s been one of the easiest things to talk about. So my kind of lived experience with this is that way back when kind of late nineties, when I started very much everything was Devon up? OK, so you’ve got developers writing lots and lots of code, and then they say they’re ready. It works on my laptop. They throw it over the wall to operations and then operations. Try and deploy it based upon some run book or something, and the whole world falls apart. OK, I’ve taken brands. You. I’m not going to name them big car brands, big airline brands. I’ve taken them off line for multiple days, trying to deploy code and having it all break on me. E JB one from Java B ones. They went so wrong and huge, huge outages across like really big brands and and everyone then points the finger of blame at everyone else. It’s like when it works on my laptop or it doesn’t work in production. Who cares about your laptop? I’m gonna come and throw your laptop out of a window. I’m gonna throw you out of a window, et cetera. That’s the kind of conversation you get into. That didn’t work too well. So then we had thankfully late noughties kind of 2008, 2009. The move towards Des trying to culturally bring these groups together culturally, think about driving shared outcomes together. And that was great. So I think people really jumped into DeVos because it was far less toxic of a relationship between these kind of groups. So what you then I think saw was You saw the Emergency Dev ops teams in large organisations. So I’d go to banks and they’d have multiple hundreds of Dev ops teams. And what you’d see is effectively the people who are in operations mixed in So cross functional teams mixed into the development with the developers and each team would be assigned a small product and that was great. And then effectively, they have their own choice of what infrastructure. You’re going to use what you’re going to use in terms of like, you know, your tin, your everything, like choose your cloud, choose whatever you want to do. So I’ve seen this many, many times multiple hundreds of devs teams. But what you find is each DEVOPS team then builds its own little platform, their own platform for their own application. And when you saw, like, micro services, come along as like let’s do that so each team may be building out like 20 microservices inside that one team. Not a great idea. I don’t want to go to micro services right now, but you saw that happen quite a lot. And then you saw they have to build their own platform to run those micro services. And what you would see is multiple hundreds of very similar looking platforms emerging because you can’t run without something to run it on. A platform needs to be there to run it. So you see hundreds of platforms emerging, and you typically see these teams, particularly in large organisations where there’s lots of regulatory stuff compliance, governance, et cetera, all of that kind of stuff. You see these teams spending most 20% of their time actually delivering business value and 80% of the time working out how to get the platform and the infrastructure to be compliant to be governed to work properly. All that kind of stuff so effectively you might be looking at an organisation with, say, 5000 developers and effectively 4000 developers worth of time is on building platforms. So you might take 100 of those developers and build a great platform, and then you’re gonna save yourself like 3900 developers worth of time. Now, you don’t have to fire those developers. You can put them actually on to building great business values. Another way to look at it is you’re going to five the capabilities in your business and when they’re delivering those capabilities because they’ve got a platform which hopefully delivers things as a service when they’re needed that are relevant and bespoke to the organisation. Sorry, listeners, if you’re not watching, you’re listening. I was slacking my hand there next to the microphone with emphasis. I think what the kids do when they clap as a service bespoke for emphasis. So when you get that platform that really is delivering great outcomes inside the business, that means before when everyone would have a long time to value because you have to like you get your de ops team going you build your platform, et cetera. Now people are like, Yes, I need some Web serving. I need database. I need cash, I need your identity. I need this And they’re just making API calls and getting those things. And they’re just getting on with the business they need to be getting on with rather than thinking about platform building. So when we see platforms be successful, it’s tremendous business outcomes, and I think you can talk about productivity going up exponent. You can talk about efficiency. So that business, if it’s kind of a steady state business, I wouldn’t recommend this, but they could fire the other 3900 developers you know, have a massive cost. Cutting it like the efficiency has gone up. But then you talk about security and risk as well, because if that team of 100 are doing an amazing job of building a great platform that encodes all the right governance and compliance and everything else into what’s been offered as a service from the platform, that means there’s so much less risk in the business because people are using effectively standardised, well governed components to build all their stuff. You know the platform provides all of that and therefore your chances of a data leak. Your chances of, you know, being hacked. All that kind of stuff is massively reduced in the business. So I think there’s There’s so many ways by which platforms can bring tremendous gains to the business on so many aspects that I found that part of it to be, you know, very easy to talk to people about. Yeah,
[00:18:11] Jon: because I’ve kind of said this before. I probably don’t know, but because if you’re spot on with all those things, I guess if if everybody’s reinventing the wheel, there’s a high cost to that we invention anyway. And if you’re all solving pretty much the same problem and all the things you’ve just said all like the non functional requirement elements around it or compliance requirements, et cetera. But what is interesting as well on that is like the market. When you look at the markets, the cloud security market is exponentially growing, and that means there’s a bunch of symptoms being caused by something so the root cause isn’t like well, you know, I signed up for Cloud. We haven’t used it yet, but We’re really worried about security. You’re like, Well, clearly you’re not. You’re only worried about it after you’ve consumed it. It’s like so kind of what’s going on, then on the consumption of it, where you’re now worried about how you’ve consumed it. So surely there’s a problem manifesting on, like how you are actually consuming the cloud for it to be such a concern that you now have to go and get something to tell you, like whether you’ve done a good job or not, you know, and how you’ve configured it on what the risk is. So it’s the preventative side for that Cause is a thing. That’s really how you’ve done it is the problem, really. And that’s what platform engineering is to solve, really, isn’t it? I think
[00:19:17] Colin: as well. Yeah, So it was like following through that history I was talking about like Deven, Ops, Dev ops. I think those Dev ops teams and the combination of that with the forces are coming in from micro services. They’ve caused a tonne of problems. I mean, they also did a lot of value, if you just imagine. I think what’s happened is those teams were focused on getting lots of code out quick, and we’ve been able to throw out so much code very quickly, particularly with containers. We just got, like, stuff running everywhere. And someone came up to me a conference a while back and said, This is when, um, heart bleed. Do you remember like there was like, loads of SL vulnerabilities coming out with All with amazing brands were coming out like the same, like one after the next, quite a few years ago. And they came to me and said, I’ve got 30,000 containers running and I scanned them, and the vast majority of them have, like, s exploits all over them. What can I do about this? And at the time I was talking about Cloud found I have a lot of experience with Cloud Foundry and kind of like pas as we knew it, so kind of 12 factor Pa is like and cloud foundry. And they said, you know, you’re talking about Bill packs here, and you mentioned about if we had this kind of thing. So if we had a customer way back in the day that had 200,000 applications running, all of which had an SL vulnerability and we swapped out a component called a bill pack inside of those applications, and it upgraded all of them, just as is so because they were using a platform and one of the components of the platform was the dependency, such as SSL. You just swap out the bill pack and it upgraded the whole lot, so that’s 200,000 done in a single command. Now, this person said, I’ve got 30,000 containers. They’re all of, you know, unknown provenance, like they just come into the platform. What do I do about them? And I said, You can only contact the container Authors certainly sort out. So I think that emergence of you absolutely spot on with your point about that. The security tool where security tool is like taking off because we kind of causing ourselves a huge number of problems by not having great platforms that kind of take care of that for us. You know, there’s so many teams out there. This is the cognitive load point again, like if you’re building your own platform, you have so much to worry about, particularly in a large organisation. Teams that have to take care of it themselves. How do they get anything done? Because you’ve just got so many concerns that aren’t the business value you’re trying to achieve. So that’s why I I’m a big advocate for people building great platforms to help those poor people that have to deliver the business value like get on with their jobs. I do want to mention I sound like I’m just here. Evangelising platforms Platform, platform platform.
[00:21:25] Jon: No, I think it’s good, though, because it’s a market, isn’t it in itself now I think it’s kind of become a recognising the same as you’ve got the cloud security market and you’ve got, like, monitoring and logging and all these different things, and it’s been around a while. It’s not like it’s new. I think it’s just because maybe the complexity of all the different things out there, like there’s so much choice, in which case like how are you integrating with all of this choice and who’s integrating all this choice together into something that can be meaningful to somebody else? So I think platform engineering as a thing is obviously just kind of necessary to function well in a business. But there’s the misconception of what isn’t an actual platform that you were saying and kind of product teams. And doing that, I think, is probably the linchpin of like, outside of measuring velocity and doom. Meric, which are quite I think more productivity and reliability focused. They’re not cost centric, so you don’t have, like, operational cost in that it doesn’t talk about scale of a team like, What’s the balance? You know, if the door metrics are amazing, But I spent 200 million Is that good? You know, is like, Am I doing well? And it’s like, What’s the cost ratio of the Dora in context and security and other things? Because it’s so vast? It focuses on an element of it, which is really important. And then there is a whole other bit that’s kind of not yet recognised as much in the industry. So I think some of the things you’re saying around the the team and the makeup of the team and knowing it uses and researching what they need and making sure you and investing, you know, from an engineering perspective and making it right is really important because that’s the frame, what it really is. You’re building at that point. Do you know what I mean? And the importance of what it is you’re building because it’s got complexity to it, and it needs to be thought about properly and needs to have the research in it to do it
[00:22:58] Colin: justice. You raise some some good points here, John. I was just kind of like moving on to a second ago. And I think there’s some bad things I’ve seen happen with platforms that maybe a bad platform could be masked in amongst all the metrics you’ve just described. And I think the key sign I think of a bad platform which wouldn’t get picked up by any metrics we’ve just mentioned is when those apps teams are forced to use it. And you see this happen in so many businesses that we’re going to build a most amazing platform. We’re gonna spend 20 million on it. It’s gonna be great. They build the platform and they say, Well, we spent 20 million on this thing. Now everyone has to use it. They’ll shout, use the platform. This is bad for a few reasons. So, firstly, it removes the feedback mechanism from the platform because you just got 100% adoption. So now you have no feedback mechanism. It removes any kind of learning because you want people for an application teams to be trying out new techniques, API s tools in the industry and saying, Hang on me, this seems really cool. Can we do a prototype with you on this thing and then we’ll start to use it on our team, and then you can see if other teams want it, and then you can use us as a sense making mechanism and then take that out to other teams. That’s how you start to grow your product, API. The moment you say to people, you can only use the things on the platform. You can’t use anything else. Your platform is almost fundamentally going to be terrible. From that point onwards, it just is. It’s like bad platforms. Start from mandates of thou shalt user platform controversy.
[00:24:08] Jon: Would you say about the SARS cloud like you shall use AWS, would you?
[00:24:12] Colin: Yes, I would. The streamline teams drive the business in terms of the actual money coming into the business, and they’re driving the outcomes for the business. So they need to be the king makers. They need to book we makers. They need to be deciding what is of use to them. If you tell them this shall be of use to you. I mean, sure they’ll use it, and it might be tremendously reliable. But you might find there’s something else out there that can make them 10 more productive. Something else out there that can make them much more efficient. And they’re not using it purely because of this mandate. So your platform’s ability to learn and adapt, as we said earlier about being a good product, the moment you mandate your platform form shall be used is no longer a product. It’s just a platform. You’re just back to the world of platform engineering again. And this is why I think you remove your ability to learn and to create a continuously learning platform product by mandating people use it. I think some of the more effective ones that I’ve seen because you mentioned about how it’s not an internal revenue centre, why not, even if you create some kind of a token system, just like some kind of charge back something where you can see, people are consuming these things, and I can see how much they’re consuming it. So I can see if they’re using other things because I’d rather use those other things so you can see so some kind of notion of having feedback baked into the system. I think you need that to build a good platform, whether it’s real money being exchanged or not. I think you need to have that sense that if we’re going to provide post as a service internally, people have the option to go and use like r DS or, you know, Google Cloud sequel or whatever. They they can use whatever they want to use, but they choose not to, because the one we use internally is kind of wide into all the right places. The data is going to be the right place for, like GDPR and governance and all that kind of stuff. They know if they use our internal one, they get a better all round package than something they take off the shelf. That’s where the internal platforms can really add value because you know it’s the right thing for you to use, and you’re choosing to use it because it meets all of those things that you need.
[00:25:54] Jon: Yeah, that does make perfect sense. It is tough, though, to be fair, though I mean not mandate. I think it’s fine and you shouldn’t have a mandate because you just use it or like basically, that’s it. You only get one choice, and the choice is my platform at the end. But I can also see too much choice who you know. Facilitating so much choice is also problematic in itself because as much as you want to be able to support, you know the right thing across the business. If there’s an element of scale on that, then the choice is exponentially grown, too. There’s going to be an engineering cost to make sure that all of the things that you’ve got to do have got to be kind of catered for. So you like that’s the trade off again is like it’s hard because, like, am I trading off now on? Do I scale up my team to support all the choice internally? It’s just a difficult balancing act of like, Can I get more money, please, because there’s more choice needed over here and we need to do a bit more engineering, and it’s like, OK, yes, but couldn’t they use something else? Because isn’t that just quite similar to this other thing we’re kind of using like Well, it is kind of similar, Yeah, but it’s apparently better
[00:26:50] Colin: and thank you. It’s a really good point, and I think we’re describing there again. Is product management Product management is not saying yes to every feature request. It’s nearly always saying no to things and it’s being white. There is a better way of doing these things. So this is my point about like when I talk to people about what goes wrong with platforms, they often describe product management back to me, and I thought, That’s what’s happening here describing like good product management, them back to me. I think if it’s the stream, align teams, if they want to go like actually I’m not going to use these things. I want to go and use these other things. I think this comes back to another thing we said earlier where the stream align teams should not be just developers. They should bear the operational cost of the decisions they made when they go off platform. So I like to talk about this in terms of skiing, which is a slightly weird analogy. But like the ski runs are like your platform. You’ve gone out there, you’ve looked at where it’s safe. You’ve put the lifts right next to them. You’ve piece bashed them so they’re lovely and smooth. People can go and have a great amazing time on those lifts. Fantastic. This is your platform. It’s like your kind of paved path analogy. It’s like if you stay on the platform, you’re all good. We know you aren’t going to get into trouble, OK, if you go off, there’s bears. There’s rocks, there’s trees. How good a skier are you really? And people need to feel that because I think quite too often they go and make some bad choices and they throw it over to operations and say, Yeah, I’ve just selected this random bunch of stuff to use in my app, and I just write the code and look, it works on my laptop, and now you sort the rest of it out. So those teams, they need to feel the pain that they’ve incurred, so they need to be not just application teams in terms of development, but they also need to be application operators. So if they choose to go off piece, that’s their choice, and there will be times when they choose to, and it’s quite right to do so. I work with a team that needed, like, 40 gig internal networking for their data, couldn’t get out of the cloud, had to buy some tin and they bore the cost of those decisions. And that’s what made their app work. So there are times when it’s the right thing to do because you need that functionality. But they need to be aware that they write this like, bizarre over the top like Rider for, like, the platform people where it’s like, Yeah, I want M and Ms and taken out You go bear the cost of this. They need to be aware when they take those choices about building esoteric things. This isn’t about making their CV better, like they need to that team and them they are going to bear the cost of those choices
[00:28:47] Jon: that they yeah, that’s really good, actually, because I think that at least coerce behaviours on wanting to play around with different things, but I guess we covered quite a lot of different various things because there’s the requirement handling, which is like the product management aspect. Probably do it in the way we’ve just kind of discussed on, like, Well, that sounds similar to this and this and that needs a level of domain knowledge having domain knowledge and product management skills very difficult in our space, I would say, because that’s quite a hard it’s not impossible. Obviously, I think people can learn product management skills. But to understand engineering, to understand the personas, to understand the overall outcome you’re striving for, and then the ecosystem that those developers are kind of surrounded by that a plethora of skills.
[00:29:30] Colin: I think too much to expect any one person to have those skills. I think that’s why you need a balanced team very much. The platform team should be regarded like in a similar way. You would regard an application team that that set of skills, I think exist in their one person, and if they did, they’d be such a generalist, they wouldn’t be good at any of them. Therefore, you need to like focus on constructing a balanced team But I think your point, your earlier point about not revenue generating or not perceived as revenue generating. I think some of the short sightedness we see in business so they don’t allocate those key skills onto those teams. It’s just the people that used to do. Operations are now relabeled platform engineers expected to get on with it, and I think that under serves the people on that team who are going to need support in terms of those new disciplines also under under serves the business. I mean, I gave an example about a business like five, their productivity and their efficiency. Who doesn’t want to do that? And yet I think many businesses I speak to are too short sighted to realise this. But people there’s
[00:30:14] Jon: probably a misperception, though, I think because it’s so ill defined anyway, people are measuring things. What you’re measuring against isn’t hugely expansive, and I think most people, and maybe people can definitely disagree with here, is that tools people C. I jobs is a platform, right? So I trigger AC. I job, it runs some tooling. It’s got configuration to it, you know, we’ve got a team of people over it. We’re a platform team because it’s kind of what I would call like manual automation, where it’s got human beings in it. It’s not really and that, you know, human beings are almost like a gateway to this platform and not the actual platform isn’t really a consumable thing,
[00:30:54] Colin: Thank you. It’s a really good point, and I think the opportunity to plug something that’s on website. We have a little micro site called Four Journeys, and it talks about some of the like anti patterns of platform building, trying to help people understand where they are now and how they can move towards better. So I think what you’ve just discussed is one of those kind of anti patterns. So the key ones I wanted to mention, I think a lot of platform teams fail by providing effectively the keys to a public cloud and then saying, Off you go, here’s AWS access, that’s it off you go or giving people like raw Cuba and saying like you’ve got Cuba, just the K API, just whatever we’ll make sure, like the CTS are running and like the API servers are running in the schedule and you just do whatever you want now, so it’s entirely up to you. So I think a lot of people hand over infrastructure and say like it’s done. And what actually happens in those situations is because the infrastructure is in no way customised or bespoke to the business that it’s in. They’ve still got all of that cognitive load, and all of those concerns are building their own platform. They’re just building on something slightly different to V MS or in some cases, just on VMS on the public cloud. So you’ve in no way you have a platform team. If you hand out like what API s straight over to the teams from Public Cloud or Ktis, you’re an infrastructure team. Let’s just call it what it is you, their team handing out vsphere like That’s it. You’re just an infrastructure team. So then I think the reaction to that as people try and do higher level abstractions that are of greater value. And then you end up people, I would say, creating things like big, monolithic, terraform code bases where it’s like who owns the code base, who’s going to pull request in like we’re going to share the code base between teams. Isn’t that a good idea? Nothing bad could happen with that. You see people like, Oh, it’s fine. You write us a jira ticket and then it’s fine. We’re really quick with tickets and immediately six week ticket queue happens. So we see we see terraform. I know what we’ll do to make life easier for everyone. We’ll give you Kates access. We’ll give you some helm charts we found on the Internet, and you kind of use them when you want. But then when you deploy that, you need to maintain it. It’s like this anti pattern after anti pattern of how people do things. And I think I mean again, Team Toppo. I had this interaction models around, kind of like, you know, collaboration. But the key one a platform team needs to move towards is as a service where you are going into your organisation. You are learning via collaboration what the right services are so you don’t start with a chart and a big plan. I’ve just thought of all the right services. You need to go and collaborate with the application teams learn what causes them pain, what the problems are in their lives and what services can be delivered and then build out those services with them in collaboration and then offer those things as a service within your organisation by as a service I mean on demand. I think right now platform teams are stuck between either You give people things that are on demand, like public cloud and like the API. Or you give people that things that are bespoken relevant in your organisation, like the helm charts you just customised like your terraform repo like you know, you find a ticket and I’ll go and do a bunch of like SSH commands and run books. So it’s like either on demand or bespoke. What organisations need to move towards building a good platform is about offering on demand bespoke services at a high level for their organisation, and I’m sure someone’s making a framework somewhere to help with that. I can’t quite remember what it called it tics something like that and that’s it’s like key point. So, you know, we’re kind of again. We’re only a small start up. We’ve been founded based upon what we’ve learned on these journeys with people, and we just don’t see anything that’s out there that is about helping people create bespoke but on demand services in that organisation. And I think that’s really what like the thing that drives me is why I wake up in the morning is try and help companies build out that really like high level, productive API of services in or that you know aren’t a jira ticket aren’t a shared terra form Rebo aren’t a bunch of helm charts. Here’s the keys to AD BS and off you go like those things I think are all the wrong abstraction. And one way of thinking about it used to be high level, bespoke and proper on demand. API. Yeah,
[00:34:35] Jon: it’s really good. Do you think then? Because that sounds like I kind of understand exactly. Now what critics is to be fair now kind of cemented into me. Now you’ve kind of contextualised it the way that you have and does make a huge amount of sense to me. The flip side, I guess, outside of like, do you think the reason those behaviours or the ways of working are existing, like the anti patterns that you’ve kind of labelled? Do you think that is because there isn’t the right things in the industry to solve those problems. Or do you think that the industry itself is kind of slightly echo chambered around? You know what? Because I guess, like any, like any industry in any market, there’s a huge amount of traction with certain tools, like the things you labelled, you know around like he and you labelled like terraform and you know Q and A s. And so there’s a bunch of technology that people just hear and they’ll hear it all the time. And therefore you’ll assume, and there could be these could be technologies even in, you know, people talking around like Q and C N, C F or platform con and all the different flavours of all different things. So you naturally might assimulate that that is platform engineering because like, yeah, I’m doing like my peers use these tools and they’re doing platform engineering, and I’m using those tools. So I’m doing platform engineering. We’re all building platforms and, yeah, that’s it. That’s what platform engineering is. And I guess it’s a harder thing because you’re a bit probably similar to in Thought. To me, you’re contextualising business value around it beyond the technology kind of influence, right, because the technology is there but their tools more than platforms. And then then you’re coming at it from a business perspective and being like, well, something needs to coerce things into something for the users so they can actually accelerate what they’re trying to do. It’s kind of meaningful to them. But industry isn’t necessarily that market isn’t necessarily designed for that thinking at the moment. Hugely, I would say, maybe he’s going to get there. I don’t know if you agree with me over time, and that’s kind of, you know, the platform engineering emergency and what that’s all about. But I don’t know if it does or doesn’t really help convey that message very well,
[00:36:32] Colin: thank you. It’s really interesting. I think it’s tough to reflect on this and try and work out. If what we’re doing is is useful, why hasn’t it been done before in quite the way? I mean, we can only each talk about our own journeys and our own experiences and then share those journeys with other people and share those experiences with other people and see how they kind of land because you mentioned how like what I was talking about kind of landed, Where were you and made sense? I do want to say that of the tools we enumerated. I like all of those tools. By the way. It’s more about like what we define as being a good platform. So I enjoy those tools. It’s definitely a place for those tools. They’re all better than what came before. Just to be clear. My personal journey I mean, way back when I did everything by hand and then I built sort of 2004. I bought out Volkswagen’s infrastructure using C F engine. So C f engine version one that was my first kind of infrastructure. As code set of things. They build out all of inks and stuff, and then I kind of followed the journey. So I did all of eBay Europe using puppet. And that was, like again a learning journey and evolution much, much easier to use than C F engine C F engine engine. Early days was like almost like a theory rather than a practise. And then there are things like cineworld cinemas using chef. So I really like Chef again as an evolution after puppet to kind of go on this journey together, and that was kind of taking things from the more kind of infrastructure as code approach. Then cloud foundry kind of came out and really generalised a lot of those things. It gave you the ability to to take my code as long as my code obeys kind of the kind of 12 factor manifesto obeys a certain set of rules. I can just push my code into cloud foundry and it just runs. You know, Cloud Foundry borrowed a lot from Google a huge amount underlying technology was like I mean, they just they just stole the ideas from the board. It was built by a team who are ex Google and it works super super well for that code so long as your code obeyed its rules and the challenge we then found was that you take that you have that opinion, take all of that. You build the best possible platform in cloud foundry and you take it out to big organisations and each big organisation wants to do everything slightly different. They all have a slightly different set of regulatory concerns and compliance and governance and way their teams work and opinions about where data sits and how it all that stuff is slightly different. So, yeah, everyone wants to do 80% the same and 20% different or less. But the 20% they want to do differently is in a different place in the stack for each of them. So you can’t ever have one off the shelf thing that meets everyone’s needs. So this is my problem with, like, you know, giving people cloud accounts. If every business use the same set of stuff in the same way, AD BS will be able to give you like the one true platform that works. But they can’t. They give you this massive wealth of services, many of which are just infrastructure level things because every business wants to do something a little bit different with them. So I firmly believe the reason why platform engineering and platform as a product more specifically are going to exist for a very long time is that your infrastructure is commodity. Your platform is a product, and then what? You offer your value that needs to be differentiated and novel so you can make profit on it from your organisation. There’s like this stack, so your apps need to be novel. Your platform needs to be a product within your organisation, and your infrastructure needs to be commodity. That’s why you can take your infrastructure off the shelf. You need a team to build your platform product. And then that is what will accelerate your business so that your novel differentiated business value really drives value. Like as in people pay lots of money for it. So I think that stack exists almost independent of the vertical that you’re in. And that’s why I think people have really failed. I mean, you know, I see out Pivotal, try to build the one platform like Pital Cloud foundry that was going to take over the world and be everybody’s platform. Why didn’t that succeed? Why am I still not there now? Why am I not one of the richest people on you know in the world? Because you can’t build one platform that meets everyone’s needs? The only person who can build your platform is you. So that’s why we’re now building out critics is because we’re trying to make it easy for you to build your platform rather than a vendor building your platform for you. Does that make sense? Yeah,
[00:40:08] Jon: it does make a lot of sense, I think 80 20 rule because I kind of listening in. And then I just kind of reflecting back on things you were saying and like Google, like Borg and the Standardisation. But the value it bought Google was probably astronomical. And so the problem that the organisation are facing as much as I guess if I was being pragmatic or objective around the problem is that standardisation will bring you more value even than the product platform as a product. Because why are they so different? Really like, what’s behaviour going on? Where people are making such different decisions like technology is diverse, you know? But actually, when you do really look at what people are doing, the logic, the business logic, you can standardise on that business logic. The actual outcome that what they built gave to the customer in the end is not so differential at each time, where every business of every single product of everything is so unique.
[00:41:00] Colin: We might have to agree to disagree on that one, because that was my lift experience of Pivotal. I think the nature of that in the scale of it is maybe proportional to the size of the company we targeted, like the largest companies in the world, like top 1000 largest companies. And each one wants to do things kind of like do
[00:41:15] Jon: things differently. But so you had a magic one, though that wasn’t about, I mean, just taking away platforms and products and all that out of the equation, and you need to look at it more on the problem itself. You’re like, you know, does homogeny solve the problem, I guess would be great. Like if you were to make some concrete decisions like business around, how things were engineered and you could standardise on it, would that reduce the need for a platform at all? But it’s like a hypothesis, almost nothing to
[00:41:38] Colin: do. It’s really interesting to kind of think about that and think, Why can’t we build a platform that everyone can use because you’re going lowest common denominator at that point in time? Because everyone has to be able to use it, And that’s why your lowest common denominator is the infrastructure. When you try and take that info level to the next step. It’s almost like the differentiation that sorry I took a step back here. All businesses would make no profit if everything they offered was homogeneous commodity. There’s almost that definition of like to economics here, like they’d make no profit if everything was just being sold at the kind of like marginal cost equals marginal price of economics. So you’d have, like, just have undifferentiated commodity for absolutely everything. So the way businesses make money is by differentiation and doing something a little bit unique. Now I think at the platform layer that differentiation starts to come in. I appreciate what you’re saying in terms of like, but the technologies might be the same, But everyone’s technologies might be a little bit different, or their business process, more to the point, might be a little bit different. Or their governance, their compliance, the way they set it might be a little bit different, so people start to compete in these aspects where they do things a little bit differently and everything makes it. That’s my point, like they’re mostly the same. If you blow your eyes. It looks exactly the same. And when you go on the ground and you do it with these organisations. It ain’t the same and you end up with everyone trying to decom your software rec, compile it in a different way, compose it in a different way, like everybody did everything just a little bit differently. So those platforms are bespoke, are unique. And I say, I appreciate you may have lived different experiences than I have, but like my experience was,
[00:42:57] Jon: I just find it intriguing because I totally agree, because my experience are exactly the same. So it’s like I guess what I’m doing is like almost picking at the problem, like hypothesising on, like taking away. I guess this the where we’ve come from the industry because I think we fully align on like the need for the platform, engineering and products. And actually things are unique and things are different and businesses are organised that way. I was just kind of like parking that and then looking at the problem because I just because it’s intriguing because it’s quite behavioural and people based and it makes you think like, well, what happens if a I is writing the code? Is it that different what happens when all this stuff happens, like do you have unique like edge cases? Is the human element the bit that’s really causing the divergence, or is it really, truly is? Actually, the business is requiring divergence, and I guess that’s really the tail end of it is like because it’s an interesting path. We’re on anyway where things are expanding in different ways, obviously from a I, and you know this code and everything else. And so copilot and things.
[00:43:51] Colin: You’re asking me a really good question there. And I think this sorry if I kind of immediately clamped down on you. No, it’s
[00:43:55] Jon: good. I just had to explain where I was coming from because I think I was kind of often attended. I knew what I meant in my head, but it probably was. I wasn’t communicating very well.
[00:44:02] Colin: But obviously, if I can reflect this question in a slightly different way, that really landed very well with me was I do think so many businesses invent things that aren’t actually different about them at all that they shouldn’t do anyway. They’re a complete waste of time, So in terms of like should they be doing these differentiated value of the 20% is different, maybe 2% is real difference and, like 18% is just them wasting their own time but because they’ve misinterpreted some kind of like governance or regulation thing. So I see that so, so common. And then the next part on top of that is how much of a performance gain would get if they didn’t deviate in that way. So it’s almost like they may deviate in these ways that are like, you know, and the infrastructure is 0% on the platform, 30% and on the app 70%. But should it actually be like 0% of a platform, should you just use like off the shelf or whatever? But I’ve seen so many organisations where we would deliver platforms and then people would have a massive incentive to use the platform because they could offload all these kind of like operational concerns onto the platform and yet couldn’t for all these reasons, so it sometimes like you, invert it Where, rather than saying to people are you know, I’m on the platform team, therefore I want to build a platform. I don’t want something off the shelf. If you invert it, application teams have the platform there, so use it. If you use it, it’s free. You don’t have to worry about any of the apps, the apps staying alive on that. It’s taken care of by the platform and that’s go offline. Once they pass their test suite, we’ll keep them running for you. Just don’t you worry about it. It’s so good for you and then you get some adoption but not total adoption and teach people why not? And they say there’s these things we just can’t get rid of them. So I think there was a lot of, like, not invented here going on. There’s a lot of like I want to build it myself going on. A lot of CV based development going on all those things are absolutely true. A lot of standing of rules and regulations, a lot of cargo coating or the person who came in before me used to do it this way. Therefore, I do it that way, all that stuff. I absolutely agree, and I think that’s what you kind of your experience. Maybe you’ve been met. Those kind of people doing those kind of things where they have invented, like traps for themselves to fall into based upon their experiences.
[00:45:53] Jon: I guess I’ve just seen where the problems moving to, because I think I’m totally in alignment, and I agree. Everything you’ve said is absolutely spot exactly same experiences, too. And I’m also not saying that when it doesn’t fit. If you can’t modernise it or change it, then it therefore just basically just should stay there and you can’t use the platform. Obviously, that’s not an answer, either. But it’s almost like the problems moving around. You know what I mean? It’s like there’s a root causes. The thing, the thing, what you just said is like, Was it really just 2% rather than like the 20%? And we can’t solve that with a platform at all, right? And that’s behavioural and it’s organisational and it’s very difficult to solve, and these things happen for a reason. Then there’s decisions made. No one can rewind time and get into a time capsule and be like, Well, we need a time capsule to solve this so we could go back in time. Now we’ve learned that decision was wrong to like go and fix it. It’s just intriguing to see. I guess the net of it always like because of all of that which is also in, you know, justified. It’s not like it’s not justified. The problem then moves is then caused to move. And that’s where you’re saying, Well, actually, there’s a value then in being flexible because of those situations, and that’s where we can meet them. But I guess it’s just intriguing more to me to kind of like, play it all out. So you kind of see how it all gets to a place in the end. It all, like, circumvents into some place, which is then going to be the platform. And now the platform, I guess, has the cost to it, which is probably value. Still, I’m not saying it’s not valuable, but
[00:47:11] Colin: it’s just I guess it’s almost like saying the info. Sometimes we do see things in the infla where it’s differentiated and it’s necessary. A good example would be like low latency financial trading. Like I’ve seen people where like down to like the nanosecond they need to like, because the faster you get that trade in and out like that will determine the success of your business. Also, like people doing content streaming and be like, Hey, come and use the platform. It’s gonna be great for your content streaming and then we need 100 gig in an hour. How’s that gonna work? Not quite like that on this platform. So there are things that even an infrastructure level are differentiated depending upon the vertical and the business you’re talking about. And that’s kind of why I’m saying, like I think a lot of you take some of the educations out and say, OK, 99% will work. It’s like standard infrastructure and 1% is customised. And then you get to the platform and it’s like maybe a certain percentage, depending upon the customers we’re talking to, maybe like, 30 or 40% is like standard and could just run on like Karo, and then the rest of it needs some more, has some custom elements to it, and then you you kind of as you make your way. I’m I’m describing a ward map here, by the way, as you make your way kind of close to the customer, so things get more differentiated. So we think in the vast majority of organisations like a platform team is necessary. If you’re an organisation that’s at scale. By that I mean, like, five teams or more and don’t need a platform team because you haven’t learned like where your differentiating parts are. I’m curious to know how that works. Curious to look into that and be like, I think there may be some efficiencies you could gain by having a platform team, because once you get to five teams, you probably do need to start thinking, Are there common elements on those teams? And therefore we could build a platform to support them and just that platform feature things I couldn’t just get off the shelf somewhere else and almost everywhere I’ve looked. So we’re working with companies that are like 30 people and they see value in a platform because they need common things delivered as a service that they can’t get off the shelf even at 30 people. So that’s the kind of I think 30 people upwards. That kind of level is where you start seeing value from your platform and the more teams you have consumed in the platform, it goes without saying the more teams you have, the more you’re like of a force multiplier. It is, the more value you get out of it. Yeah,
[00:48:58] Jon: perfect. I know it kind of ruined slow time. I’ve kind of like it’s been quite very, very interesting you on because I think I love these kind of conversations anyway and playing a bit of just listening to other people because I align so like, tightly to all the principles, like everything you’ve kind of said. What you said makes me almost like, deliberately challenge my own view. If you see what I mean, because you’re giving me a view. So it’s like, Is this right? You know, we a good thing. So I was just kind of playing Devil’s advocate on it because I think it’s totally necessary, but just more for my own like objectivity. I suppose it helps.
[00:49:26] Colin: It’s always good to challenge our assumptions because I’m sure five years, two years time, whatever I’ll reflect on the things I said here and say, Oh, that thing was wrong completely. I went and invalidate it. So obviously you know, our views of the world are formed on a series of assumptions and then we go out before hypotheses we go and invalidate them. So I’m sure there’ll be some things that I said today that I’ll reflect on and be like What was I talking about?
[00:49:43] Jon: Millions of things. I do that story of my life, I think. But if people want to find you, how would they find you? Contact you if they like. Want to reach out to you And thank
[00:49:52] Colin: you for that chance. So s dot i o be one way, or you can go to dot i o t shot off again and you can look at the crass framework and also hat of monkeys on Twitter. Not the people are using Twitter that much anymore, and we should be using various different things, but yeah, Hat of monkeys on Twitter and on LinkedIn as well. So on LinkedIn CEO in. So please do contact me. I’m interested to hear if anything that I’ve said is you find it controversial. You don’t agree with it. You do agree with it. Like I’d love to hear some feedback from the audience about whether or not you think your organisation doesn’t need a platform. Even though you’ve got 10,000 people. That would be great to hear, to hear about those use cases. So for being challenged. And all of it perfect.
[00:50:27] Jon: All right. Thanks so much as well for being a pleasure. Thanks for having me. All right. Thank you.
Part of the Appvia family.