In this episode, Pivotal’s Andrew Clay Shafer and Coté talk about this history of DevOps—what it is, and how it relates to things like continuous delivery and cloud. Also, we discuss what it means to be a “learning organization” and some studies thereof that Andrew has delved into.
Want to hear how organizations are using Cloud Foundry to further their DevOps projects? Come to the Cloud Foundry Summit, May 11th and 12th to hear all about that and also check out the technical underpinnings.
Register with the code COTE to get 25% off!
PLAY EPISODE
SHOW NOTES
- Subscribe to the feed: http://pivotalsoftwarepodcast.libsyn.com/rss
- Feedback: podcast@pivotal.io
- Links Referred to in the Show:
- Coffee – what’s your deal? Andrew was trained at Caffé d’bolla.
- Walk us from “Agile Infrastructure” to DevOps.
- What innovations enabled DevOps?
- DevOps answers the how, the process.
- There is no DevOps manifesto.
- “Organizational Learning Culture’s Influence on Job Satisfaction, Organizational Commitment, and Turnover Intention among R&D Professionals in Taiwan during an Economic Downturn”
- Seven dimensions of organizational learning questions.
- Andrew’s talk on the topic of being a learning organization.
- “Survival is not mandatory.” Is it reasonable to ask organizations to change? Have you seen people change? You should assume that people are smart and can learn.
- The DevOps elephant.
TRANSCRIPT
Coté:
We’re recording here in the morning, Andrew. We talk a lot about technology and platforms, things like that. This episode we’re going to talk about DevOps but I wanted to start off, I got to ask you, what’s your coffee ritual? What kind of coffee person are you?
Andrew Clay Shafer:
I’m one latté into this morning.
Coté:
A latté. Now, I assume you’re at home, let me do a little Sherlock Holmes-ing here, or maybe Curious George when he was being Sherlock Holmes. I assume you’re at home, right?
Andrew Clay Shafer:
I am at home, but I did not get the latté at home.
Coté:
Whoa, you’re throwing me for a loop. Did you actually go out and get a latté and return to your domicile?
Andrew Clay Shafer:
I take the kids to school and then I typically don’t actually drink a lot of coffee when I’m home. I had to go to the bank and then I saw the coffee shop and I was like—I’ll drink a latté.
Coté:
I see. Now you’re a … Do you go to some sort of local cofferteria? I don’t even know what they call those. Coffee shop? What’s your general selection criteria for going to a coffee place?
Andrew Clay Shafer:
I got ruined on coffee by going to a place in Salt Lake which … Everyone scoffs when you say there’s this really good coffee place in Salt Lake. But Salt Lake actually has this amazing coffee culture. Because of the underlying culture they don’t drink coffee so then as a reflex reaction to that there’s a lot of coffee, or a lot of really good coffee.
Coté:
Sounds like some business geniuses that they have. These folks don’t drink a lot of coffee, let’s open some coffee shops.
Andrew Clay Shafer:
Have you ever seen … I’m assuming you’re familiar with some Seinfeld episodes with the Soup Nazi?
Coté:
Sure.
Andrew Clay Shafer:
This guy is the coffee Nazi. He will … When he first opened he would not serve you coffee in anything but porcelain. You could not get coffee to go.
Coté:
BPA-free then.
Andrew Clay Shafer:
If you ask for milk or sugar in certain coffee he wouldn’t give it to you.
Coté:
I like this guy. Just black coffee. That’s my style.
Andrew Clay Shafer:
You could get milk in a latté obviously, but if you wanted to do the siphoned coffee and then you ask for milk he’s like, “No.”
Coté:
Right. He’s like the coffee has been prepared to perfection when I hand it to you.
Andrew Clay Shafer:
That’s right. He buys the beans, he roasts the beans, he only buys enough beans to serve for two weeks at a time because after that they’re undrinkable.
Coté:
Wow.
Andrew Clay Shafer:
Exactly.
Coté:
Does this guy still exist?
Andrew Clay Shafer:
He does.
Coté:
Man, I got to go to that place.
Andrew Clay Shafer:
It’s great. If you ever end up at Mountain West Ruby Conference or one of these conferences in Salt Lake, go to caffé d’bolla. That ruined me for life. Now places like the Blue Bottle, whatever, a bunch of places people think are great in San Francisco, are pretty mediocre.
Coté:
Yeah.
Andrew Clay Shafer:
There’s good places in Pacific Northwest obviously. But that ruined me and so now when I go to a place I’ll usually try an espresso but then they’re usually terrible. Then I fall back to latté because you can cover the fact that no one knows how to make espresso with a little bit of milk.
Coté:
Yeah. It’s true. The latté is … It’s your lowest risk thing if you’ve got any notion of fancy coffee in you. Because, like you said, it can cover up a lot of problems and yet still taste pretty good. In fact I think you could probably get Las Vegas casino coffee. We’ve all …
Andrew Clay Shafer:
It’s terrible.
Coté:
Yeah. Every time I drink it I imagine that there’s these gigantic vats in neon lit rooms where they’re just pouring in some powder and boiling water. You just got to get your stuff sometimes.
Andrew Clay Shafer:
There’s a few things in your life that will just ruin you from that moment on. Once you’ve had really great espresso then everything else seems terrible. Or if you end up going to Belgium then you can’t have mussels or chocolate or any of these other things again without being like wow these are terrible.
Coté:
Speaking of Belgium, we were there several months ago now, it’s been a long time. Time flies when you’re having fun or just trying to get the kids to school. I remember that little coffee … It wasn’t a coffee shop, it was a café, and I had ordered just a normal drip coffee in so much as you can get that in Europe. I think you had a latté, or an espresso, a pretty full coffee service. I took a picture of this and I never did anything with it so here I am doing it. It looked like … I had this stripped down black coffee and then you had the full coffee service. I was thinking this is a perfect example of enterprise feature requirements and very stripped down lean feature requirements. Because the … On the one hand, the coffee that you had, it had a spoon, it comes with a chocolate, it’s got an optional sugar, it basically is going to be up and to the right on the Gartner magic quadrant because it has everything, and it’s got vision.
Andrew Clay Shafer:
Ability to execute and completeness of vision.
Coté:
Yeah. It’s just that spreadsheet that the product manager for that coffee filled out all filled out 100%, perfect. Whereas my coffee was just wasn’t much going on. It always strikes me how much Europeans put into that coffee service. There’s a lot of Baroque stuff around it and the result is awesome. I got to work on that metaphor, it seems like a good metaphor for something. The problem is … The issue with the metaphor, and maybe this is the double meaning of it, is I want that chocolate, right? I want all those wingdings and accessories. I don’t want to subject myself to the Spartan just black coffee. It’s … I’m conflicted.
Andrew Clay Shafer:
We’re going to have to up your coffee game, Coté.
Coté:
That’s right.
Andrew Clay Shafer:
I’m going to take you … We’ll do a little tour through Pacific Northwest, hit Salt Lake, try some of these other places. We’ll get you on the siphons, we’ll let you understand the nuance of the espresso so when the guy says it has plum notes at the bottom then you’ll understand what he’s talking about.
Coté:
Yeah. I’m all for it. I drink about a pot of coffee a day so I’m all for it. I will get more specialized.
Speaking of how you want to outfit yourself and cultrate yourself and accouterment yourself, what I want to talk about today is DevOps. We’ve actually, you and I, over many years have talked about DevOps, we don’t always call it that, but it’s a discussion that we have quite a bit. I thought for the listeners that we have evolving here, the weird hodgepodge of audience that we have, it would be nice to go over what DevOps is and then pretty quickly get to how things are going at the moment, right?
One of the things when I’ve been studying DevOps, as I often note, I often like to over rotate on the tool side, the technology stuff. Because the community as a whole, in a positive way, over rotates and emphasizes the culture part. They’re very much so into what goes on in the culture and how all that stuff pans out. Obviously these two things together give you a complete picture.
But before we get to that, the other thing that I think would be fun in this conversation is way back when we used to call it agile infrastructure, that was pretty much the framing of DevOps that we had. There was this weird phase right back … Remember when the IT skeptic was becoming popular? It was a strange phase of ITIL fading into agile infrastructure and cloud was affecting it and things going on. Then we finally called it DevOps and everything was hunky dory and it’s still going on in a thing. But take us back to that moment when agile infrastructure was a discussion going on. How did you get involved in this thing called DevOps and start to figuring it out?
Andrew Clay Shafer:
Not to exhaust a meme but you keep using that word. Yeah, anyway. The Princess Bride … I was basically talking about agile infrastructure as a consequence of being deeply involved in agile software development practices, being a very frequent member of this thing called the Agile Roundtable in Salt Lake, it was led by Alistair Cockburn. Then starting to work on Puppet and coming to realize that there’s … It wasn’t just me, there’s a lot of other people at the same time. I think one of the things I did was wrap an articulation around a lot of the practices that people were adopting. Recognizing that in this world where you can now configure things with an API, you can provision things with an API, you can add and take things out of monitoring with APIs, that all that work looks suspiciously like software development.
Coté:
Right.
Andrew Clay Shafer:
That you can start to use a lot of the processes and tools from software development. I also was … A lot of times when people say agile what they really mean is scrum. I feel like I’m really fortunate to have been exposed to a much broader narrative around agile through Alistair Cockburn and through some of the XP practices and some of the people that I was involved with in Salt Lake. It was very easy … Part of this is Alistair’s gift to everyone to think about context and try to figure out ways to take advantage of this transition.
I also recognized that the agile framing was very developer centric. You can go back … I don’t want to put words in anyone else’s mouth, but definitely people gave me a lot of credit for a lot of ideas in the DevOps movement. If you go back and watch some of the presentations I did, say 2008, 2009, honestly I think probably 90% of what’s been discussed over and over in DevOps is all in those presentations with respect to both the tooling, the goals of automation, the culture, all of it is in that prototypical form in the things I was saying and doing in 2008.
Coté:
You alluded to this earlier, and like I said I tend to over rotate on tools just because we got your culture stuff covered elsewhere, but there’s an interesting thing that I’m always interested in tracing with technology. There’s almost a set of innovations, I’ll call them, tools or technologies, or ways of using tools or technologies, that enabled people to do this agile infrastructure and DevOps stuff, right? There was something that was not nicely … You couldn’t really do it before. You couldn’t automate your infrastructure as well or get … To use another phrase programmable infrastructure or whatever.
Andrew Clay Shafer:
Absolutely.
Coté:
What do you think that change was? What innovations were introduced that made it possible to start doing DevOps as we call it nowadays?
Andrew Clay Shafer:
One of the things I just said is that you have to be able to do these things with APIs. You have to be able to do these things programmatically. If you’re going to … I don’t think this is … It goes back to how you want to define the word and how you want to frame things. If you want to do these practices and you can’t bring machines up, you can’t provision machines, you can’t do a bunch of these things, then a lot of it just starts to look like waste, right? You spend a lot of time with people doing monotonous, tedious, repetitive tasks that computers would be very good at doing. Machines are very good at doing the same thing over and over. The types of problems that you can solve when you move to these automation frameworks, the API-driven provisioning, whether that’s in your own data center or outside of it, just changes what you’re capable of doing.
Also I’m very fortunate to have had the perspective … A lot of this was due to the Puppet community and connections that I made. A lot of the people that were building big web in that timeframe, they had what would pass for clouds right now, private clouds, they were able to provision on demand, they were able to do a bunch of stuff that a lot of the enterprise people are tripping over themselves trying to get to. That was just a function of … It’s existential. If you’re going to grow at the pace some of these organizations had to grow then you have to solve that problem. ITIL is not your friend. In fact it’s probably a detriment to whatever you’re trying to accomplish. There’s this transition … I would say in may cases or many ways DevOps captures some of the practices … I wouldn’t say that it was all about big web per se but it was about going faster and safer and that movement and the explosion of the internet really forced many organizations to find those solutions. It wasn’t that they set out to find those solutions it was a necessity. The other option was to not survive.
Coté:
There’s almost … One of the things you hear is that DevOps is just a continuation of continuous delivery, if you will. There’s a lot of continuous in there. It seems like … Just to recap there’s two technologies that enabled DevOps, or innovations if you prefer fancy words.
Andrew Clay Shafer:
I’m not sure I like that framing. I’m not sure I agree with it. I think that it’s not a continuation of continuous delivery I think that those … To me, my framing, and I’ve had many personal conversations with Jess Humble about this and related topics, I’d say continuous delivery and DevOps are really the same thing or they’re manifestations of the same thing from different perspectives.
Coté:
Right. It seems like the two technologies that enable all this DevOps commotion, or essentially programmable infrastructure if you will, things are highly automated and you let the computers do what they’re good at instead of letting a service desk and people do what they’re good at which is taking a long time, to be snarky about it. Then there’s also the idea of continuous delivery is … We have the tools that support run operating like this, if you will, and if we lacked those tools essentially it wouldn’t create all the cultural problems that we have. We would still be stuck with the more manual way of going about doing things. As with a lot of things it’s a weird confluence or vortex, if you will, of different technologies that have come together and out the other end comes this idea of DevOps, if you will.
I agree with you. I think treating the idea of … Not to get overly nuanced but treating the idea of continuous delivery is pretty much one-to-one to what we’re talking about here, fits very well with how to frame everything and start thinking about the tool chain. Definitely … Just reflecting on me watching technology over the past 20 or so years, the speed at which the underlying technologies, like the automation and the cloud technology, and then also the technologies behind continuous delivery, the speed of which those have become mainstream has been extremely fast. It’s been, I don’t know, five, six years or so, which is … For it to reach … I don’t know what the percentage is but significant material double-digit use and awareness in the market. That’s a very … That’s almost as fast as the web was adopted.
Andrew Clay Shafer:
There’s a quickening. Everything is getting faster and that’s part of what driving this. But if you go back to the vocabulary and the framing here, I would probably argue that continuous delivery is a why and a what and then DevOps is a how.
Coté:
Exactly. Then that gets to … It unravels why people talk about culture so much. In the sense that if you’re talking about the how or the process or the way you’re going about things, then that becomes a human problem. It’s not really anything you can compile, it’s basically just to use … To borrow a phrase a thought technology that you’ve got to deploy. Perhaps like programming the human mind is much harder than computers. Computers are pretty dutiful but convincing people to change the way they do things is much more difficult.
Andrew Clay Shafer:
The tools inform the process and vice versa. I would say that … I’m not sure I 100% agree that everyone over rotates on culture. There’s actually debates inside of some of the pockets of the DevOps community where one side over rotates on culture and the other side over rotates on tools, and that’s okay. I think that the … In general, and this is true of a lot of other progressive movements in very similar arcs, is that things start with these principles, these framing principles, and sometimes they’re explicit and sometimes they’re implicit. That manifests itself as practices and then those practices, because tools and practices are intertwined, those make tools. Tools are the easiest thing to see and they’re the most concrete thing. I think that’s why certain people that aren’t … They don’t want to live in the abstractions. It’s easier for them to fixate on the concrete. I think that’s where you see this divide, personally.
Coté:
It occurs to me we haven’t really covered the basics of what DevOps is trying to deliver. Obviously you can reverse engineer that if what we’re talking about is continuous delivery and basically using highly programmable cloud infrastructure there’s a notion of a certain high velocity that you’ll achieve with things. But when you’re thinking of defining what DevOps is, what do you say?
Andrew Clay Shafer:
There’s been some interesting debates in the circles of people that are involved and have been involved in DevOps around the need or the necessity to define DevOps, and there’s people arguing both sides of it and people saying we shouldn’t do it. In many regards it’s been left vague as a feature. You don’t fix the practices, you don’t fix this. One of the things that I’ve and these go back to the talks I’m referring to earlier, I always had this thing and I borrowed it from this guy’s blog post around the flying by the seat of our pants cycle. Basically the cycle starts with smart people flying by the seat of their pants, and then they have some success, and then those things they did become … They start to recognize these patterns and then those patterns get recorded and they become dogmatic. At some point the context of that dogma is maybe different than the new reality that things have evolved into and so smart people reject the dogma.
Coté:
It’s how pants become canon. But if the original pants were bellbottom and then mom jeans are popular in the ’80s, you got to revise your canon once the pants become official.
Andrew Clay Shafer:
I’m not sure how far I want to go with that metaphor.
Coté:
Any time you can make a Gloria Vanderbilt reference I think you want to take it, you want to run to it, just wrap your hands around it.
Andrew Clay Shafer:
Embrace it.
Coté:
That’s right. It is interesting that there’s a very definite agile manifesto and proud of all of those points we are as it were. But there’s not so much a DevOps manifesto, there’s not definitive canonical references for things. There’s definitely collections of literature and links and books but there’s not a founding document so much.
Andrew Clay Shafer:
It’s interesting. I think if you look there’s definitely people who have made some statements but there’s not been a central manifesto that everyone’s rallied around. I think that’s actually … While it may be confusing for a lot of people it’s a feature.
Coté:
Right. When you’ve observed … Despite the fact that there’s not …
Andrew Clay Shafer:
Working as designed, will not fix.
Coté:
That’s right. Despite the fact that there isn’t a perfect articulation of it and therefore the following question is a little funny if you think about it too much. But when you’ve observed people or organizations that are doing DevOps over the years, what do they achieve? What are the benefits that they get? Why do they go through all this weird cultural change? What do they end up having?
Andrew Clay Shafer:
They typically would have the ability to deploy software. They also tend to have … I will consider it a higher level of contentment. That’s language I just borrowing from Adam Jacob, who just gave a great talk about related topics at his conference. I think that to me personally a lot of this has to do with creating systems. I think there’s a thread going back through Segui and Demming and some of these other people where DevOps is just a manifestation of these ideas that are decades old being applied again to … In some ways centuries old.
There’s a really interesting article where people are talking about some stuff from the 1800’s, and how for whatever reason things devolved back to this autocratic, bureaucratic mechanism where in … Especially I think when you have a lot of pressure to evolve in order to survive then you have to let go of a lot of those boundaries. In knowledge work, which is what I feel software is and certainly system engineering, then if you don’t empower people, if you don’t tap into their intrinsic motive to be able to deliver that, then you’re really at a disadvantage. If you’re trying to manage software like you would try to manage digging ditches I think you’re in for a world of hurt. You can’t start with the premise that you don’t have smart software developers and sys admins, or else you’re already losing.
Coté:
Right. It reminds me of a conversation yesterday. It’s always dangerous to analogize software to three-dimensional engineering like building a house. My mother and her husband, my step-dad, are building a house and of course they close on it a month ago and they still are having contractors come out and fix things. I was trying to do some root cause analysis, a retrospective if you will, of why is that happening. It turns out that they were behind schedule around Christmas time so the contractor just rushed everyone and didn’t follow the maxim that if you’re made to wait it’s to assure you like your house.
It sounds like there was a bunch of rush work and these contractors didn’t work out and all sorts of problems happened. Then not only was the timeline compressed to be unrealistic through this weird autocratic belief that actually these people the reason that they’re not done is I just haven’t yelled at them enough. This is a fundamental human anti-pattern is the reason that things are not going how I want is because I’m not getting angry enough at the people and they’re just lazy. Which sometimes can be the case but often times is not really the case. Then there was this compounding problem, again that you see a lot in software, where we’ve already screwed up and now we have to have the tile people come in and work on stuff again so they’re going to layer a fix on it. You put the tile in and you add more grout and then when the grout dries it’s a different color than the other grout that you had. Now this problem is just spiraling out of control.
You see things like that in development all the time. Let’s do this emergency patch to fix things and then there’s this chain of issues that happen. Anyways it reminded me of what you’re talking about in the software world is what’s … A lot of what I like about the DevOps conversation is it’s a … Or the conversation that goes on there and especially the agile world is it often gets to the point of this stuff is hard and unpredictable and you need to relax and establish a system that lets you just learn how to do it each time and learn what’s working in your context and not have these unrealistic expectations of things. Because otherwise you just have this grout that’s a different color. You’re just shooting yourself in the foot continuously.
Andrew Clay Shafer:
In this type work, and I experienced this at every level throughout my career, you are constantly given the choice between doing something right and doing something right now. I think that’s a decision that every developer and every sys admin makes minute to minute, hour to hour, day to day.
Coté:
Exactly. That’s exactly what I was thinking in talking about my mom’s house. Again I was using this framing in my head to think about just software and technology. Is it realistic to suggest to my mother that they should have just said the house will be done when it’s done? I always like to remove common patterns of tech discussion into another domain that is very common. It’s just man, I know from an engineering perspective that’s the right answer but that’s such a hard thing to have someone who’s buying a house accept. But on the other hand that’s what you need to do.
Andrew Clay Shafer:
Indeed.
Coté:
It’s just like that in software. It’s going to be done when it’s done, what do you want from me?
Andrew Clay Shafer:
Going back to the Salt Lake Agile Roundtable, there was frequently a moratorium on discussing estimation.
Coté:
Exactly.
Andrew Clay Shafer:
About once a quarter we would lift the moratorium and then after one session be like no, can’t talk about that for a while.
Coté:
Did you at least have a talk that was how to convince people not to do estimates?
Andrew Clay Shafer:
That’s actually a movement that has been going on for a while. There is a lot of interesting conversation going around that. We talked about this a little bit while we were wandering the streets of Belgium. But there’s some interesting movements I think. The no estimates are interesting, the kinevits? stuff is interesting. A lot of people are starting to realize the inherent uncertainty and that just because you have a Gantt chart that says something’s supposed to be done before something else on a certain timeline that is a … It’s often just a lie that you’re telling to yourself.
Coté:
To that end, this gets to another phrase that comes up a lot that we can discuss, that is the idea of being a learning organization. Clearly part of what that means is that you’re learning reality, you’re learning what the date is going to be, so to speak. You’re always learning if you’re done or what it takes to get done so there’s that day to day learning that you’re doing. Then there’s also learning new tools and ways of going about things. As you’re solving problems you have to learn new technologies and not just rely on the old ones. I feel like being a learning organization is more about just learning how to cope with problems as they come. In the discussion you’ve had in this DevOps world, what do people mean when they talk about being a learning organization?
Andrew Clay Shafer:
As a consequence of DevOps being very good to me, I had the luxury of not really needing to work and one of the things that I spent a lot of time doing was reading papers about organizational learning. I did some presentations on this 2013, 2014. I found some really interesting research that framed it. It all started when I stumbled on this dissertation a Chinese gentleman had written about organizational learning in respect to job satisfaction and retention in these R&D departments in Taiwan. I can dig up the paper, it’s referenced in the presentations I gave. But then that got me reading about the research that he was referencing and then finally I ended up reading a bunch of stuff by Watkins and Marsick, which are two women who did … They came up with this framework for seven dimensions of organizational learning and they would give you … There’s a questionnaire to frame what organizational learning means inside of your organization. I just felt like this was the closest thing that I’d encountered that would give you something that was both measured and actionable. The questionnaire you can basically reframe the questions as things that you could try to fix.
The seven dimensions of organizational learning, I’ll just say them but they’re in presentations on SlideShare or some of the other videos you can watch online. It’s continuous learning, inquiry and dialogue, the team learning together, empowerment, embedded system, which is probably the most vague of their dimensions but that is to what extent does your group adopt models and jargon that they can communicate in more dense manner about their own systems.
Coté:
Right, that’s interesting. It’s like their own can’t.
Andrew Clay Shafer:
Yeah, exactly. Inside of Pivotal we have words that mean something to us but they don’t mean things outside of Pivotal. That’s true of basically every company I worked at that … That’s just natural evolution of … In some ways its tribal signaling at well. Then system connection is how much the different pieces of the organization are connected to each other and able to have feedback loops with each other. Then the last one is this notion of strategic leadership which is how much the empowered executives are able to recognize the dynamics of the internal, external system and drive change into the organization. Those are all from the ’90s, so this is research I dug up and I just got really interested and read a bunch about the … I try to drag it back into the DevOps narrative and I did some presentations of velocity and some agile conferences about it. I really think it’s a great way to frame things.
Just to dig some of the … I pulled up one of the presentations really quick and this is a little bit of a framing just so people can understand what I’m talking about. These are some of the questions that are on the Watkins and Marsick questionnaire. Here’s one and you would rate it from one to 10. In my organization people openly discuss mistakes in order to learn from them, one to 10. In my organization people identify skills they need for future work tasks, one to 10. In my organization people are encouraged to ask why regardless of rank. In my organization groups focus both on the group’s task and on how well the group is working. In my organization … My organization builds alignment of visions across different levels and work groups.
There’s a long list of these, I won’t read all of them, but that’s just a flavor for what they were trying to frame and then this dissertation I first started getting on this thread was he’d apply this model and ask a bunch of questions and then was correlating it with retention and job satisfaction and a bunch of other metrics with those people. He was arguing that the higher degree of organizational learning measured with the seven dimensions meant that you had better retention, a bunch of other things were better, so they’re highly correlated with organizational learning.
Coté:
Which as we have discussed previously means you can sleep well at night, ultimately. You’re refreshed in the morning and get your lattés.
Andrew Clay Shafer:
If you’re good at this you get to sleep a little more.
Coté:
That reminds me of one of the things that I’ve noticed about the advice of being a continuous learning organization doing continuous delivery and DevOps and agile and all this stuff is there’s this in contrast to people or organizations that are not that way there’s a manic self-awareness and, to use a phrase, mindfulness. There’s always this … People who practice all this stuff that we’re talking about, or at least talk about it, they almost take for granted that when you’re doing your day to day work you’re always observing it and figuring out if it’s operating correctly. It sounds a little ridiculous after we’ve gotten this far to say you should be continually monitoring if what you’re doing is the right thing to do.
Andrew Clay Shafer:
Right.
Coté:
But having worked in many organizations that would probably answer all … The answer to all of those questions would be can I give negative five as an answer. It’s no longer shocking but in fact it’s more expected that most organizations, they don’t have that culture of being very self-reflective and mindful about things. It’s almost as if they’re just trying to get to the end of the day and they’re not really thinking about engineering the organization.
In some cases that can be fine for a short amount of time but if you’re an environment like we’re in nowadays, where basically the business mission is figuring out a new way to do business before your competitors do and cream you, then it’s pretty good to be mindful and reflective about what’s going on and not just sit there and do the same thing over and over again. I think that’s one of the biggest challenges. Again it supports why culture becomes the conversation, if you will. But the last thing I wanted to ask, and I ask myself this continually and written things about it, one, is it realistic to ask organizations to change? Two, have you actually seen organizations change? Is there evidence that change can happen?
Andrew Clay Shafer:
Wow. I think there is evidence and people do change. I think that there’s also a tendency, part of it comes back to hubris, to claim that you’re changed when you’re not. To claim yeah of course we’re DevOps, of course we’re agile, when in reality you change very little. It’s just a fashion show or a … It’s the spring fashion, you want to wear what everyone else thinks is fashionable. In general the Darwinian forces of the market, and especially when you look at the quickening that we’ve already referred to, I think you don’t have to change. To quote Demming, I’ve used this many times before, survival is not mandatory.
But you do see changes you see some … I worked with people who made fantastic changes. Certainly my ideal, this archetypical platonic ideal of how to do some of these things, is very rare. But that’s okay. If you go to places … You look at what’s going on with Velocity, the DevOps Summit, GKINDA? you’re seeing all sorts of transformation across these industries where people are looking for better ways or they’re in a position where they feel this Darwinian pressure. These existential crises where if you don’t change what you’re doing then you’re not going to be able to do it, you’re not going to be able to do maybe anything, really motivates people.
There’s not … No one’s entitled to their business model. You look at the Fortune 500, you look at the churn in the S&P and Dow or whatever, people are not going to be around, they’re not going to be able to maintain whatever position they’re in because change is inevitable. If you’re not going to become part of whatever the new normal is then you’re always susceptible. We’ve seen lots of these stories where Uber has I think a $40-something billion valuation right now and the flipside of that is there’s been, at least the last thing I read, a 60% drop in the taxi fares in San Francisco. There’s more Uber in New York City now than yellow cabs.
Coté:
Those numbers just keep accelerating. It’s pretty clear being in the taxi industry is not cool at the moment.
Andrew Clay Shafer:
There used to be Blockbuster. You used to go rent videos at Blockbuster. Now that’s not the world we live in. If you don’t recognize that these things are changing and you’re just going through the motions you can have a really hard time. I think it’s interesting, particularly in the segment that we’re in, that you’re seeing a number of these, and they’re multi-billion dollar companies, going private with leveraged buyouts taking them private so that they can try and reinvent themselves and get back in the public markets. There’s just no way they feel they can make the kind of changes that they need to change under the scrutiny of the way our current markets reward you for behavior.
Coté:
That’s a interesting way of looking at going private, if you will. It’s almost will let you have an optimistic way of looking at it is that these, as we used to call them and if I remember the late ’80s, these masters of the universe. People with big bags of money or people who can get big loans to get big bags of money, they’re optimistic that they can take these beleaguered companies and take them off the market and fix them. Which … That’s a judgmental way of putting it. They can modernize them and make them more valuable by applying new ways … New business ideas and new technologies and things like that. Which is a lot better than just giving up. It means it’s possible to survive. That’s good stuff.
Andrew Clay Shafer:
There’s a bunch of ways to frame it. I think that the optimistic way to frame it … A lot of times it’s not the … If you look at stuff that’s going on, Dell, which is something you have some familiarity with, TIBCO, Informatica, all these things have gone private recently. I think that when you see leveraged buyouts sometimes it’s people cashing out and getting investors and that kind of stuff out of the process. Then at least for people like Dell in particular who are attached to that thing, I think they really genuinely want to reframe that business and reemerge as something that is reimagined and part of the new reality.
Coté:
Indeed. They’ve got wonderful signs in the Austin airport that … I don’t mean this to sound snarky but the way that Dell presents itself and talks about itself is a good end state that they’re shooting for. They actually can articulate in tweet link phrases what it is they want to be. Which that … Was it one of the seven ways of awesomeness was strategy essentially? Getting clear on your strategy is actually really hard.
Andrew Clay Shafer:
Yeah.
Coté:
At an organization that level. It’s nice that at least in their banners in the airport that they know what’s going on. I’ll give you another example. Back when I was an analyst one of the companies I liked to follow was SUSE and Attachmate and Novell by implication. I always thought it was … Because SUSE as an independent … SUSE as its own unit was very free about its momentum and revenue numbers and things like that so you could rate it on that. It was interesting that once Attachmate bought Novell, and so Novell goes private and SUSE is owned by them. To use a phrase they use in the M&A world, the masters of the universe there were pretty good at unlocking the value of SUSE. Their revenues immediately started going up and up once they were fixed, to use that word.
Andrew Clay Shafer:
It turns out running a business is … It requires running a business.
Coté:
Exactly. It is. I think that’s a good framing to look at going private. Sometimes it’s just a financial thing which … We all like money so congrats to those guys. But hopefully what we more shoot for is it’s an opportunity to have a company survive Demming’s faint praise.
Andrew Clay Shafer:
Thrive.
Coté:
Exactly.
Andrew Clay Shafer:
You want to thrive. That’s really … If I could put anything on what DevOps is about it’s about thriving. It’s about making those cultural changes, taking advantage of the best possible tools, so that you can not just compete, you can not just survive, but you can thrive. I just want to point out one more thing because you just used the word snarky and we had this discussion earlier about snarkiness in the DevOps community. I wanted to point out this study we’ve been throwing around in some of the other circles I participate around where sarcastic people are proven smarter.
Coté:
That’s right. Also cures cancer I think. I’d like to just add that in. Or it might cause cancer, I don’t know. Probability is either way.
Andrew Clay Shafer:
I’m just going to double down on sarcasm is what I’m saying.
Coté:
That’s right. You can just send that link to anyone who replies. That would be … Nothing goes better with a stiff cup of sarcasm than a shot of passive aggressiveness.
Andrew Clay Shafer:
Get on this level.
Coté:
On that note, this has been another exciting Pivotal conversation we’ve had. If you want to get to the show notes of this episode or check out all the other Pivotal podcasts that we have, you can go to pivotal.io/podcasts. That will send you to a listing of all the stuff that we have. We’ve got a lot of great things going over the cloud platform stuff that we have, the data products, all over Pivotal. Also as this is I think the fourth episode, so far all of the long-term listeners who have been around, we’ll be back next week or around that time with another discussion of how to start thriving.
Andrew Clay Shafer:
If you made it this far, thanks for listening.
Coté:
Indeed. We’ll see everyone next time.
Andrew Clay Shafer:
Adieu.
About the Author
