(upbeat music)
- Welcome to "Conversations with Leaders."
My name is Jake Burns.
I'm an Enterprise Strategist with AWS.
Today I'm joined by Brandon Pulsipher
who's the Vice President of Cloud Operations at Adobe.
Brandon, welcome.
- Thanks, good to be here.
- So can you start off, tell us a little bit about yourself,
your background and what you do at Adobe?
- Yeah, I've been at Adobe,
I came about 12 years ago through acquisition.
Spent 10 years before that
with a startup in the digital marketing
and kind of digital transformation space.
And now I've spent the last 10 years helping Adobe
along this cloud journey as we've expanded
and just taken that journey together
with both the solutions that Adobe purchased and acquired
as well as the transition of the Creative Cloud
that most people are familiar with.
- And so what does Cloud Operations at Adobe do?
- Yeah, it's a, I think, intentionally broad term
so that we can put whatever we want in there,
but focus on the cloud infrastructure,
whatever sort of your interpretation of cloud is.
If that's internal/external, kind of public/private,
all of the end-to-end infrastructure,
however we deliver that,
focus on the cloud spend, cloud efficiency,
and kind of cloud maturity,
and just kind of helping the business continue to adopt
and use the modern technologies in a way that adds value.
- I understand that at Adobe
you've tried a few different organizational models
and models for IT.
How do you know a model's working,
and how do you react quickly
when you find out that things aren't working?
- Yeah, I think this kind of concept
of agile, and kind of the engineering world
making its way to IT
has been a really fun kind of merger of mindsets to see,
and see the IT industry embrace that.
And I'd say that's part of what we've been through
in this cloud journey where operations
and engineering really come together.
And so we've had to charter a little bit of our own path
through that kind of DevOps SRE.
What does that mean?
How do we get there?
How do we move from the sysadmin world
to this new approach of Infrastructure as Code.
And we've been through quite a few
organizational adjustments and changes to get there.
And I think, for me, three or four organizations
and organizational names over last three or four years,
but folks have embraced it, and, I think, are excited
and energized by new ways of doing things.
And so it's been an exciting transition.
- So Brandon, a big focus for you has been cloud efficiency.
I'm curious, how do you track that?
And maybe we could start off, what is cloud efficiency?
- Yeah, I think that is an important question
because I think it's one of these things
we're still kind of defining.
There's not a sort of industry definition
or a set of standards that necessarily define that.
So I think it a little bit has to be defined individually
by each company or organization,
and what their objectives are, but I think
it's what's important in terms of efficiency,
how do we make sure we're using every dollar
the best way in creating value?
Obviously, we all wanna drive every dollar we can
into kind of innovation and creativity
and value for our customers.
And so if we're spending extra dollars on infrastructure,
then we're not able to do that.
So I think it's just about making sure
we have the right balance in that investment.
- Well, coming from Amazon, I really love that answer.
(laughs) every dollar you're not spending
on customers is not efficient, you know.
That's a good way to look at it.
Do you think there's a trade-off
between efficiency and agility?
- I don't think there has to be.
I think actually they fit really well together.
I think agility, the ability to be elastic and scale up.
And I think a lot of companies scale up really well,
'cause we are forced into building for that,
from an IT and an engineering aspect,
but the same forcing function doesn't exist
to have to scale down, and the other side of agility.
But I think there's a lot of value there
that can be derived.
They don't have to be competitive.
Great agility and the ability to be elastic
and spin up and spin down
can create a great customer experience
and drive better efficiency.
So it doesn't have to be sort of choose one or the other.
There's a sort of two-for benefit you can get.
- Yeah, that's a great point.
It's something that I always talk about.
We love to talk about scaling up,
but we don't talk about scaling down often enough.
And it's kind of like scaling down
is too boring to talk about.
It's like cost savings and eliminating waste.
But actually I think if you take a more long-term view,
and I wonder if you agree with this,
just having that ability to shut things off
and stop paying for them,
and having the ability to scale things down
tends to make organizations bolder in what they try
and what they experiment with
because the cost of failure is much less.
So it actually has kind of an exciting benefit
that probably stems from that ability to scale down.
- Yeah. I completely agree.
I think that's true.
And I think the more that we can drive value
and understand agility and how do we prevent failure,
but how do we learn from failure?
'Cause, inevitably, in any kind of agile approach,
there's gonna be some degree of failure.
And so we have to understand and acknowledge that as a risk
and just make sure we learn from it and adapt.
Failure is not a problem.
The same failure again and again is a problem.
- Yeah. I would go so far as to say
if you're not failing, at least some of the time,
you're probably not trying hard enough.
- Yeah, I think that's true.
And the challenge we haven't acknowledged
in this industry is how do we embrace the ability
to be agile and experience that failure,
but abstract our customers from being impacted by that?
- Right, right. Exactly.
So a good failure would be one where it's something
where your customers aren't impacted,
but you're learning,
and you're not making that same mistake
over and over again, obviously.
And a bad failure would be one
where it does impact customers.
And obviously, we don't wanna have those kind of failures.
So the correct strategy, or good strategy,
would be one where we're allowing ourselves to fail
but not have it impact our end customers.
- Yeah, I completely agree.
I think that's the end goal we all have.
- So Brandon, one of the things that comes up
when we engage with executives
going through transformations is this question,
does it have to be a top-down led transformation
or can it start from the middle?
Can it grow organically from the bottom?
I'm wondering how did this transformation
come about at Adobe?
And what are your thoughts on how to initiate one?
- Yeah, I probably....
I don't think it has to come from top down,
and often, probably...
Well, maybe sometimes there's a vision statement
of, hey, we need to change.
Certainly the how we get there
often comes from the people
who are sort of on the front lines,
and they have the best insight often.
And so I think, if we make these transformations at least
without getting the input,
and having that dialogue with the teams,
I think that'd be a miss
because there's so much we can learn.
So I think it should be a combination of both.
And that said, I think that's when it works really well,
when we've gone through some of our transformation.
I think we struggled a little bit
with this kind of DevOps mindset transformation for a while,
and I think for us that secret sauce was that balance
of kind of frontline managers and executive sponsorship
and leaders that were committed.
And when we sat down every week
with kind of these frontline set of managers and directors
and we shared the stories and we talked about the need,
and we didn't let up, we did that for month after month.
And people started to see that this is real
and we're serious about it.
And you saw it sort of come together
throughout the organization.
It wasn't being pushed from the bottom as an idea
that people felt is not going anywhere.
It wasn't some top-down mandate.
It really was this sort of combination
of bringing the right things together.
- Interesting, so it sounds like
there was some planning involved before you got started.
- Yeah, I think planning,
and, I think, attempts and failed attempts.
We probably started early on
with that sort of top-down mandate,
like, hey, we need to move faster
to this kind of DevOps mindset
and Infrastructure as Code.
And that sounded really good,
but not every network administrator or system administrator
is ready to start writing code.
And so I think we certainly had to invest
in the skill side of that,
and both invest in the people we had
and supplementing that as we hired
with, maybe we hire a software developer
and not a sort of infrastructure person.
And so how do we sort of...
Creating that mix, I think, was valuable,
but yeah, it took some time
and it definitely has been a journey.
- So any last advice?
I mean, there's a lot of people out there
who are still, believe it or not, starting out
on their transformation journey,
or starting out with the cloud.
For those that are just starting out,
and are trying to lead a change,
any kind of general advice that you would give?
- I think, just be willing to try new things out.
I think, again, another sort of,
I think, leadership concept or quality
that I think we're coming around to is this vulnerability.
And so being willing to be a little bit vulnerable
and maybe it's have an uncomfortable conversation
to say I think we need to make a change.
What's the value this is gonna create?
And then step forward and try it out,
and then be willing to say, hey, it worked or it didn't.
And then I think finding the right partners
to help you along the way is an important aspect.
We don't have to go this alone.
Fortunately, while there's still a lot of folks
maybe early in the journey,
there's a lot that we can learn from others
that have gone before us in a lot of ways.
- I agree. I agree.
There's never been a better time
to be doing a cloud migration or transformation
just because we have so many great examples nowadays,
unlike a few years ago, right?
A very short few years ago.
Nowadays we have so many great examples of what works.
Some examples of what doesn't work.
And so we're not going into the unknown anymore, right?
So learn from those who've done it before.
- Yeah, yeah, I think that's an absolutely valuable concept.
And again, maybe not every element of that applies,
but I think that's one of the things
we see value in with AWS
is sometimes we're still migrating workloads to the cloud
and we may sort of transition
a workload that we've done.
It's very similar to other things we've done,
but occasionally, we're hitting something
that we haven't done before.
And so just the ability to call on our partners
and say, hey, you've probably seen this before.
We haven't.
Help us understand how we might navigate this,
and what you've seen work or not work
so that we can try and avoid those pitfalls.
- Yeah, absolutely.
Definitely having a strong partner to rely on
gives you a competitive advantage.
And it's very wise to take advantage of that.
So Brandon, I really wanna thank you
for being with us today.
It was a great conversation.
- Yeah. I enjoyed it.
So it's always exciting to talk about the transformation.
(upbeat music)