1
00:00:00,000 --> 00:00:19,160
so this week we have paula kennedy um from our pivotal london office on and paula tell us a

2
00:00:19,160 --> 00:00:25,780
little bit about your role and how you've kind of ended up being someone who you know gave a talk

3
00:00:25,780 --> 00:00:31,360
say last year on platform as a product because that's kind of the that's the topic the thread

4
00:00:31,360 --> 00:00:37,560
we're going to be pulling on today um as domain said so my name is paula kennedy based out of london

5
00:00:37,560 --> 00:00:44,320
i've been at pivotal just over three years my current role is looking after our pivotal cloud

6
00:00:44,320 --> 00:00:53,820
foundry solutions team in europe so we have around 20 people based across europe who go out to help

7
00:00:53,820 --> 00:01:01,860
customers with how to essentially how to run install scale operate pivotal cloud foundry

8
00:01:01,860 --> 00:01:07,780
um i have a second job which i just took over recently as well which is looking after the

9
00:01:07,780 --> 00:01:13,680
education team in amir and actually the two roles fit very well together so we have more classical

10
00:01:13,680 --> 00:01:19,720
education which is how we enable customers at scale and then we have the pivotal cloud foundry solutions

11
00:01:19,720 --> 00:01:26,980
which is how we very closely work with customers platform teams to really enable them to think about

12
00:01:26,980 --> 00:01:35,760
platform as a product okay that's interesting to kind of that the complementary nature of sort of the

13
00:01:35,760 --> 00:01:46,440
the services and then the sort of at scale training um so the the big question for you is and we sort of

14
00:01:46,440 --> 00:01:51,280
we're talking about this before there there's there's a couple different questions sort of woven in

15
00:01:51,280 --> 00:01:57,960
together but it's really about not so much what the platform as a product is although i'm sure that'll

16
00:01:57,960 --> 00:02:05,460
come up more just the the how you get there um what does that look like and just given that a lot of

17
00:02:05,460 --> 00:02:12,800
folks are who are end up being on that platform team right the platform engineers the product manager

18
00:02:12,800 --> 00:02:20,900
um or product owner like and you know are those the same person do they have to be or can there be someone else who's sort of

19
00:02:20,900 --> 00:02:27,760
functioning in that role um but they didn't start that way they usually started doing some other job and so those people

20
00:02:27,760 --> 00:02:34,320
kind of have to go on a bit of a journey to become that and they might be designated it and called it before they're

21
00:02:34,320 --> 00:02:44,960
really kind of thinking it yet you know like you have a new job congrats new title but like you're not really doing it for i don't know

22
00:02:44,960 --> 00:02:49,120
some number of months until you're like okay now i get it right now i get what my new job is

23
00:02:49,120 --> 00:02:58,320
so i just wanted to see if you could just given like you see so this happen again and again and again um

24
00:02:58,320 --> 00:03:04,160
what's the is there kind of a pattern to sort of what that looks like and how where folks are coming

25
00:03:04,160 --> 00:03:11,520
from um and then ultimately like you know what what along that path kind of helps folks be more

26
00:03:11,520 --> 00:03:16,600
successful right if they could learn anything from the stumbling blocks that other folks have gone

27
00:03:16,600 --> 00:03:26,720
through what would that be uh to go to go down this path okay so i guess to start off with i'd say

28
00:03:26,720 --> 00:03:33,920
our customers are all coming from different starting points in fact when when my team first engaged with

29
00:03:33,920 --> 00:03:40,240
a customer typically at the at the point of in the customer's journey they have selected pivotal cloud

30
00:03:40,240 --> 00:03:47,520
foundry as their platform of choice they understand that our pivotal mission is we want to transform

31
00:03:47,520 --> 00:03:53,440
how the world builds software so the customer will have some inkling of the fact that changes are coming

32
00:03:53,440 --> 00:04:03,280
but may not fully understand the level of change that we're looking to drive into customers so when the

33
00:04:03,280 --> 00:04:10,640
pivotal cloud foundry solutions team first engages we have a very idealized view of what a platform

34
00:04:10,640 --> 00:04:15,920
team should look like and what a product owner should look like but quite often the customers are

35
00:04:17,520 --> 00:04:22,640
as you mentioned they may not be right at that place they may not have the people lined up they

36
00:04:22,640 --> 00:04:28,400
may not fully understand what work is involved what change of culture is involved what change of

37
00:04:28,400 --> 00:04:34,720
mindset is involved so it really is a journey when we start what we talk about with our customers is

38
00:04:34,720 --> 00:04:42,960
having a dedicated platform team that is balanced and that has a platform owner and so all of those

39
00:04:42,960 --> 00:04:49,040
things have very specific meanings when we talk about having a dedicated platform team what we see with

40
00:04:49,040 --> 00:04:54,960
our most successful customers is they have a small number of platform engineers a platform team only

41
00:04:54,960 --> 00:05:03,200
needs to be say two three four people it can be quite small and can support many multiple application

42
00:05:03,200 --> 00:05:08,720
developers so we talk about kind of a one platform operator to a 500 application developer i mean that's

43
00:05:08,720 --> 00:05:13,600
kind of a number that gets thrown around sometimes in pivotal but really the platform team can be quite

