1
00:00:00,000 --> 00:00:04,920
You're in for a great discussion about, I don't know, platform engineering, platform as a product,

2
00:00:05,220 --> 00:00:10,360
thinking about how you manage the team and even recruit the team of people that run the platform

3
00:00:10,360 --> 00:00:15,340
you have. But I wanted to remind you that come December 6th to 8th, we have SpringOne coming up

4
00:00:15,340 --> 00:00:19,460
in 2022, in case you're listening to this in the future. It's going to be a great conference where

5
00:00:19,460 --> 00:00:23,860
we talk about software development, especially in the Java and the net world, people using Spring,

6
00:00:24,120 --> 00:00:28,360
setting up golden paths to production, all the kind of stuff that platform engineer people are

7
00:00:28,360 --> 00:00:32,940
concerned about and interested in. A little bit of Kubernetes stuff here and there, DevOps-y things,

8
00:00:33,080 --> 00:00:36,760
basically all the stuff you would expect from the cloud native world. And the stuff that I look

9
00:00:36,760 --> 00:00:41,240
forward to most, kind of the type of discussion Darren and I have here, is talking with the people

10
00:00:41,240 --> 00:00:45,460
and organizations about how they're managing, running that stuff, changing the organization,

11
00:00:45,620 --> 00:00:49,900
the skills and practices, the culture, if you will. But we've got all the sessions posted in the

12
00:00:49,900 --> 00:00:54,840
workshops. If you go to spring1.io, you can browse Zoom and check them out. And you should register.

13
00:00:54,840 --> 00:01:01,420
And I've got a code you can use to get $200 off. And that's Coté 200. That's C-O-T-E 200. So if

14
00:01:01,420 --> 00:01:05,240
you're interested in this discussion you're about to hear, these kinds of topics, definitely go to

15
00:01:05,240 --> 00:01:10,120
spring1.io and check out the stuff we have. It's probably a good conference for you to come to.

16
00:01:10,220 --> 00:01:13,300
And you'll be able to talk with the actual practitioners, do it, not just see the talk

17
00:01:13,300 --> 00:01:18,520
that they give. Ask questions, talk with your peers. So check that out. Use the code Coté 200

18
00:01:18,520 --> 00:01:26,220
at spring1.io to check it out and save $200. And with that, let's go see what Darren's take on

19
00:01:26,220 --> 00:01:30,820
platform engineering is, the experience that he's had in large organizations putting it in place,

20
00:01:30,820 --> 00:01:35,860
and some advice for kind of the long-term viability and scaling up. And really one of the parts I like

21
00:01:35,860 --> 00:01:40,980
about the conversation a lot is we kind of think about what it means to product manage a platform

22
00:01:40,980 --> 00:01:45,440
platform for, for operations people, which I think is a big shift in what's going on there.

23
00:01:45,940 --> 00:01:50,280
Enjoy. I'm going to continue in my series of, I was, maybe, maybe you have a good way of putting

24
00:01:50,280 --> 00:01:55,140
it. I'm going to, I'm going to christen this a series called what is platform engineering

25
00:01:55,140 --> 00:02:01,640
or whatever we used to call it. I don't, I don't know. I don't know if that's a good one. It seems a

26
00:02:01,640 --> 00:02:08,540
little too forceful, but to that end, you've worked in this area for many years and helped run and

27
00:02:08,540 --> 00:02:11,000
build and be on these teams. Why don't you introduce yourself?

28
00:02:11,000 --> 00:02:18,400
Yeah. Thanks for having me. My name's Darren Rice. I'm based near, near London in Essex in England.

29
00:02:19,400 --> 00:02:26,140
I joined VMware at the start of this year as part of a team called the Tanzu Value Advisory Team.

30
00:02:26,680 --> 00:02:30,100
It's a team that had been sort of quite successful in the U.S. for about three or four years,

31
00:02:30,680 --> 00:02:35,620
back even when, you know, when we were pivotal. But we decided to expand the function into Maya.

32
00:02:35,620 --> 00:02:41,020
I was the first one to join and now we have three members. I know you know them, Brian Ross and Mark

33
00:02:41,020 --> 00:02:46,840
Zotner. So we're now at full strength. And basically our team is a sort of executive advisory

34
00:02:46,840 --> 00:02:50,820
team. You know, we've come from industry, we've sat in these people's shoes and we can sort of

35
00:02:50,820 --> 00:02:56,480
talk through their problems at a business level and outcome level. You know, having seen what to do,

36
00:02:56,540 --> 00:03:00,280
what not to do, you know, and we can advise them beyond just sort of, you know, the products that we

37
00:03:00,280 --> 00:03:04,560
offer and the services we offer, but also around, you know, how do you drive some of this cultural

38
00:03:04,560 --> 00:03:08,340
change? How do you, how do you actually really do this in practice?

39
00:03:08,940 --> 00:03:09,100
Totally.

40
00:03:09,800 --> 00:03:16,680
Before, before VMware, I was in, you know, finance for 25 years, 20 years of that was in banks.

41
00:03:17,320 --> 00:03:24,440
And my most recent role, I sort of ran the global middleware team for, for UBS.

42
00:03:25,180 --> 00:03:29,280
Middleware is a bit of an old fashioned term now, I know, but I haven't found a better word

43
00:03:29,280 --> 00:03:30,400
for it yet. I mean, it's the.

44
00:03:30,460 --> 00:03:34,380
Oh, exactly. That's the, I mean, that's, that's the problem I always have is like, yeah, I

45
00:03:34,380 --> 00:03:37,100
know this is an old term, but we don't have a new one yet.

46
00:03:37,840 --> 00:03:42,560
Yeah, exactly. So I could make up lots of fancy names, but it's the bit that sits in the middle

47
00:03:42,560 --> 00:03:47,400
of the app and, and the operating system, right? So, so I ran that. So, but, and as a part

48
00:03:47,400 --> 00:03:53,780
of that, my team brought Tanzu into the, into the bank and we ran it at scale. So, you

49
00:03:53,780 --> 00:03:58,420
know, we, when we obviously tried to introduce a lot of these platforms of product concepts,

50
00:03:58,640 --> 00:04:03,140
you know, having had Tanzu labs in and to talk to us about all of that.

51
00:04:03,560 --> 00:04:08,300
So, so, so let's, let's, well, well, first of all, yeah. I mean, Mark just told me this

52
00:04:08,300 --> 00:04:12,180
morning that he, he, he moved over to your team, which is exciting. He'll, he'll be great

53
00:04:12,180 --> 00:04:18,380
there. He, he, of course, he's been in this, I don't know, channel of podcast video stuff

54
00:04:18,380 --> 00:04:22,720
at some point talking about our legacy trap stuff and the work we did there, which is,

55
00:04:22,820 --> 00:04:27,180
which is always good stuff. And then you have, in addition to English, you've got German and

56
00:04:27,180 --> 00:04:29,840
French covered. You can do some, some TV and other things.

57
00:04:29,840 --> 00:04:34,280
Well, he not only increases the team by 50%, he increases the languages by 300%.

58
00:04:34,280 --> 00:04:44,420
Exactly. There you go. So like, like, let's start with like, I mean, I don't know what,

59
00:04:44,420 --> 00:04:49,760
without getting too like hung up on like, you know, the last, like, like six months or so of

60
00:04:49,760 --> 00:04:53,920
the phrase platform engineering. And, you know, as you were calling it platform as a product or

61
00:04:53,920 --> 00:04:59,320
running the platform or just running that like centralized thing that, that your developers

62
00:04:59,320 --> 00:05:03,520
use and that they run their apps on inside an organization, like, like, how do you think

63
00:05:03,520 --> 00:05:10,360
about what that is? Let's just call it the platform team. Like, like what, what is, what's

64
00:05:10,360 --> 00:05:14,860
going on there? What, what, what's the roles and responsibilities it has in the organization?

65
00:05:16,240 --> 00:05:22,480
Yeah, I think, so I was at, you know, banks for a long time and I saw things evolve from,

66
00:05:22,480 --> 00:05:28,660
um, let's say traditionally how people did it is people tended to order, you know, infrastructure