44
00:05:13,600 --> 00:05:23,040
small but that platform team is most highly effective when it's focused on running the platform so

45
00:05:23,840 --> 00:05:28,960
that can be quite a hard ask even for customers at the beginning they may have people that are lined

46
00:05:28,960 --> 00:05:32,880
up to be the platform team but they've got a hundred other things that they have to run as well

47
00:05:34,320 --> 00:05:40,640
and so um maybe they only have people that are available part-time or another pattern that we've

48
00:05:40,640 --> 00:05:47,440
seen quite often is customers might outsource their data center might outsource other parts of their

49
00:05:47,440 --> 00:05:53,840
infrastructure and might choose to outsource their platform team which in itself then can be challenging

50
00:05:53,840 --> 00:06:01,040
because you're trying to ask a big outsource company to change how they think about running this

51
00:06:01,040 --> 00:06:05,520
one small piece of software as part of a larger thing that they run on behalf of the customer

52
00:06:05,520 --> 00:06:11,520
and that's more challenging so like i say we typically look for a small dedicated team

53
00:06:13,040 --> 00:06:18,640
and we look for that team to be balanced and what we mean by that is that it's got people in the team

54
00:06:18,640 --> 00:06:25,040
who've got infrastructure knowledge as well as people who are more used to applying software engineering

55
00:06:25,040 --> 00:06:34,400
practices to the platform and in addition to that we also look for a product manager into the team which

56
00:06:34,400 --> 00:06:40,720
is slightly different from kind of product owner or platform owner as we were talking about before so for

57
00:06:41,520 --> 00:06:49,200
pivotal a product manager again is very specific skill set but it's that person on the team who is

58
00:06:50,320 --> 00:06:55,520
unblocking the team making sure that they can make progress that is running a backlog that is

59
00:06:55,520 --> 00:07:01,520
prioritizing the backlog that is really driving the platform as a product mentality home within that

60
00:07:01,520 --> 00:07:08,800
platform team which might be slightly separate from a platform owner or kind of platform champion who might

61
00:07:08,800 --> 00:07:17,680
might have more kind of political power is able to reach out more broadly in the organization is able to

62
00:07:17,680 --> 00:07:22,800
unblock the team at a higher level and might have ownership of multiple different things

63
00:07:23,840 --> 00:07:30,800
but is also that um kind of overseer of of a wider program maybe not just the pcf but maybe other parts of the

64
00:07:30,800 --> 00:07:40,560
the business as well okay that's really helpful because you know i think some folks think about

65
00:07:40,560 --> 00:07:49,600
the product manager as the product owner um but and they also i you know if someone were to ask me to

66
00:07:49,600 --> 00:07:56,480
define just product management um prioritization would be like the first thing that i think of like

67
00:07:56,480 --> 00:08:03,760
prioritizing you know the road map which is sort of effectively what the backlog is but i really

68
00:08:04,800 --> 00:08:10,320
liked how you described like the first thing that you said was the person who's unblocking the team

69
00:08:11,200 --> 00:08:15,200
yeah um and so i think that that sort of speaks to

70
00:08:18,160 --> 00:08:23,760
you know either that's just more what product managers are in general or on these platform teams

71
00:08:23,760 --> 00:08:29,920
what you can expect is that that is a big part of your job is is kind of performing that unblocking

72
00:08:30,800 --> 00:08:37,040
and that's related to this product owner is sort of blocking it unblocking maybe at a different level

73
00:08:37,040 --> 00:08:42,080
right and like more of a political level and you know resources level and whatnot not not so much

74
00:08:42,080 --> 00:08:47,920
at the technical level is that a fair kind of you know recap of that distinction that you just made

75
00:08:48,720 --> 00:08:55,680
yeah i think it's also about allocation of time so a product manager who's part of the platform team

76
00:08:55,680 --> 00:09:00,720
it's also that person's full-time job working on that platform with the team all day every day

77
00:09:01,360 --> 00:09:06,000
so they're unblocking like you suggested a kind of a more tactical level they're also prioritizing the

78
00:09:06,000 --> 00:09:11,040
backlog they're also in the stand-up in the retrospectives in the planning meetings they're

79
00:09:11,040 --> 00:09:17,440
all day every day part of the platform team whereas the platform owner or platform champion

80
00:09:18,080 --> 00:09:24,400
as i say might have a broader range of things that they are looking after and might only check

81
00:09:24,400 --> 00:09:32,320
in with the platform team on a less frequent schedule but it's still that that person that the platform

82
00:09:33,120 --> 00:09:42,160
uh team can go to to unblock them at a at a more senior level okay okay so and you mentioned that

83
00:09:42,160 --> 00:09:47,920
some of the some of the challenges that folks run into when they're kind of starting down this journey is

84
00:09:48,800 --> 00:09:54,880
you know say not not having dedicated folks or not having folks um

85
00:09:56,080 --> 00:10:02,080
you know internal to the the company itself if they're part of kind of an outsourced arrangement

86
00:10:02,720 --> 00:10:11,280
um what else in terms of you know let's let's imagine that those don't exist and you you actually