67
00:05:28,660 --> 00:05:33,400
and middleware in a kind of, you know, you would put something on a shelf, you'd say,

68
00:05:33,400 --> 00:05:38,320
okay, this is a web server package with some scripts around it, off you go and install it. And each

69
00:05:38,320 --> 00:05:43,600
person would go and individually order their server and their operating system on their database and

70
00:05:43,600 --> 00:05:49,360
so on. Right. You know, that's how, and our job in, you know, go back 15 years was to create these

71
00:05:49,360 --> 00:05:57,540
kind of generic sorts of self installable sort of pieces that really was impossible to put any

72
00:05:57,540 --> 00:06:02,800
standards around. It was not centrally hosted. It was, so you were more sort of providing a product

73
00:06:02,800 --> 00:06:08,540
in a very kind of put it on the shelf and away you go. Good luck. I think the, the, the change for when

74
00:06:08,540 --> 00:06:13,500
you start talking about platforms and the concepts existed for a long time and, and people built things

75
00:06:13,500 --> 00:06:19,020
like web farms or, you know, shared database clusters or whatever it is, you know, I think we just sort of

76
00:06:19,020 --> 00:06:24,940
added new terms to it to call it, you know, platforms as a product or whatever. It just means that the sort of,

77
00:06:24,940 --> 00:06:32,620
it's that multi tenant, you know, someone's going to centrally own the responsibility for certain things.

78
00:06:32,620 --> 00:06:36,380
So the developer doesn't have to care about it. Right. The developer doesn't have to order all the pieces.

79
00:06:36,940 --> 00:06:41,420
Right. And so you worry about things like getting the base infrastructure, the capacity around it,

80
00:06:41,420 --> 00:06:47,500
right. How the platform is generally running, how someone consumes it and so on. Right. That for me is what

81
00:06:47,500 --> 00:06:53,900
it's all about. Um, a bit like, you know, it's having a landlord rather than you owning your own

82
00:06:53,900 --> 00:06:58,540
complete, how I use sort of house analogies quite a lot, by the way. So it may not be the first time

83
00:06:59,180 --> 00:07:04,700
we go into a house analogy, but, um, but that's the important thing for me is that suddenly you've got

84
00:07:04,700 --> 00:07:11,340
experts who can concentrate on what they're good at, which is hosting, right. Which is running,

85
00:07:11,340 --> 00:07:16,540
whether it's Java or web apps or databases or whatever it is, providing that for you

86
00:07:17,500 --> 00:07:21,580
and it started a long time ago, but then we got better at it. We, we had to do it originally

87
00:07:21,580 --> 00:07:27,020
using our own homegrown tools and just sort of sticking this stuff all together, sticking load

88
00:07:27,020 --> 00:07:33,100
balances over it and stuff like that. And then of course we brought products along like, like Tanzu.

89
00:07:33,660 --> 00:07:38,540
Um, and of course that cloud does a lot of that for you as well. Right. But the concept

90
00:07:38,540 --> 00:07:43,580
I think has existed for quite a long time. And, and I think, I mean, I think the,

91
00:07:43,580 --> 00:07:51,180
the, so one evolution of the idea of the, uh, let's call it the, the, the centralized services team,

92
00:07:51,180 --> 00:07:55,580
as, as, as we were joking, you know, like, I think, I think it's, it's a very, in a good way,

93
00:07:55,580 --> 00:08:02,780
a very mature, well-known thing that you, I mean, to go back further into history, the point of middleware

94
00:08:02,780 --> 00:08:11,500
is like, these are reusable common services that many different, uh, developers inside an organization

95
00:08:11,500 --> 00:08:17,500
use that generally you don't want to code yourself like a database most famously, right? Like, or,

96
00:08:17,500 --> 00:08:23,180
you know, a message bus, or it's just sort of like, I don't know, the plumbing that would be ridiculous

97
00:08:23,180 --> 00:08:28,860
for you to write on your own. And so generally whether, I mean, I guess there's three, there's

98
00:08:28,860 --> 00:08:35,020
three things like one, you might actually write it on your own, but then it's used by everyone,

99
00:08:35,020 --> 00:08:39,900
right? Like it's, it's, so it's, it's not like every team doesn't rewrite their own stuff, or

100
00:08:39,900 --> 00:08:43,980
you might use like an open source thing and you kind of like manage that and run it on their own,

101
00:08:43,980 --> 00:08:50,300
or you like, similar to that, you buy, you buy it from a vendor. And, you know, I think, I think,

102
00:08:50,300 --> 00:08:56,060
you know, most, well, at least I, you know, I stopped coding in 2005. So, so all my knowledge

103
00:08:56,060 --> 00:09:03,020
is based on J2EE, right? And like, you know, that was a huge stack of middleware that basically aspired

104
00:09:03,020 --> 00:09:08,620
to just do everything. Or as you were saying, web service, uh, farms or clusters, whatever. So anyways,

105
00:09:08,620 --> 00:09:15,820
it seems like, like about, I don't know, around, at least this is when I heard about things about like

106
00:09:15,820 --> 00:09:21,420
2015 or, or whatever in, in the, the platform as a service days. And this is when I joined Pivotal.

107
00:09:21,420 --> 00:09:27,260
Like we would talk a lot about as, as a phrase you used, uh, a little while ago, like platform as a

108
00:09:27,260 --> 00:09:33,500
product. And, and I think it was that as a product that was kind of like the evolution of the centralized

109
00:09:33,500 --> 00:09:41,020
middleware, which is what if we like product manage what we're providing here, which, which is

110
00:09:42,060 --> 00:09:46,700
a shift from, and I mean, tell me if I'm getting this wrong, like I'm going over it to kind of

111
00:09:46,700 --> 00:09:52,780
validate my fanciful notions, but it seems like with the traditional way of doing middleware,

112
00:09:52,780 --> 00:10:00,220
your focus is more on we're delivering some middleware or services that have to meet a set of

113
00:10:00,220 --> 00:10:06,540
requirements. Uh, that they, they need these, these features and they need like this uptime and they

114
00:10:06,540 --> 00:10:10,940
need this blah, blah, blah. But their, their job is to meet the needs that we have specified.

115
00:10:11,660 --> 00:10:15,820
Whereas the slight, slightly, but, but constant, very consequently, more important thing of the,

116
00:10:15,820 --> 00:10:21,740
as a product part is let's go find out what the developers need. And like, let's continuously

117
00:10:21,740 --> 00:10:29,660
kind of like gather the requirements from developers by working with them and evolve what we're doing by

118
00:10:29,660 --> 00:10:35,100
figuring out what makes, let's treat them as the primary customer in, instead of the enterprise

119
00:10:35,100 --> 00:10:39,340
architecture as the primary customer, I, I guess, I don't know. I mean, does that seem like,

120
00:10:40,300 --> 00:10:42,060
is that a fair characterization?

121
00:10:42,060 --> 00:10:49,020
That is absolutely what happened. Um, because I think traditionally these platforms were just built

122
00:10:49,020 --> 00:10:53,740
by engineers and it was the same people that had engineered things in a traditional way that we're

123
00:10:53,740 --> 00:10:58,620
also providing, you know, the platforms for people to run on. I think what we did across the board,

124
00:10:58,620 --> 00:11:03,020
and this is not just true of middleware, we did it across the, you know, I wasn't the, uh, the genius

125
00:11:03,020 --> 00:11:08,140
inventor of the, this change of approach, right? But it was, but I was one of the implements of it.

126
00:11:08,140 --> 00:11:13,180
Um, it was, it was that change in mindset. You know, we changed our titles overnight from engineering

127
00:11:13,180 --> 00:11:17,660
leads to service and product leads, right? And that was a significant sort of mind shift. And we also

128
00:11:17,660 --> 00:11:23,820
started putting people into the positions, um, that maybe the traditional engineers didn't feel

129
00:11:23,820 --> 00:11:28,300
comfortable doing, but it was that interface to the customer, which would typically the application

130
00:11:28,300 --> 00:11:33,980
owner or developers, right? Um, I think in large organizations, when we talk about developers,

131
00:11:33,980 --> 00:11:37,100
actually, we talk about lots of different types of people, because there's people that are bashing

132
00:11:37,100 --> 00:11:41,100
out code, there's actually people that can actually write a line of code, but they're actually owning

133
00:11:41,100 --> 00:11:47,020
the applications and responsible for how the application gets, you know, its roadmap and how

134
00:11:47,020 --> 00:11:51,180
it gets deployed and what infrastructure it uses. But anyway, I'm sort of digressing there on what is

135
00:11:51,180 --> 00:11:58,140
an app owner, right? Sure. But certainly in terms of the roles of those service and product managers

136
00:11:58,140 --> 00:12:04,060
were much more around, you know, have you published your catalog of what you're actually offering

137
00:12:04,060 --> 00:12:10,220
and all the different t-shirt sizes and how, how do you consume it, right? You know, what does it cost

138
00:12:10,220 --> 00:12:16,140
for the internal user to use it? Are there other options? Have you got a roadmap from where you are

139
00:12:16,140 --> 00:12:22,060
to where you need to be? Have you got information about what's the top priorities that the you'd like

140
00:12:22,060 --> 00:12:27,500
us to focus on? Is it end of life? Is it compliance? And then how are you running regular review sessions

141
00:12:27,500 --> 00:12:32,940
with your customers to find out what they want? So you can give the information two way. And again,

142
00:12:32,940 --> 00:12:37,660
I'll make sure it's a two way street, because we were often saying to the customers, by the way,

143
00:12:37,660 --> 00:12:41,980
we do want you to still worry about end of life and, and compliance and things like that, which is what

144
00:12:41,980 --> 00:12:46,940
I'll come on to in a minute, right? But it was them telling us, yeah, but we really need X, Y and Z.

145
00:12:47,500 --> 00:12:50,540
Whereas I think you're, I think you're right in the past, it was very much probably

146
00:12:52,060 --> 00:12:57,820
architectural CTO led saying we should go to technology X and our platform should be based on

147
00:12:58,540 --> 00:13:01,260
Tomcat, not web sphere or, you know, yeah, yeah.

148
00:13:01,260 --> 00:13:07,580
Tomcat, not Oracle. Yeah. You know, we, we didn't, we, we changed it because of those kinds of drivers,

149
00:13:07,580 --> 00:13:13,580
not because, oh, we need this particular feature. We need to start introducing different ways of doing

150
00:13:13,580 --> 00:13:14,460
this stuff. Right.

151
00:13:14,460 --> 00:13:19,900
Yeah. Yeah. No, and, and, and I mean, you, you went through a great list there of, uh,

152
00:13:21,260 --> 00:13:27,820
like, like thinking about your, your software or, or whatever the, the, the technology thing you're

153
00:13:27,820 --> 00:13:33,100
creating as a product, right. With roadmaps and like, like I, I, you know, in, in a, in a comical,

154
00:13:33,100 --> 00:13:38,780
but very serious way, so to speak. Right. Like just publishing the catalog of services you have

155
00:13:38,780 --> 00:13:44,540
and making sure people can access it is often overlooked. Right. Like, like, and, you know,

156
00:13:44,540 --> 00:13:52,140
it's just a form of marketing basically. Right. Like I, I remember, uh, I remember hearing,

157
00:13:52,140 --> 00:13:57,100
I forget where this was or who it was, but I remember someone was talking with, uh, uh,

158
00:13:58,220 --> 00:14:02,140
like, you know, the infrastructure people and, and they, they were, they were talking with who,

159
00:14:02,140 --> 00:14:05,340
I think this was one of our, our people who was talking with them and they were saying like,

160
00:14:06,140 --> 00:14:12,940
oh, you know, we, the developers keep asking us to like set up a public cloud access. And so we need

161
00:14:12,940 --> 00:14:17,020
some way to do that. And, and then they kind of went down to the people who are providing the service

162
00:14:17,020 --> 00:14:21,180
and they were like, yeah, we have that. Like you totally have public cloud now. It's not a big deal.

163
00:14:21,180 --> 00:14:25,500
You can just do that. And then, and then, so the person asked them like, well, what,

164
00:14:25,500 --> 00:14:28,380
like, how do you do it? Cause the developers don't know about it. And they're like, oh,

165
00:14:28,380 --> 00:14:32,540
well you file a ticket and then we'll open it up for you. And it was kind of like, well,

166
00:14:32,540 --> 00:14:34,460
that's why they don't know about it. Cause there's not like,

167
00:14:35,100 --> 00:14:40,620
there's not like a catalog of offerings that, or even worse, there is a catalog of offerings,

168
00:14:40,620 --> 00:14:44,860
but there wasn't enough time spent to make sure the developers knew about it. Right. And

169
00:14:45,580 --> 00:14:51,020
I think like, like to kind of embellish or, or like add kind of a, whatever to the list you were

170
00:14:51,020 --> 00:14:56,460
saying, like, I think a couple of years ago, like I kind of, the way I also started thinking

171
00:14:56,460 --> 00:15:00,860
about it is like, well, I've always worked for software vendors and we sell our software as a

172
00:15:00,860 --> 00:15:05,900
product. So I know all the activities you go through to do that. And it's kind of like, well,

173
00:15:05,900 --> 00:15:12,220
you just use those activities for internal it now, which, which I think is a whole lot of different

174
00:15:12,220 --> 00:15:18,940
stuff that you add in, uh, as, as you were listening there. Yeah. Um, I think when you,

175
00:15:18,940 --> 00:15:24,940
the marketing and, um, sort of advertising almost internally of what you do, I think is a very

176
00:15:24,940 --> 00:15:29,020
important thing that often gets missed with traditional engineering teams. I mean, people

177
00:15:29,020 --> 00:15:33,500
will tell you we have, oh, we have documentation. Like exactly. It's not that it's not that you don't

178
00:15:33,500 --> 00:15:38,220
have something written down, but typically, I mean, and I was guilty of this when I was an engineer,

179
00:15:38,220 --> 00:15:44,940
right. Your documentation consisted of a, of a confluence page that started with a Unix command,

180
00:15:44,940 --> 00:15:52,620
right? It's like, well, no, you're, you're starting down here and that, that's still very important

181
00:15:52,620 --> 00:15:58,620
stuff that might be needed by technical people. Once you get into the, you know, how do I actually

182
00:15:58,620 --> 00:16:04,620
install this stuff? But no one really started at that bit before saying, you've already assumed that

183
00:16:04,620 --> 00:16:09,180
I'm, you know, I'm inside the car and I'm asking you, I've already picked the car. I know how to

184
00:16:09,180 --> 00:16:14,380
drive it. Now I've got detailed instructions on how to turn the key and what the buttons do. He's

185
00:16:14,380 --> 00:16:19,740
like, no, stop, step back from that. You know, how do I even know what I want? How do I get to

186
00:16:19,740 --> 00:16:24,860
that confluence page in the first place? How do I know these are the different 12 things that you're

187
00:16:24,860 --> 00:16:29,420
offering? And also more importantly, how do I know that these are the ones that we, you want us to

188
00:16:29,420 --> 00:16:35,180
go, you know, that sort of order of preference, right? You know, decision trees that we then,

189
00:16:35,180 --> 00:16:39,980
as we got more mature, we started putting decision trees, not just here's a service catalog,

190
00:16:41,100 --> 00:16:46,140
do what you like. Cause I think one of the dangers of cloud is there's so many services. As soon as you

191
00:16:46,140 --> 00:16:50,940
open it up to people, there's, there's 27 different ways of doing it that you don't necessarily want to

192
00:16:50,940 --> 00:16:55,980
do it in 27 different ways. You want, you might want to offer two or three, but you also might want

193
00:16:55,980 --> 00:17:02,140
to say some kind of guidance and decision tree on if I'm doing this, then we really, you should take

194
00:17:02,140 --> 00:17:06,940
this one. Right. But if you really need that, then go to this one and then that one, not just here's

195
00:17:06,940 --> 00:17:12,620
the cloud, knock yourself out. Right. Yeah. Yeah. So, I mean, there's, there's a lot of like threads

196
00:17:12,620 --> 00:17:17,500
to pull on there, but one, one that, that I'm curious to hear, you know, having, having done this,