87
00:10:11,280 --> 00:10:17,600
have a dedicated team it's the the two to four people that you mentioned plus the the product manager

88
00:10:18,320 --> 00:10:24,640
and you know now what happens you know does does that necessarily mean that they're kind of like

89
00:10:25,360 --> 00:10:30,480
up and running right away and sort of operating in that or but or what steps do they have to make at

90
00:10:30,480 --> 00:10:37,520
that point so i would always say they should call in the pivotal cloud foundry solutions team

91
00:10:38,080 --> 00:10:44,240
because that's what my team is um but our starting point honestly for for treating the platform as a product

92
00:10:44,800 --> 00:10:51,840
is i guess it's it sounds very straightforward but it's it's really having a product mindset

93
00:10:51,840 --> 00:10:57,920
and the starting point is understanding your users and building the thing that your users need

94
00:10:58,960 --> 00:11:05,680
so the very first thing that we try to do when we come and engage with a customer is to understand

95
00:11:06,640 --> 00:11:12,080
what's the first workload that you want to put onto the platform because if we can understand

96
00:11:12,080 --> 00:11:16,640
what the first application or the first 50 applications i mean it is a question of kind of

97
00:11:16,640 --> 00:11:24,560
start small and then iterate is what we try to focus on but as a as a platform team treating the

98
00:11:24,560 --> 00:11:30,800
platform as a product it's about putting the user right at the center of everything that that platform

99
00:11:30,800 --> 00:11:36,960
team does and then you need to understand exactly what the requirements are from the users and in this

100
00:11:36,960 --> 00:11:44,080
case the users would be the application developers so you need to understand what the requirements are

101
00:11:45,040 --> 00:11:52,160
then you need to build the smallest thing we talk about mvp being minimum viable platform in this case

102
00:11:52,160 --> 00:11:58,560
so you need to build the smallest thing to then give access to your application developers so they can use

103
00:11:58,560 --> 00:12:05,200
it then they can provide you feedback and then you can iterate so in pivotal we talk a lot about user-centered

104
00:12:05,200 --> 00:12:12,320
design we talk about lean and agile methodologies to be able to build the smallest thing get fast feedback

105
00:12:12,320 --> 00:12:20,320
and iterate and when it comes to the platform we are saying exactly the same things so we take all of

106
00:12:20,320 --> 00:12:27,680
our labs methodology that we've built up over the last 30 years say and we're trying to take all of those

107
00:12:27,680 --> 00:12:34,960
practices into the platform because the end result that we're aiming for is to build the platform that the

108
00:12:34,960 --> 00:12:43,040
application developers want to use it meets their needs it gives them a wonderful developer experience and they

109
00:12:43,040 --> 00:12:49,680
are then excited to put their applications onto the platform so the starting point for the platform team has to be

110
00:12:50,320 --> 00:12:56,000
almost a change of mindset the platform team has to understand that they are there to serve the

111
00:12:56,000 --> 00:13:01,600
needs of the application developers instead of what we've seen more traditionally let's say of

112
00:13:02,480 --> 00:13:07,040
building what the platform team or the infrastructure team might think people need

113
00:13:07,680 --> 00:13:12,560
and then finding lots of other people don't put their applications or workloads on there because

114
00:13:12,560 --> 00:13:18,720
it just doesn't do exactly what people need it to do so the whole kind of build it and they will come

115
00:13:18,720 --> 00:13:24,000
model doesn't really work we're trying to do the opposite way around i know when labs is working

116
00:13:24,000 --> 00:13:28,800
on a new application they have those initial conversations with users to just determine what

117
00:13:28,800 --> 00:13:32,720
can we build that's going to be an mvp is it similar with the platform team gets some kind of feedback

118
00:13:32,720 --> 00:13:36,400
i mean how do they even make that decision about what the mvp is going to look like they should

119
00:13:36,400 --> 00:13:43,200
definitely talk to the developers i mean it feels it's very funny where we we've been to customers and

120
00:13:43,200 --> 00:13:48,880
we've spoken to platform teams and as domain mentioned earlier sometimes the customers

121
00:13:49,360 --> 00:13:53,120
are pulling in different people into their platform team but traditionally we've seen lots of

122
00:13:53,920 --> 00:13:59,440
uh infrastructure folks coming in let's say and then we might start off and say well let's go talk

123
00:13:59,440 --> 00:14:04,720
to some application developers which endangers like like horror in these people's eyes of like they

124
00:14:04,720 --> 00:14:12,480
actually have to go and talk to the application developers um which somehow seems terrifying but

125
00:14:12,480 --> 00:14:18,880
it's it's really a question of defining those user needs and one thing as you mentioned jeff in the in

126
00:14:18,880 --> 00:14:24,640
labs methodology we talk about the balance team of being design as well as product management as well as

127
00:14:24,640 --> 00:14:32,560
engineering in our platform team we would love to also have designers in there and designers are typically

128
00:14:32,560 --> 00:14:39,120
the ones that would lead the um kind of user research and creation of personas and really helping to

129
00:14:39,120 --> 00:14:45,120
define that user-centered design when we have platform teams typically our customers is it's a hard ask

130
00:14:45,120 --> 00:14:53,120
for our customers to provide a product manager generally it's even a hard ask to ask them to provide a designer