197
00:17:17,500 --> 00:17:26,140
this is your take on is how do you, um, how do you make sure that you keep doing the work to make

198
00:17:26,140 --> 00:17:31,020
things better? Like, like that's, that's kind of a ridiculous question. Right. But, but another,

199
00:17:31,020 --> 00:17:36,540
traditionally, like another thing that I think people encounter with, let's call it the middleware,

200
00:17:37,420 --> 00:17:45,820
like service delivery thing is that especially in enterprise architectures is it's, it's hard to kind

201
00:17:45,820 --> 00:17:51,980
of like gather the feedback. If the decisions you've made are the right ones and then make sure that you

202
00:17:51,980 --> 00:17:57,340
go and fix it. So for example, something as simple as you were saying of like, well, we posted a page

203
00:17:57,340 --> 00:18:05,500
about how to use, uh, whatever, how to package your stuff up to deploy. Like that's a thrilling thing.

204
00:18:05,500 --> 00:18:13,980
And, or, or like, you know, also like how to, how to set up a, a developer and a testing environment.

205
00:18:13,980 --> 00:18:20,140
Right. Like that's a common thing to get started with. And like in, in the ideal state, um, I don't

206
00:18:20,140 --> 00:18:24,460
know what the period is, but like the person who the P the team will maintain that page would go and

207
00:18:24,460 --> 00:18:29,660
say like, well, is this working? Right. Like, is this good? And how would we know if it's good?

208
00:18:29,660 --> 00:18:34,140
And maybe we should change it. Right. And then, I mean, that goes on even further, like, oh,

209
00:18:34,140 --> 00:18:39,500
now we need to, uh, we found a need for developers to have a new type of service or a new type of

210
00:18:39,500 --> 00:18:44,460
configuration. And now we need to go do that. Right. And this is kind of like the product type is

211
00:18:45,180 --> 00:18:49,420
to use a way that some people say is like, you know, a project ends, but a product never ends

212
00:18:49,420 --> 00:18:57,420
until you kill it. Right. But like, and, and so it seems like for us vendors, it's easy because like,

213
00:18:57,420 --> 00:19:02,300
we want more money. So we keep paying attention to building it and we keep doing it. But it seems

214
00:19:02,300 --> 00:19:06,620
like when you're delivering in a project delivery mindset, like it's a new skill to learn that like,

215
00:19:07,100 --> 00:19:11,820
we've got to go back and revisit and revise this stuff, not just sort of be done with it.

216
00:19:12,940 --> 00:19:16,220
Well, I think the first thing you just hit the nail on the head, which is you don't run

217
00:19:16,220 --> 00:19:23,180
everything just as a project. Right. That's why we had to shift to sort of an ongoing concept of

218
00:19:23,180 --> 00:19:28,060
you own this platform or products forever. Someone once said to me, when's this done?

219
00:19:28,700 --> 00:19:34,620
And I said, Oh, never. Well, when the users don't need it anymore is the answer to when this is done

220
00:19:34,620 --> 00:19:40,140
and we'll move on to something else. Right. But until then, then it's never done. I think that's why we were

221
00:19:40,140 --> 00:19:47,100
encouraged and I'll get on to how you do this. But, you know, having those reviews with

222
00:19:47,100 --> 00:19:51,820
with the users, having internal, you know, we used to, we used to have internal chat channels or something

223
00:19:51,820 --> 00:19:56,700
like that, whether it's Slack or Skype or whatever it is, right, to encourage feedback. And we had,

224
00:19:56,700 --> 00:20:01,100
you know, part of that marketing side is, you know, leave feedback on,

225
00:20:01,100 --> 00:20:05,740
whether it's on Confluence or whatever it is, you know, have ways of having feedback.

226
00:20:05,740 --> 00:20:11,340
And yeah, you can't do everything, but then work out ways of, you know, prioritizing it.

227
00:20:11,340 --> 00:20:16,140
Obviously you will have multiple customers. Yeah. Because you'll have different lines of business and

228
00:20:16,140 --> 00:20:20,460
different maybe objectives. But if there are often, if they're saying, if you get multiple

229
00:20:21,100 --> 00:20:25,980
lines of business or customers saying the same thing, then that's a driver to improve. And then

230
00:20:26,700 --> 00:20:32,780
you do that by setting the goals and objectives of the team managing that platform to be that improvement.

231
00:20:32,780 --> 00:20:39,580
You just deliver this project and you'll get your tick in the box at the end of your annual review,

232
00:20:39,580 --> 00:20:45,660
actually, you have to set those goals at the start of the year to say, well, you're a product owner.

233
00:20:46,460 --> 00:20:52,380
Your goal is the following and whether that's, you know, improvements in surveys or whether it's,

234
00:20:52,380 --> 00:20:57,580
you know, you have to make it up what, how you measure it, but it's got to be something that's

235
00:20:57,580 --> 00:21:01,660
measurable in terms of the platform. How many service reviews did you run? How much

236
00:21:02,620 --> 00:21:07,420
positive feedback did you get from those? Are your roadmaps in place for the next three years and

237
00:21:07,420 --> 00:21:14,380
always being kept? And as long as you sort of people get motivated by what their goals are, right?

238
00:21:14,380 --> 00:21:16,620
Yeah, that would be great.

239
00:21:16,620 --> 00:21:18,780
The goal is to finish the project and you're done.

240
00:21:18,780 --> 00:21:25,420
Yeah, that'd be a great thing to contemplate at some point is like, what are management metrics for

241
00:21:25,420 --> 00:21:28,940
platform engineering and platform as a product, right? And centered around like,

242
00:21:30,380 --> 00:21:37,900
I mean, I think you're identifying it is how do you, to make a verb out of it, how do you metric size

243
00:21:39,100 --> 00:21:43,820
product delivery? And, and, and I think, I think the, you know, I mean, as with so many metrics,

244
00:21:43,820 --> 00:21:49,580
right? Like whatever metrics, they're great and bad, who knows, just like sugar, like sugar can be

245
00:21:49,580 --> 00:21:54,620
terrible or it can be wonderful, right? Like just depending on what you do with it. And like,

246
00:21:55,340 --> 00:22:00,380
it seems like there's two types you're going over there. One is like the, I don't know,

247
00:22:00,380 --> 00:22:05,980
the trailing indicators, kind of like the static things of like, we had every quarter,

248
00:22:05,980 --> 00:22:10,780
we had like a customer review meeting and we generated like a backlog from it, which is just

249
00:22:10,780 --> 00:22:16,620
like, these are things that should be happening. It's like the blood test, right? Like, and, and,

250
00:22:16,620 --> 00:22:23,420
but then the other thing is more trying to capture like the flow and improvement of things, uh, as far

251
00:22:23,420 --> 00:22:29,420
as like, like somehow, as you're saying, you want it, you want to capture that, like, yes, we're improving

252
00:22:29,420 --> 00:22:34,300
this. And not only are we improving it, but we're, we're learning what's better. And, uh, you know,

253
00:22:34,300 --> 00:22:38,860
figuring out how you capture that stuff, I'm sure is a bit of an art in some organizations of how you

254
00:22:38,860 --> 00:22:44,380
map it to how that organization functions. But as with most cases, it's probably pretty standard,

255
00:22:44,940 --> 00:22:49,420
the types of things you would, you would start measuring, which, um, I'm always a fan of giving

256
00:22:49,420 --> 00:22:55,740
like management, some new metrics to do stuff. Cause like, there's only so much like work they can do

257
00:22:55,740 --> 00:23:01,420
beyond like meetings, setting the tone and metrics, like everything else is, you know,

258
00:23:01,420 --> 00:23:06,780
it doesn't really scale so well. So they, they need the same tools or similar things.

259
00:23:07,900 --> 00:23:12,860
Yeah, that's, that's, that's right. I mean, you know, we, um,

260
00:23:14,780 --> 00:23:19,260
I think it's also about trying to tie into actually what the end goals are, because you could have

261
00:23:19,260 --> 00:23:24,380
specific goals about what the platform is, right. Yeah. Which will be very specific to the platform.

262
00:23:24,380 --> 00:23:29,420
But ultimately that's why I can't give complete examples now, because it could be, it just depends

263
00:23:29,420 --> 00:23:34,220
on what's the biggest driver from the customer's side. Right. And if the customer is saying,

264
00:23:34,220 --> 00:23:40,140
you know, what our measurement is time to market. And at the moment it's still even with the platform

265
00:23:40,140 --> 00:23:45,180
taking too long. Well, then you can put a measurement around that. If it's, it costs too much,

266
00:23:45,180 --> 00:23:52,860
you can put a measurement around how you can trim those costs. If it's, um, I need more or whatever

267
00:23:52,860 --> 00:23:57,900
it is, you could then put a measurement around that. The platform then becomes the enabler to those

268
00:23:57,900 --> 00:24:03,340
other KPIs or whatever it is that you, that you then address. Have, have you improved end of life?

269
00:24:03,340 --> 00:24:07,180
The platform isn't going to do that on its own. You've got to sort of keep that platform getting

270
00:24:07,180 --> 00:24:13,180
better and better. So it then has the knock on effect that other things in the organization are

271
00:24:13,180 --> 00:24:17,980
getting better. Right. Yeah. But I think it does come from a cultural mindset. You know,

272
00:24:17,980 --> 00:24:24,380
we had people come into the organization and, you know, and say, you are service and product

273
00:24:25,180 --> 00:24:31,580
managers now, right? Your job is to continually improve your, your, your platform. That is your job.

274
00:24:31,580 --> 00:24:38,780
Not did you create a 10 Linux packages last month? Right. Yeah. Yeah. Yeah. You don't,

275
00:24:38,780 --> 00:24:45,660
you don't just do like a, like a, an inventory of the assets and services created, right? Like you,

276
00:24:45,660 --> 00:24:51,100
you want to, you want to shift towards like, uh, how, how are, how are you learning and, and, and

277
00:24:51,100 --> 00:24:56,940
adapting them to, uh, to be useful essentially? Well, so, so next week, uh, speaking of the people,

278
00:24:56,940 --> 00:25:02,620
like we have, uh, we have a talk at, uh, VMware Explorer in Barcelona with, uh, with another,

279
00:25:02,620 --> 00:25:06,380
another set of people who've been doing this for a while, uh, our, our friends from Mercedes,

280
00:25:06,380 --> 00:25:11,820
the ones who run the, um, who I think for like seven years now, uh, have been, have been running

281
00:25:11,820 --> 00:25:16,220
the, uh, the cloud foundry instance, the, I mean, started off being pivotal cloud foundry,

282
00:25:16,220 --> 00:25:21,340
and now it's the Tanzu application service. And they've been using that as the stack, the platform

283
00:25:21,340 --> 00:25:25,740
for doing all this that we've been talking about. Um, and so it's going to be great to hear from them.

284
00:25:25,740 --> 00:25:30,300
Like what I think, you know, what we've been trying to put together in this talk is not so much a

285
00:25:30,300 --> 00:25:35,340
definitional thing, but like, what are the lessons learned, uh, from, from those seven years and what

286
00:25:35,340 --> 00:25:41,740
does it look like after seven years? Right. Which, which I think, I think will be fun stuff. Um, but,

287
00:25:41,740 --> 00:25:45,820
you know, as a little preview of that, the part that you're going to talk about, I think that will be

288
00:25:45,820 --> 00:25:52,940
great is the, um, the, the people in the platform engineering team, right? Because as, as, as you

289
00:25:52,940 --> 00:25:58,140
and I have talked and you've commented on, like, there's, there's a lot of emphasis on the developer

290
00:25:58,140 --> 00:26:07,020
side of stuff, which is cool. And, and I think what I'm always interested in is not, not only how

291
00:26:07,020 --> 00:26:15,100
you sort of build the new role and, and even hire for a platform engineer on the team, but, you know,

292
00:26:15,660 --> 00:26:21,740
usually in a large organization, you have a lot of great skilled, uh, you know, good people already

293
00:26:21,740 --> 00:26:27,420
doing operations stuff and like, I don't know, maybe they can move on to doing this.

294
00:26:28,540 --> 00:26:34,380
Right. And, and so the, so the question becomes like, so how do you, I mean, it's hard to phrase

295
00:26:34,380 --> 00:26:38,220
this without it sounding like negative, but I don't mean it to be, but like, how do you just work with

296
00:26:38,220 --> 00:26:43,500
what you have instead of like coming up with an entirely new team and kind of motivate people

297
00:26:43,500 --> 00:26:47,420
and train them and all of that. So what's, what's been your experience with that? Like working with the

298
00:26:47,420 --> 00:26:52,140
people that you have, I mean, I think there's always a bit of a mix because I mean, I've seen

299
00:26:52,140 --> 00:26:58,060
it done badly both ways and I've seen it done well. Right. I think what I've seen it done badly is

300
00:26:58,060 --> 00:27:04,140
either you don't bring anyone in at all. I'm not necessarily saying that has to be new permanent

301
00:27:04,140 --> 00:27:09,340
members of staff, but if you don't engage some kind of consultant or vendor or someone to work with

302
00:27:09,340 --> 00:27:14,860
you, that's done it before, I think that's a mistake. If you just try and you can, as you say,

303
00:27:14,860 --> 00:27:19,420
you've got some good people, but they need some guidance and steer. Right. Teach them to fish kind

304
00:27:19,420 --> 00:27:23,260
of thing. Right. I've also seen it the other way where projects have, they just brought in a completely

305
00:27:23,260 --> 00:27:28,460
new superstar team that work goes off into a lab and builds it all on their own. And they don't know

306
00:27:28,460 --> 00:27:33,100
anything about the organization and they come out and go, what do you reckon? And then everyone goes,

307
00:27:33,100 --> 00:27:39,180
this just won't work. And it also builds resentment in the old team saying, why do these guys get to

308
00:27:39,180 --> 00:27:44,540
work on the fancy shiny stuff? And we're stuck doing, you know, the traditional stuff. So either

309
00:27:44,540 --> 00:27:50,220
those two things don't work. I think you need a blend. You need some new people, some new ideas,

310
00:27:50,220 --> 00:27:56,460
and at least bringing in from maybe places that have already done it. But I think the vast majority,

311
00:27:56,460 --> 00:28:03,020
as you say, you need to then educate and train and mold your existing team to work with

312
00:28:03,020 --> 00:28:07,260
those new people and make them part of it, make them feel that they are part of it,

313
00:28:07,260 --> 00:28:12,860
not that they're being replaced. Right. So that you don't end up with, you're going to get a few

314
00:28:12,860 --> 00:28:16,780
Luddites, right? You're going to get a few and they're probably the people that won't be working

315
00:28:16,780 --> 00:28:21,340
for your organization for much longer anyway, because they'll say, you know, we've always

316
00:28:22,380 --> 00:28:28,140
done it like this. What's wrong with the physical server? You know, it works perfectly fine,

317
00:28:28,140 --> 00:28:32,460
you know, and they'll put, so those people, you know, but the vast majority of people are willing to

318
00:28:32,460 --> 00:28:36,700
change. It's just, maybe they just need a bit of a steer. Right. I think the most important

319
00:28:36,700 --> 00:28:41,900
thing is get your own team to buy into the concept first, right? Before you start going,

320
00:28:41,900 --> 00:28:48,140
selling it to the app teams and developers. Um, obviously you probably might buy in from your

321
00:28:48,140 --> 00:28:52,220
manager as well, but before you start going out to wider stakeholders, you've got to try and convince

322
00:28:52,220 --> 00:28:57,740
your own team. And there's a few different ways of doing it. There's obviously incentives and there's

323
00:28:57,740 --> 00:29:02,460
also not so threats, but you've got to sort of make people realize that you've got to move on. The

324
00:29:02,460 --> 00:29:07,100
industry moves on the world moves on. Right. So the first thing we started with was

325
00:29:08,140 --> 00:29:15,180
from an ops perspective, um, understanding what is now expected of an ops team. The bar has been raised,

326
00:29:15,180 --> 00:29:21,900
right? Dining out on uptime was something we did in the nineties and maybe early two thousands. Right.