131
00:14:53,120 --> 00:14:59,680
so typically what we would do is have the product manager take that role as well so for example when

132
00:14:59,680 --> 00:15:05,200
when the pcfs team would show up on a customer we would bring our product manager we would pair with

133
00:15:05,200 --> 00:15:10,240
the customer's product manager and then together we would go and interview users like you interview

134
00:15:10,240 --> 00:15:15,360
the application developers understand which application is going to land on the platform first figure

135
00:15:15,360 --> 00:15:20,880
out what the requirements are and then build the platform that meets those needs and then we iterate so

136
00:15:20,880 --> 00:15:25,280
we're we're not looking to just get one application landing on the platform we want all the applications on

137
00:15:25,280 --> 00:15:31,360
there but we start with one and then we get feedback and then we add the next one and get feedback and

138
00:15:31,360 --> 00:15:36,000
it's that iterative cycle that makes sure that you're building the right thing not that you spend six

139
00:15:36,000 --> 00:15:41,520
months building a platform announce it to the application developers and then find it doesn't meet

140
00:15:41,520 --> 00:15:47,760
anyone's needs yeah i think it's like i could i could imagine how someone would go down the path of

141
00:15:47,760 --> 00:15:53,360
well if we want all the applications then we've got to understand what all the requirements are and then

142
00:15:53,360 --> 00:15:59,040
it's like oh well there's just so many requirements maybe we should find the least common denominators

143
00:15:59,040 --> 00:16:03,440
and then you end up with the least common denominators that are not enough for anyone to use

144
00:16:03,440 --> 00:16:10,480
exactly i mean we have this this talk track within our team where we say going into production

145
00:16:10,480 --> 00:16:19,360
is not a binary state it's a continuum so we think about you identify the first workload and you build

146
00:16:19,360 --> 00:16:25,680
that minimum viable platform that has everything that it needs so maybe it only needs integration into one

147
00:16:25,680 --> 00:16:30,160
database for example or maybe it doesn't for that one application maybe it doesn't need

148
00:16:30,160 --> 00:16:35,760
user authentication like you choose an app and you you create just enough of a platform

149
00:16:35,760 --> 00:16:39,840
that means that application can go all the way through to production

150
00:16:39,840 --> 00:16:45,120
and that's kind of step one and we think about it as uh circles which is funny because i'm i'm signing

151
00:16:45,120 --> 00:16:51,520
what the circles look like and now i can see what my sign language is showing but um you'd start with your core

152
00:16:51,520 --> 00:16:57,920
and the application lands and that's kind of production but that doesn't mean it's finished

153
00:16:57,920 --> 00:17:04,400
it means that you've now got the next ring of kind of requirements needed for the next 50 applications

154
00:17:04,400 --> 00:17:08,480
so you work out what the next workloads are you figure out what those requirements are and you add

155
00:17:08,480 --> 00:17:14,640
those features to the platform and then those 50 applications can go live and it's the it's sort of

156
00:17:14,640 --> 00:17:20,400
these building circles of you add more and more features but you add them into the road map and

157
00:17:20,400 --> 00:17:26,240
you prioritize them and as more features get added more workloads can land on the platform but you start

158
00:17:26,240 --> 00:17:34,000
small and then you iterate so now you mentioned that it's basically impossible to get a designer and so

159
00:17:34,000 --> 00:17:43,600
the product manager has to um often wear that hat now is that is it something that it doesn't seem to

160
00:17:43,600 --> 00:17:51,760
me like there's that many product managers kind of lying around inside a lot of enterprises particularly

161
00:17:51,760 --> 00:17:59,280
working on infrastructure software um that you can sort of oh yeah that person right so i imagine that the

162
00:17:59,280 --> 00:18:08,800
folks who end up as the product manager for this kind of internal platform had a very different job before

163
00:18:09,360 --> 00:18:15,200
uh so where do what kind of background do they end up usually having like the folks who end up being

164
00:18:15,840 --> 00:18:20,720
down the road successful product managers for this app platform

165
00:18:22,960 --> 00:18:32,640
it depends i guess is the standard answer um typically we see very some very technical product managers

166
00:18:33,280 --> 00:18:40,560
who might come from an infrastructure background or possibly they've been a sys admin before and they

167
00:18:40,560 --> 00:18:47,920
would be people who are very much embedded in the team but very technical alongside their team

168
00:18:49,280 --> 00:18:55,760
we've also seen customers who have pulled in people with a project management background that's a fairly

169
00:18:55,760 --> 00:19:03,440
typical pattern that we see and those people again will come in and be part of that platform team all day

170
00:19:03,440 --> 00:19:12,880
every day and might not be as technically kind of skilled on the platform itself but have the ability

171
00:19:12,880 --> 00:19:21,840
to be able to seek the user requirements to run that um iteration process to get the feedback who then

172
00:19:21,840 --> 00:19:28,400
develop their technical skills along along the way but are coming from a a completely different background

173
00:19:29,200 --> 00:19:34,320
i mean we've also seen a kind of an anti-pattern i guess as we've seen some some cases where

174
00:19:35,280 --> 00:19:41,200
we have customers who bring in external contractors because as you say product management skills within