327
00:29:22,540 --> 00:29:28,860
But no one now says, um, Oh, what was great about your iPhone? And he went, Oh, it worked.

328
00:29:30,620 --> 00:29:36,540
Right. No one says that anymore. Right. Oh, it was on 99.9% of the time. You know, well,

329
00:29:37,260 --> 00:29:41,340
it probably wasn't because of the battery, but that's a different story. Right. But, uh, but, uh,

330
00:29:41,340 --> 00:29:47,740
you know what I mean? For, for banks, for retail, for any of these important government, you know,

331
00:29:49,100 --> 00:29:52,060
everyone just expects it. You know, the retention, I think there was a survey. I mean,

332
00:29:52,060 --> 00:29:56,780
you probably know better than I do about what the expectation now of an average user is. Right.

333
00:29:56,780 --> 00:30:03,180
And it's less than 30 seconds. If you're all right, yes. And, or if it is, even if it's slow

334
00:30:03,180 --> 00:30:09,420
or unusable, they'll move to something else. Now banks are a bit stickier than other organizations,

335
00:30:09,420 --> 00:30:15,340
particularly retail banks. We were talking about it last night, actually. Um, so if you've got a,

336
00:30:15,340 --> 00:30:24,140
a retail app and it doesn't deliver your groceries, you'll probably switch, right? If your bank,

337
00:30:24,140 --> 00:30:29,820
if you can't get your balance, it's going to take quite a lot for you to uproot all of your,

338
00:30:29,820 --> 00:30:35,820
you know, account and move. But, but if you look at younger generations, they are doing that.

339
00:30:35,820 --> 00:30:40,460
They are getting the new, you know, the new banks. So, so banks have also can't rest on their laurels.

340
00:30:40,460 --> 00:30:47,420
So it's also around understanding we have to move to survive. And, and within that an operations team

341
00:30:47,420 --> 00:30:53,100
cannot just think the stuff that used to be important, uptime, capacity,

342
00:30:53,100 --> 00:31:00,140
you know, and, and that sort of stuff isn't going to cut it. Cloud gives it, gives you that out of

343
00:31:00,140 --> 00:31:06,140
the box. Right. So, so, and if you don't want to be replaced, you need to move on and be a,

344
00:31:06,140 --> 00:31:10,460
you know, a different sort of, you have a different mindset, get involved in, in, in some of the more

345
00:31:10,460 --> 00:31:16,700
interesting stuff. And so let's face it, producing graphs on uptime and how much capacity is left is

346
00:31:16,700 --> 00:31:23,180
pretty dull as well. Right. Yeah. Whereas, yeah. Right. Whereas, whereas writing automation or,

347
00:31:23,180 --> 00:31:27,500
you know, making the platform better, that's what engineers actually want to do. So that's my next

348
00:31:27,500 --> 00:31:33,900
point is traditionally in an organization that doesn't think in this mindset, you probably got a very,

349
00:31:33,900 --> 00:31:39,260
you mentioned it earlier, a ticketed approach. You've got very ad hoc requests coming your way

350
00:31:39,260 --> 00:31:45,420
because you haven't got a standard service catalog. Your life is probably not too happy because you get

351
00:31:46,060 --> 00:31:51,340
beaten over the head because you're not delivering these bespoke requirements every day. Right. And

352
00:31:51,340 --> 00:31:57,580
in some cases you just, you just can't do what the customer's wanting you or asking you to do. If you

353
00:31:57,580 --> 00:32:04,700
move that mindset to you, you work on automation, you work on constant improvements and you are making

354
00:32:04,700 --> 00:32:11,660
the customer happy. Well, that's a mind shift change, right? Then your day life, your day job will become

355
00:32:12,300 --> 00:32:18,300
happier. Right. But the other, the other example was rather than, I mean, I probably answered the same

356
00:32:18,300 --> 00:32:24,940
question a hundred times because we hadn't got it documented. People didn't know where to go.

357
00:32:24,940 --> 00:32:30,700
So compare that doing that all day long to creating a community, creating a chat channel.

358
00:32:30,700 --> 00:32:36,540
The best thing ever was when a different customer answered the question that another customer put

359
00:32:36,540 --> 00:32:42,060
on that chat channel and our team. Oh, right, right. You got, you got the internal stack overflow effect

360
00:32:42,060 --> 00:32:46,940
where you can, you can do support by users talking with each other. Absolutely. Because I think

361
00:32:48,140 --> 00:32:53,420
you've probably answered that question 500 times. To me, if you've answered that question 500 times and

362
00:32:53,420 --> 00:32:59,340
people used to complain about it all day long to me saying, my day is just swamped with customer queries.

363
00:32:59,340 --> 00:33:02,860
And I'm like, have you written it down? Have you written down the answer? Have you pointed them at

364
00:33:02,860 --> 00:33:07,820
the site each time? Oh, do you just see what I mean? So it's that, it's that change. But, but again,

365
00:33:07,820 --> 00:33:15,100
building that community, getting, getting people to answer for you. Then if you want to, if you want to grow,

366
00:33:15,100 --> 00:33:45,020
you're not just adding headcount to your team, you grow by building champions within the, the app teams. Right. And then, and people resonate with that. They say, you're right. I don't want to be spending time troubleshooting the same problems, answering the same questions, doing ad hoc requests all day. I want to be working on cool new stuff. Right. And that's, that's how you incentivize engineers. I think the other thing is people care about their reputation. Right. I think traditionally infrastructure and ops teams,

367
00:33:45,020 --> 00:34:14,680
are considered expensive and a bottleneck. Right. That's how they're viewed by the business. A necessary evil almost. Right. Which I think is grossly unfair. What people want to do is they are, you know, celebrated for being experts in their field. It's, you know, and you, you know, what people actually like is, Oh, you've really helped me there because you really know your stuff. Yeah. You know how to use this platform. You've helped me steer my application in a way. Right.

368
00:34:14,940 --> 00:34:40,940
And that's the kind of stuff that people actually really like. And when they start doing it and seeing it in anger, right. Their daily life changes for the better. Right. And I've actually seen it happen. Right. Of course, you've still got some of the old stuff that you have to occasionally deal with because these organizations still have a lot of legacy, but you want people to be working in that new way. And I found that most people bought into that. Right.

369
00:34:42,940 --> 00:34:50,380
yeah other area is also about sorry but i'm sort of in my in my flow now and the other area is about

370
00:34:50,380 --> 00:34:56,780
tying it back to some of the things that operations people do care about i mentioned capacity and end

371
00:34:56,780 --> 00:35:04,940
of life and and compliance right um i think unfortunately infrastructure teams and operations

372
00:35:04,940 --> 00:35:11,340
teams have traditionally been sort of beaten up by auditors saying you've got all this end of life

373
00:35:12,220 --> 00:35:17,900
you've got lots of you know stuff that isn't patched you've got non-compliant systems what are you going

374
00:35:17,900 --> 00:35:22,300
to do about it and often the answer is well i can't do anything about it because it's the applications

375
00:35:22,300 --> 00:35:27,980
that need to make the change to either upgrade or you know i can't necessarily depends on where you

376
00:35:27,980 --> 00:35:32,540
are in the stack but when it gets into sort of middle areas i just can't upgrade the java underneath

377
00:35:32,540 --> 00:35:39,420
someone right without them sort of needing to test their application i think if you can say but if we

378
00:35:39,420 --> 00:35:45,260
help the developers they can help us right if you if you deliver a platform that's always evergreen

379
00:35:45,260 --> 00:35:54,060
that's always compliant this that's always you know you you know adhering to our standards when it comes

380
00:35:54,060 --> 00:35:58,060
to an audit your life is not going to be miserable going around a thousand servers trying to show an

381
00:35:58,060 --> 00:36:03,980
auditor what on earth state that server is in so it's that sort of cyclical thing which is what i think

382
00:36:03,980 --> 00:36:11,500
devops really should be about it's yeah ops helping devs help ops yeah and and that's something that

383
00:36:11,500 --> 00:36:18,860
people who've even with a traditional infrastructure mindset have bought into i mean you know we had a

384
00:36:18,860 --> 00:36:26,300
situation where we're talking to a customer and they didn't want to go any faster from the infrastructure