175
00:19:41,200 --> 00:19:48,960
platform teams are hard to come by so we've seen customers go externally as well which is fine but

176
00:19:48,960 --> 00:19:54,960
um our encouragement is always to try to grow those skills in-house and it's something that we would

177
00:19:54,960 --> 00:20:02,160
like to help with as well so so pivotal does offer product management training as a as an option so um

178
00:20:03,200 --> 00:20:08,240
it's something that we're really really keen to help customers with it's so critical we see the

179
00:20:08,240 --> 00:20:13,280
customers who are the most successful are those that have their own dedicated team with their own dedicated

180
00:20:13,280 --> 00:20:18,560
product manager and those are the ones that are able to prioritize able to meet users needs able to

181
00:20:18,560 --> 00:20:23,440
release features quickly i mean those are the most successful patterns we see kind of coming back to

182
00:20:23,440 --> 00:20:32,000
that like journey or progression of folks who are coming along so you know starting by you got to go talk to

183
00:20:32,000 --> 00:20:37,600
those developers right you got to interview them and that's you know work through your fears wherever

184
00:20:37,600 --> 00:20:43,840
they may be coming from do you find like that the fear around like is it that they're afraid this is

185
00:20:43,840 --> 00:20:50,800
going to be a waste of their time are they just afraid of like having to sit there and have a conversation

186
00:20:50,800 --> 00:20:58,000
like i don't know if is it even is it fear really at all or i'm just curious if you've been able to

187
00:20:58,000 --> 00:21:04,080
sort of figure out like this is sort of the the psychological landscape of what's going on

188
00:21:04,080 --> 00:21:11,200
when you tell a team of you know would-be platform engineers guess what today we're going to go talk to

189
00:21:11,200 --> 00:21:21,280
some developers your customers it's really it's really funny i intend i attended a a pre-platform

190
00:21:21,280 --> 00:21:27,520
dojo workshop with a customer so so when my team gets involved we we do platform dojos which essentially

191
00:21:27,520 --> 00:21:35,520
is just our name for how we enable customers it's a the name of our engagement but i attended a pre-dojo

192
00:21:35,520 --> 00:21:40,400
workshop with a customer where we we really went deep with the platform team they had already

193
00:21:40,400 --> 00:21:46,800
identified their team we went deep with them on this is what we mean when we say platform as a product

194
00:21:46,800 --> 00:21:52,080
this is what it means to understand user requirements and build the right thing and we did a full day

195
00:21:52,080 --> 00:21:57,600
workshop and at the end of the workshop we did a retrospective which we love to do at pivot we love

196
00:21:57,600 --> 00:22:06,000
retros so we did a retrospective and one of the platform engineers gave feedback that said it all

197
00:22:06,000 --> 00:22:11,600
sounded very nice but it also sounded like a lot of marketing nonsense and it would never happen in real

198
00:22:11,600 --> 00:22:24,480
life which was really surprising um because somehow that person didn't believe us when we said no no we're

199
00:22:24,480 --> 00:22:29,280
actually going to talk to some application developers and we're actually going to understand their needs

200
00:22:29,280 --> 00:22:36,720
that's i think it's it's maybe not fear it's more just what people are used to let's say they're more

201
00:22:36,720 --> 00:22:42,800
used to having ticketing systems they're more used to maybe an application developer requests an

202
00:22:42,800 --> 00:22:48,560
environment and then it goes into a queue and then the platform team might pick up that ticket and then

203
00:22:48,560 --> 00:22:57,120
might work on it it's somehow habit i guess more than actually fear um but what was really funny and

204
00:22:57,120 --> 00:23:02,800
that's with that same customer we then followed up with the start of the engagement and we did uh an

205
00:23:02,800 --> 00:23:11,040
inception meeting and for us we have a very um clear process for what we want a an inception to look like

206
00:23:11,040 --> 00:23:15,920
it's typically one to two days and we ask for the customer to really bring a lot of people together

207
00:23:15,920 --> 00:23:22,080
and often it's it's a chance for all different teams within a customer to come together where

208
00:23:22,080 --> 00:23:26,640
maybe they have never even been in the same room before so typically we would ask for the platform

209
00:23:26,640 --> 00:23:32,320
team to be present platform owner so the platform team which includes product manager we would also

210
00:23:32,320 --> 00:23:37,520
ask for the platform owner to be present so some senior stakeholders to come along and we would also

211
00:23:37,520 --> 00:23:45,200
ask for somebody from security maybe somebody from compliance and representatives from whichever

212
00:23:45,200 --> 00:23:50,400
application has been identified as the first app to land we want someone from the application team to

213
00:23:50,400 --> 00:23:57,760
be in the room so an inception meeting could have 15 to 20 people all together but in that inception

214
00:23:58,560 --> 00:24:03,360
one of the things we will go through is kind of a road map so we'll say how long does it take now

215
00:24:04,080 --> 00:24:10,400
from the application team having an idea to getting the idea into production let's map out the whole

216
00:24:10,400 --> 00:24:17,440
journey and let's work out all of the steps and then let's work out if you're using pivotal cloud

217
00:24:17,440 --> 00:24:22,400
foundry how many of those steps get taken away how many of them get shortened how many of them get