385
00:36:26,300 --> 00:36:32,300
side because the data center was full and we realized that the data center is full because developers are

386
00:36:32,300 --> 00:36:37,900
hugging the infrastructure because they don't trust the infrastructure team to deliver the capacity when they

387
00:36:37,900 --> 00:36:42,700
need it right so it gets into this cyclical problem and we said you do realize that if you built the

388
00:36:42,700 --> 00:36:48,860
trust up in the developers that the platform could deliver you what you need in a day they would give

389
00:36:48,860 --> 00:36:56,540
up all the capacity that they're hugging because they might need it once a year for some i don't know some

390
00:36:56,540 --> 00:37:01,740
regulatory test that they need and otherwise it sits completely idle right so it's it's trying to get

391
00:37:01,740 --> 00:37:06,060
that sort of we all help each other we're all wearing the same badge we're all in the same company kind

392
00:37:06,060 --> 00:37:11,420
of mindset yeah yeah and i remember i mean to highlight that i remember i remember us talking

393
00:37:11,420 --> 00:37:17,740
about that uh last time we talked and and i thought it was and i still do uh i think it's a great example

394
00:37:17,740 --> 00:37:24,540
of like you know in the old devops western western thing it's a great example uh practical example of

395
00:37:24,540 --> 00:37:30,700
what a pathological organization is like which is to say but you don't want to be that organization no one is

396
00:37:30,700 --> 00:37:35,340
like wakes up in the morning says like i'm going to put a pathological organization in place but

397
00:37:35,340 --> 00:37:45,180
it's exactly like the kind of unintended negative consequences that kind of occur when both sides

398
00:37:45,180 --> 00:37:52,300
aren't trusting and friendly with each other right and and it's it's kind of more lays on the developer

399
00:37:52,300 --> 00:37:56,860
side they're hoarding these resources it's not always the operations people but it does turn into this

400
00:37:56,860 --> 00:38:04,940
vicious pathological cycle where um bad things are happening you're you're wasting resources

401
00:38:04,940 --> 00:38:10,540
because of really like so speak the culture that you have in place like the people relations stuff where

402
00:38:11,420 --> 00:38:17,740
the ops people kind of assume developers are going to be wasteful and they're not making it easy for

403
00:38:17,740 --> 00:38:21,820
them to get resources and then the developers are like i don't want to work with those ops people

404
00:38:21,820 --> 00:38:26,140
they're terrible to talk with and so i'm just going to hoard this thing and make a an under under the

405
00:38:26,140 --> 00:38:31,820
desk data center and like whereas if you had a better relationship between them both of them would

406
00:38:31,820 --> 00:38:37,500
benefit i mean it's a typical like prisoner's dilemma kind of sort of of uh of capacity stuff but i mean

407
00:38:37,500 --> 00:38:43,580
anyways i i want to point out that that's a great example of of the effect of being a pathological

408
00:38:43,580 --> 00:38:49,260
organization but it's human nature as well i mean we saw it with covid how if you don't think you can

409
00:38:49,260 --> 00:38:57,420
get hold of pasta or toilet rolls you buy a hundred yeah yeah it's the same thing with with uh with

410
00:38:57,420 --> 00:39:03,180
infrastructure if you don't think you can get a vm when you need it you order a hundred and then you

411
00:39:03,180 --> 00:39:08,460
sit with them until and then then you think you can use them when you need them and people used to do

412
00:39:08,460 --> 00:39:15,660
that right it wasn't until we had to introduce things like you know um monitoring usage and telling

413
00:39:15,660 --> 00:39:23,100
people you're one percent utilized we are going to auto turn you off but to counter that we will give

414
00:39:23,100 --> 00:39:30,860
you free vms for 30 days so we gave that trust that and and they knew that you didn't have to go

415
00:39:30,860 --> 00:39:37,180
through the any approvals or anything to get a free vm for 30 days you build that trust and and we

416
00:39:37,180 --> 00:39:42,620
proved that it worked so there you go we can give it to you if you need it on demand therefore we're

417
00:39:42,620 --> 00:39:48,220
going to take away everything that you're not using but yeah you had to do the the trust thing first

418
00:39:48,220 --> 00:39:54,860
before you got any agreement to do the auto delete thing second right yeah it's human nature it's human

419
00:39:54,860 --> 00:40:00,780
nature it it reminds me i mean this is this is speaking of seven years ago is one of the things

420
00:40:00,780 --> 00:40:06,380
that one of your other teammates tony uh from from the home depot i remember in one of his early

421
00:40:06,380 --> 00:40:10,700
presentations when he was at the home depot going over how they were setting up this platform stuff he

422
00:40:10,700 --> 00:40:17,500
was saying uh i don't know maybe it was six seven months into this uh they had set up their platform

423
00:40:17,500 --> 00:40:22,060
and then developers weren't using it you know as much as they thought they were which is which is as you

424
00:40:22,060 --> 00:40:27,180
know not cool because you still have this business case you need to make like if you've spent all this

425
00:40:27,180 --> 00:40:32,300
effort building up a platform and then six months later it's not being used your your spreadsheet's

426
00:40:32,300 --> 00:40:39,980
not going to look good as far as as far as your business case um and and you know the idea that they

427
00:40:39,980 --> 00:40:45,020
had was like well what they found out is that people like didn't want to go through the hassle of

428
00:40:45,020 --> 00:40:50,780
accounting for and paying for the usage of that platform and so they were kind of like well so what if

429
00:40:50,780 --> 00:40:57,180
they don't have to pay for it because like it's kind of sort of all funny money in the in the first

430
00:40:57,180 --> 00:41:03,260
place it's all of our money and as an organization we benefit when developers are running on this

431
00:41:03,260 --> 00:41:10,380
platform so maybe we should just remove that barrier for them to do it and you know and we'll sort it

432
00:41:10,380 --> 00:41:16,380
out later but the important thing is to get people using it and and to you know again avoid that

433
00:41:16,380 --> 00:41:20,940
pathological thing where it's just like you're hoarding stuff because it seems because it's

434
00:41:20,940 --> 00:41:26,620
artificially expensive is is what what you want to you want to remove so you're absolutely right we went

435
00:41:26,620 --> 00:41:33,580
through the same sort of thing and we did change the way we did internal cost recovery initially

436
00:41:34,700 --> 00:41:41,180
people wanted us to have fair and transparent cost recovery based on what it really cost us to run

437
00:41:41,180 --> 00:41:48,540
it which is why the new stuff was very expensive and the old stuff was cheap because end of life is

438
00:41:48,540 --> 00:41:53,500
cheap right because oh yeah you didn't have to load in all the upfront fees for it yeah we've already

439
00:41:53,500 --> 00:41:59,020
written down the servers you're probably not paying license fees anymore because it's end of life

440
00:41:59,020 --> 00:42:05,420
yeah probably not got any people left that know anything about it or if you have this one guy

441
00:42:05,420 --> 00:42:11,580
like who's who spends a third of his time on it at best so if you think the real cost of running that

442
00:42:11,580 --> 00:42:18,300
that end of life system is the electricity right now there's a massive risk to it and unfortunately you

443
00:42:18,300 --> 00:42:23,500
know it was a concept that i touted for a while to try and put an internal sort of insurance premium

444
00:42:23,500 --> 00:42:27,340
because in my early days i worked in insurance right to try and get the idea that's interesting

445
00:42:28,060 --> 00:42:33,020
insurance premium charge against an end-of-life server because of the risk that it then came

446
00:42:33,020 --> 00:42:38,380
because if you had an outage the cost to the bank would be hard it never quite flew but i at least tried

447
00:42:38,380 --> 00:42:46,220
to to do it in the end we did manage to get the chain the the agreement to say within your area as you

448
00:42:46,220 --> 00:42:52,940
say it's all internal money sloshing around i then have ended up with the ability within my area to say

449
00:42:52,940 --> 00:43:00,620
i'm going to make the uh the new platform keepers chips i'm going to make it's a loss leader it's

450
00:43:00,620 --> 00:43:05,740
come and stay at our hotel the first three weeks is free and then i started loading up the cost on

451
00:43:05,740 --> 00:43:11,660
the end of life to drive people off those platforms even though it was artificial charges now it's not

452
00:43:11,660 --> 00:43:18,220
the only lever because internal money doesn't completely drive people off platforms but it's a

453
00:43:18,220 --> 00:43:23,420
it's one of a few things you can do right totally totally and and you know i mean i think at the

454
00:43:23,420 --> 00:43:29,900
very least it's just like more crap you got to put up with right like as a user right like it's just

455
00:43:30,780 --> 00:43:36,540
you know another another barrier and bottleneck to just getting on and doing the work right which and

456
00:43:36,540 --> 00:43:43,500
so it's good i mean that's a that's a a good product way to think is just like uh like how how quickly

457
00:43:43,500 --> 00:43:49,500
can someone just use this platform and like what's all the stuff not never mind like even before they

458
00:43:49,500 --> 00:43:54,380
get to the command line or a button that they click like what do they have to do and then i think you

459
00:43:54,380 --> 00:44:01,020
know that that almost seems like the let's call it the intermediate platform uh team's job is to like

460
00:44:01,020 --> 00:44:06,540
think about what's everything that has to happen before someone touches a keyboard and and like

461
00:44:06,540 --> 00:44:11,180
let's let's make that as easy as possible because that's going to be the next you know i mean it

462
00:44:11,180 --> 00:44:15,260
seems like you're constantly trying to figure out the bottleneck and and eliminate it and uh

463
00:44:15,260 --> 00:44:22,540
get get people moving along faster well and also removing things that stop when people gain the system

464
00:44:22,540 --> 00:44:28,940
because of internal reasons like so you know internal chargebacks and you know isn't it is a fascinating

465
00:44:28,940 --> 00:44:36,860
topic uh wow hilarious topic a lot of time because you know i even had the conversation where because

466
00:44:36,860 --> 00:44:43,100
we hadn't managed to sort it in the early days of virtualization internally two vms cost more than

467
00:44:43,100 --> 00:44:49,180
one physical server and because you were splitting up a monolith and you're often running say your web

468
00:44:49,180 --> 00:44:54,460
layer on one vm and your database on another internally people say well this is more expensive because

469
00:44:55,180 --> 00:45:00,460
it looked more expensive to them because they had the same cross charge right but you don't want

470
00:45:00,460 --> 00:45:05,180
people to be doing that because you know in real life that isn't the case it's definitely not

471
00:45:06,140 --> 00:45:10,940
more expensive to run two vms than one physical but you know you've got to start that's the

472
00:45:10,940 --> 00:45:16,460
continuous improvements you have to look at as well what what silly stuff is in the way of people

473
00:45:17,500 --> 00:45:24,220
using the platform or not using the platform rather right coming up yeah because or how do you stop

474
00:45:24,220 --> 00:45:29,100
people gaming the system to sort of say oh well you know your your platform is more expensive because

475
00:45:30,140 --> 00:45:37,420
you haven't sorted out the uh the pricing properly whatever it is yeah yeah yeah well great well this

476
00:45:37,420 --> 00:45:43,020
has been a good uh uh you know we'll have to uh we'll have to find some uh schedule some time to talk

477
00:45:43,020 --> 00:45:46,300
about all sorts of other aspects because there's there's many other things and we just kind of

478
00:45:47,500 --> 00:45:53,900
i don't know took some little digs here and there into it not not in the uh but it's uh and it'll be

479
00:45:53,900 --> 00:45:59,820
it'll be fun next week to see what uh what we end up doing in that talk and uh with with the mercedes

480
00:45:59,820 --> 00:46:06,460
people um but yeah i mean so uh like like like if people i mean do you have anything you want to point

481
00:46:06,460 --> 00:46:13,020
people to about yourself i mean uh any any uh any stuff you want to do a call to action about what

482
00:46:13,660 --> 00:46:18,540
what are you up to there on the internet yeah i mean so obviously i'm if people want to get hold of

483
00:46:18,540 --> 00:46:25,020
me or or see what i'm liking then obviously i'm on linkedin um just be cautious of the spelling of my

484
00:46:25,020 --> 00:46:30,860
name get his daran rice as we discussed just before yeah yeah because uh because everyone spells it

485
00:46:30,860 --> 00:46:37,180
wrong or as i said to you before maybe everyone spells it right except my parents exactly so it's

486
00:46:37,180 --> 00:46:45,340
daran rice okay on linkedin uh you know and i've recently also along these sort of lines wrote a blog

487
00:46:45,340 --> 00:46:53,100
um around how kpis drive behavior which is sort of right a classic sort of tale of um how transformations

488
00:46:53,100 --> 00:47:00,060
can go wrong if you set the wrong behavior kpis or okay to be honest it doesn't really matter it's about

489
00:47:01,180 --> 00:47:06,780
the fact that people will they'll achieve something based on what their their goal is

490
00:47:06,780 --> 00:47:12,700
right yeah yeah sure whether that is the right goal or not so you know if that blog can be shared

491
00:47:12,700 --> 00:47:17,500
that's a published tanzu blog that i wrote that maybe along these sort of lines would be interesting

492
00:47:17,500 --> 00:47:22,860
for people to read other than i think i think especially you know i i have i have three kids

493
00:47:22,860 --> 00:47:28,140
in the heat of becoming wonderful people right in the middle and uh it's easy to forget when when

494
00:47:28,140 --> 00:47:32,940
you're you're you're you're parenting that in a corporate setting people are generally very good

495
00:47:32,940 --> 00:47:40,140
at doing what you ask them to do as as represented by metrics so to your to your to your point you should

496
00:47:40,140 --> 00:47:45,180
make sure your metrics are correct because otherwise they'll give you exactly what you asked for

497
00:47:45,180 --> 00:47:50,860
it even though you didn't want it which is uh which is good well so i'll i'll put a link to that and uh

498
00:47:51,420 --> 00:47:56,540
in in the show notes we have or which you can find by going to uh tanzu talk.com and finding this

499
00:47:56,540 --> 00:48:02,860
episode in in the list and um you know there's also uh i'll also put a link to there's two other

500
00:48:02,860 --> 00:48:08,300
things one uh you know we mentioned uh platform as a product we have a great paper that was updated i

501
00:48:08,300 --> 00:48:13,660
think last year kind of just going over the concept of platform as a product and a little more

502
00:48:13,660 --> 00:48:17,900
detail on what we were talking about and also we have a there's a there's a great gartner report

503
00:48:17,900 --> 00:48:23,420
that we uh licensed that goes over i think it fits in this space it kind of goes over the idea of an

504
00:48:23,420 --> 00:48:30,140
internal developer portal which is which is something adjacent and overlapping to a lot of the platform

505
00:48:30,140 --> 00:48:34,060
stuff we were talking about that would be another thing to talk fun to talk about at some point kind

506
00:48:34,060 --> 00:48:40,140
of narrowing down to more of the the idp backstage role in here which i think is always fascinating to

507
00:48:40,140 --> 00:48:46,940
uh figure out what the venn diagram is but i i think that's a great report to look through because it's

508
00:48:46,940 --> 00:48:53,580
very um it is the style of gartner report that is very prescriptive and lists a bunch of stuff

509
00:48:54,140 --> 00:48:59,020
which i think is often useful in thinking about it just that you know the other style which is always

510
00:48:59,020 --> 00:49:05,340
nice is just like here's a fascinating great new idea isn't it awesome but you you sometimes are left

511
00:49:05,340 --> 00:49:09,980
thinking about what do i do now after that which is totally fine but this one has a little more

512
00:49:09,980 --> 00:49:15,020
practical uh and with that you know if if uh if you don't subscribe to the podcast you should go to

513
00:49:15,020 --> 00:49:20,780
tonsutalk.com and add it into your uh your podcast listener just search around your podcast thing for

514
00:49:20,780 --> 00:49:26,380
tonsu talk and subscribe to it i also recommend uh anytime you get access to someone's phone or device

515
00:49:26,380 --> 00:49:31,500
whether it's family friends or enemies you should subscribe them to it too so it downloads and give

516
00:49:31,500 --> 00:49:37,580
them a little surprise uh to follow there and with that we'll see everyone next time bye bye