218
00:24:22,400 --> 00:24:30,560
automated and for an mvp how many steps does the application team care about and it was a really

219
00:24:30,560 --> 00:24:35,760
interesting exercise we did this exercise with this customer and the platform team went first and they wrote down

220
00:24:35,760 --> 00:24:41,760
all the steps to go from like code getting sent to them to it going live in production wrote down all

221
00:24:41,760 --> 00:24:47,200
the steps and then the application team came along and said well these are the ones we actually care

222
00:24:47,200 --> 00:24:52,480
about and they just pulled down just a few of the post-it notes so a few of the things under the lines

223
00:24:52,480 --> 00:24:56,960
were like well which ones do you really care about and it turned out that the platform team

224
00:24:56,960 --> 00:25:02,480
traditionally would do a whole heap of kind of work that took a lot of time that wasn't delivering

225
00:25:02,480 --> 00:25:09,120
any value to the application team and i think after that inception you could suddenly see that for

226
00:25:09,120 --> 00:25:16,160
the platform team there was a kind of something resonated with them that made them think there might

227
00:25:16,160 --> 00:25:21,440
actually be some value in talking to the application team after all because it could cut out a whole lot

228
00:25:21,440 --> 00:25:26,160
of work that they were actually having to do that they didn't need to do to be able to deliver a

229
00:25:26,160 --> 00:25:31,200
kind of a sandbox play environment for the app developers to start testing immediately and giving feedback

230
00:25:34,000 --> 00:25:39,120
so in order to get the light bulb to go off you have to first get them in the same room

231
00:25:39,920 --> 00:25:44,960
do you think yeah i mean that's that's what happened in that one case yeah uh i would hope that

232
00:25:45,680 --> 00:25:52,320
when when when we're talking to our customers we can try to articulate it in a way that the customer

233
00:25:52,320 --> 00:26:01,120
understands the value but sometimes seeing is believing honestly so i think for for those folks who are

234
00:26:01,120 --> 00:26:06,080
thinking about or who are in a platform team or might be selected to form a platform team

235
00:26:08,080 --> 00:26:16,560
it might seem daunting to think everything's going to be different but it's also liberating to think

236
00:26:17,280 --> 00:26:26,880
that just by understanding what minimum platform looks like it could reduce hours of toil hours

237
00:26:26,880 --> 00:26:32,480
of wasted effort that isn't actually delivering any value and it allows the platform team to be more

238
00:26:32,480 --> 00:26:39,360
productive which then allows the application teams to be productive quicker which being a virtual circle

239
00:26:39,360 --> 00:26:41,760
everybody goes faster and it's a win-win for everybody

240
00:26:44,320 --> 00:26:49,200
okay so allowing the platform team to go faster

241
00:26:50,800 --> 00:26:56,800
since that that's the team that kind of has to make this shift into the mindset so after something like

242
00:26:56,800 --> 00:27:06,720
an inception what happens next what what starts to change and what what do you think folks um

243
00:27:07,600 --> 00:27:13,040
should be trying to do at that stage and what might be some anti-patterns at that stage

244
00:27:15,600 --> 00:27:23,200
i think one one good pattern that we've really seen is when a platform team gets into the habit

245
00:27:23,200 --> 00:27:31,920
of seeking feedback and it's a it's again it's a hard mindset to to shift into but we've seen customers

246
00:27:31,920 --> 00:27:40,080
who have really been able to accelerate their um kind of standing up of the platform scaling of the platform

247
00:27:40,640 --> 00:27:46,000
because what they're doing is every week they might be running a lunch and learn for stakeholders

248
00:27:46,640 --> 00:27:55,440
or they might be running a demo for app teams and it's about being able to show a wide audience

249
00:27:56,000 --> 00:27:58,080
the capabilities of the platform that they've built

250
00:27:59,840 --> 00:28:06,080
as quickly as they can so it's about getting as fast feedback as possible and by doing these regular

251
00:28:06,080 --> 00:28:12,800
like say lunch and learns or brown bag sessions or demonstrations of the platform they get immediate

252
00:28:13,360 --> 00:28:21,440
feedback and they have the added added benefit of building some excitement internally so

253
00:28:23,040 --> 00:28:30,160
by publicizing the work that they're doing and by being able to deploy things quickly ask for feedback

254
00:28:30,160 --> 00:28:36,720
make changes quickly they they build up that internal desire for the application teams hopefully to want to

255
00:28:36,720 --> 00:28:43,440
get on that platform as fast as they possibly can so it's a really good pattern that we've seen that once a

256
00:28:44,080 --> 00:28:47,600
customer engagement starts we will try to encourage that almost from the first week

257
00:28:48,320 --> 00:28:51,040
let's build a thing and let's show people by the end of the first week

258
00:28:51,920 --> 00:28:57,280
what have we built what does it look like let's get some feedback and then putting that pattern in place

259
00:28:57,280 --> 00:29:05,120
so that continuously happens and it's just normal behavior is a way that the like

260
00:29:05,120 --> 00:29:08,480
say the platform team can learn quickly and make changes quickly

261
00:29:09,680 --> 00:29:13,520
i think what we would consider an anti-pattern is

262
00:29:15,200 --> 00:29:19,920
the customer maybe starts off well goes and asks for requirements but then

263
00:29:21,120 --> 00:29:29,600
starts building and doesn't show anybody anything so delaying that feedback is is really an anti-pattern

264
00:29:29,600 --> 00:29:36,560
i would say okay is there any role of data and how that that reflects how the developers are actually

265
00:29:36,560 --> 00:29:40,560
using the platform because we know at times people think they know what they want but don't necessarily

266
00:29:40,560 --> 00:29:45,520
know what they want is there does data play a role there potentially i think it's going to depend

267
00:29:45,520 --> 00:29:52,560
on on on the applications themselves and the developers and what they're looking for uh quite often

268
00:29:53,200 --> 00:29:59,840
when a new technology is coming in like pivotal cloud foundry the application teams a lot of them

269
00:29:59,840 --> 00:30:05,440
won't know what those capabilities are so the starting point when we do demos for example is

270
00:30:05,440 --> 00:30:11,760
we have to show the capabilities of the platform so that the app developers know what they could change

271
00:30:12,880 --> 00:30:18,640
um another thing that we try and do on the education flipping hats for a second and putting my education

272
00:30:18,640 --> 00:30:25,680
hat on uh on the education side we have a couple of trainings which are more focused for application

273
00:30:25,680 --> 00:30:33,840
developers so we have the platform acceleration lab is a offering that we have and it's about training

274
00:30:34,480 --> 00:30:40,160
developers how to build cloud native applications and then we have a three-week course which is about

275
00:30:40,960 --> 00:30:46,320
training application architects and more senior application developers on maybe how to refactor

276
00:30:46,320 --> 00:30:54,240
applications and how to migrate applications so it could be the case that we need to give some

277
00:30:54,240 --> 00:30:59,600
education to those application teams because they don't know what the platform capabilities are

278
00:31:00,160 --> 00:31:05,680
and maybe don't know what as you said maybe they don't know what they're asking for necessarily

279
00:31:05,680 --> 00:31:10,640
because they don't fully understand what new capabilities are available to them so at the

280
00:31:10,640 --> 00:31:15,600
same time as the platform team is going to ask those developers what do they do now what tools do they

281
00:31:15,600 --> 00:31:22,080
need what services do they need etc there is a corresponding education that needs to happen for those app teams

282
00:31:22,720 --> 00:31:29,440
that teaches them what the platform can do that might teach them more around how to build cloud

283
00:31:29,440 --> 00:31:34,640
native applications depending on where that customer is coming from or where those app teams are but if

284
00:31:34,640 --> 00:31:38,720
they aren't used to building you know if they're not used to kind of 12 factor applications that they're

285
00:31:38,720 --> 00:31:44,000
not considering some of the things we think about for cloud native applications there's a corresponding

286
00:31:44,000 --> 00:31:46,800
amount of education that should happen for those app teams as well

287
00:31:46,800 --> 00:31:53,280
um back to the kind of good patterns um and what you said about getting feedback the and you sort of

288
00:31:54,160 --> 00:31:59,920
address this in your answer because my question is like okay well what does that look like how do you get

289
00:31:59,920 --> 00:32:06,640
that feedback i mean my first instance like you know i think about can we get your feedback i think of

290
00:32:06,640 --> 00:32:17,600
like a survey you know and it's like which can be useful for certain things but you know seems like that's

291
00:32:18,720 --> 00:32:27,440
not the full breadth of feedback uh exercises that you can do and you mentioned like okay well

292
00:32:27,440 --> 00:32:34,720
doing like a brown bag lunch and learn or a workshop or just a demo um these are also ways of getting

293
00:32:34,720 --> 00:32:44,720
feedback and i think like broadening the kind of uh sort of your your mental vocabulary around ways that i

294
00:32:44,720 --> 00:32:50,240
get feedback is part of the solution i mean i for me i i wouldn't have thought of those things but it

295
00:32:50,240 --> 00:32:57,120
makes sense when you explain it now if you're in a kind of an organization that's like not used to

296
00:32:58,160 --> 00:33:06,000
lunch and learns and internal workshops and internal demos you know how do you recommend folks get

297
00:33:06,000 --> 00:33:12,000
started with you know hey this we're starting this week we want to we want to give a demo by the end

298
00:33:12,000 --> 00:33:18,640
of the week um how do they do that in a low friction way to does it matter how many people they give

299
00:33:18,640 --> 00:33:24,560
that demo to if they're able to just grab a handful of folks or what do you what should they do to kind

300
00:33:24,560 --> 00:33:34,640
of start that process i think a key starting point is identifying the stakeholders so one of the exercises

301
00:33:34,640 --> 00:33:41,600
we would do in an inception meeting is we we would figure out the stakeholders but we group them so

302
00:33:41,600 --> 00:33:47,440
we'd have people who are core so that would be the platform team product owner product manager

303
00:33:48,800 --> 00:33:55,360
then we have interested so people who should be involved in lots and lots of the meetings but are

304
00:33:55,360 --> 00:34:01,440
not part of the core and then we might have informed stakeholders so people who are not paying that much

305
00:34:01,440 --> 00:34:07,040
of close attention but could be somebody from finance who's paying for the for the work or could be

306
00:34:07,040 --> 00:34:13,040
somebody from compliance who just needs to keep an eye and there's something again about starting

307
00:34:13,040 --> 00:34:20,480
small and then iterating so if you're a company that doesn't have a strong practice of internal demos

308
00:34:20,480 --> 00:34:26,400
internal lunch and learns for the platform team when they're getting started as a minimum they need

309
00:34:26,400 --> 00:34:33,920
to figure out who the key stakeholders are and have those folks attending at least a demo once a week

310
00:34:34,960 --> 00:34:41,520
and if there's an opportunity to record that and share it more broadly that's a good start if there's a way

311
00:34:41,520 --> 00:34:51,200
of inviting other people to attend remotely so using zoom or skype or you know webex whatever the tool of choice

312
00:34:51,200 --> 00:35:00,080
is then that's a good place to start i think it's it could be daunting to think i need to demo this i need to get the whole

313
00:35:00,080 --> 00:35:06,400
company to show up in a room at lunchtime and yeah and have a look um again we're all about starting small

314
00:35:06,960 --> 00:35:11,920
so it's finding that that low friction way whether it's a dial-in whether it's just a small group of

315
00:35:11,920 --> 00:35:20,080
stakeholders to begin with um and then another way to think about most most internal teams hopefully would

316
00:35:20,080 --> 00:35:27,440
be having some regular like stand-ups for themselves for the teams maybe there's an internal all hands

317
00:35:27,440 --> 00:35:33,200
if you can't get people to come to your scheduled meeting trying to figure out if you can get a quick

318
00:35:33,200 --> 00:35:40,640
slot on other people's regular meetings asking for a 15 minute slot on a company all hands or a company

319
00:35:40,640 --> 00:35:47,600
town hall or a regional meeting whatever the the company schedule is to be able to then just go and

320
00:35:47,600 --> 00:35:54,720
show up and do a quick demo could be another way to start that process all right well i could keep

321
00:35:54,720 --> 00:35:59,840
keep going in terms of pulling the thread on the like and then what happens and then what happens um

322
00:36:00,480 --> 00:36:08,720
but i know that you know this uh this can't be the never-ending podcast um where do you recommend

323
00:36:08,720 --> 00:36:16,000
folks go to kind of just learn more about it obviously engaging your team in this process is

324
00:36:16,800 --> 00:36:24,400
hugely helpful and i've heard from many many customers that you know attribute their success

325
00:36:24,400 --> 00:36:30,000
to we did that dojo right we did the platform dojo we wouldn't have been able to get this off the

326
00:36:30,000 --> 00:36:37,200
ground if we hadn't done that um so it's a huge testimony to to what your team does but you know folks

327
00:36:37,200 --> 00:36:42,560
who are kind of just listeners and want to learn want to think about applying this stuff where do you

328
00:36:42,560 --> 00:36:48,320
recommend that they go to learn more any particular resources or any kind of just general resources

329
00:36:48,320 --> 00:36:56,160
how can they follow you well that's a great question so in terms of resources on our pivotal

330
00:36:56,160 --> 00:37:02,960
website we have a white paper that was co-authored by one of my colleagues in the u.s joe fitzgerald

331
00:37:03,520 --> 00:37:09,120
and uh colin humphries who's based here in london who's in the r d team so they co-authored a white

332
00:37:09,120 --> 00:37:16,880
paper which actually is called platform as a product so i would recommend downloading that as a great

333
00:37:16,880 --> 00:37:22,560
resource just to to have a read through there's as you mentioned at the start there's a talk i did at

334
00:37:22,560 --> 00:37:29,840
cloud foundry summit last year which is also available on youtube which talks quite high level

335
00:37:29,840 --> 00:37:34,640
again it's not very detailed technically but it talks about some of the things i've mentioned today

336
00:37:34,640 --> 00:37:38,960
about how to treat the platform as a product what the team should look like some of the

337
00:37:38,960 --> 00:37:48,800
step-by-step practices that that team should have in place um definitely if customers are ready to go

338
00:37:48,800 --> 00:37:56,880
all in and have a engagement with pivotal they should engage my team or my colleagues around the globe

339
00:37:56,880 --> 00:38:04,800
because doing a dojo is a great way to get started for sure people can follow me on twitter if they

340
00:38:04,800 --> 00:38:12,880
feel like my twitter handle is paula l kennedy or one word that's probably the best ways okay well

341
00:38:12,880 --> 00:38:19,600
that's i think a good good set of stuff to get started with you got reading and watching and uh tweeting

342
00:38:19,600 --> 00:38:24,160
in there so you've covered you know like the holy trifecta so thank you so much this has been

343
00:38:24,160 --> 00:38:31,920
great i really i learned a lot about thinking on that that feedback process in particular and um putting

344
00:38:31,920 --> 00:38:40,160
that in perspective of how important that is in the overall journey to becoming a you know a product

345
00:38:40,160 --> 00:38:46,960
oriented team within your your kind of platform practice so thank you and looking forward to

346
00:38:46,960 --> 00:38:58,160
hopefully seeing you again soon thanks domaine thanks jeff