Yes, it could take a while. I’ve been in IT infrastructure operations for I think 35 years but at some point you stop counting. When you're young, you brag about how long you have been in the industry. When you get older, you round down. So I'm in the round down phase.
I started out actually in the mainframe world at Exxon, running operations and infrastructure there. It was mainframes back then, IBM mainframes. But skip forward, the recent journey probably started when I was early at Chef, I was the ninth person at Chef. I helped create and build the customer facing business there. That was a lot of fun because I had worked at a large enterprise legacy and this was a nice introduction to open source and cloud and I had done some previous cloud work. That led me into a couple other interesting things.
Actually while I was at Chef, this crazy man over in Belgium run this conference called DevOps Days. It was actually one day and I was fortunate enough to go there. I was the only American at the first DevOps Days conference and it felt like everything I had been doing in our industry was now correct. It was about 35, 40 people who all felt the same and we all spread out into the four corners of the world. Lindsay Holmwood went to the Sydney and a bunch of people up here in the UK started and I started, along with Damon Edwards, the first DevOps Days in the US.
Skip ahead, the last couple of years have been good to me. I had a company that I was a principal sold to Dell called Enstratius and, as you pointed out, about a year ago last week, I sold the company called Socketplane to Docker. So I have been at Docker, I'm director of ecosystem development. I do business development at Docker.
2. What does a director of ecosystem development do exactly?
Business development. I help, as you can imagine, a lot of companies that are integrating with Docker. So I spend a lot of time with a team of about four people helping people understand how to integrate correctly, in what ways, how to build images, how to get images correctly into our ecosystem, into our [Docker]Hub and those things. If you come to us, we'll help you to write APIs and then we try to sherpa you through our system. So I have been in that group for about six months and it's about building process around helping people understand how they can help us, how we can help them.
3. Do you have some strict guidelines for that or it's more per case basis?
This is kind of good bonus material. Yes, I mean what we tell people is it's really easy, easy peasy. On our website, there is a partner tab right on docker.com. You select it, it’s a quick click through. It gets you registered as a partner with us, we call it a member partner. At that point, that's where we kind of start the engagement. I would then actually schedule a call. I'd bring in some of my guys to go ahead and do a little deep dive on it. And then we walk you through what we call ecosystem technology partner which is kind of a categorized version.
There are different categories: network, security, ... You could think of all the categories. I think we have 29 categories right now and we put you in that category and it's a higher level certification. It really means that we mutually feel - the partner and us - that we are consistent in the way we think and what the market looks like. That's when we start working with you more aggressively. It's easy to get started. The best way to get in the system is just registering.
Yes. I mean easy answer is all the above. If you think about it Docker, as an organization called Docker, will be three years in April or maybe late in May. Sometime pretty soon, right? Pretty soon we're three years old. That's pretty new. Docker is already a brand name, in the IT industry it's like a Coke, a Pepsi. You can't walk to anybody who does IT who doesn't say "Oh, Docker yes."
Something that is only three years old. I have only been there a year, right? But I have been watching this phenomenon pretty closely like a lot of us. The first year, they had no idea that it was going to be this explosive, right? They take a technology which is a public PaaS which was DotCloud. They do this form of a pivot and they put out this thing and they believed that this is a rock solid way to do infrastructure. I can't imagine anybody really understood what was going to happen in that first year.
Couldn't predict.
So the first year is really just about settling dots. The next year is about trying to understand your market. This is my opinion, right? Again because in the first two years I wasn't there per se. And then I think if you get to the understanding your market, this is what other companies take five, six years to do. Two years to settle dots, two years to understand your market, two years to actually try to answer the market. So I would say in my opinion the third year, this last year, we're going to say 2015, was about answering the market.
You know I hear people say “well Doctor doesn't really understand security”. These are things that were written back in 2014 and again I think if you really had to assess the three years, you would say second year was a company who tried to understand the market and this third year was a company trying to address it. So a lot of things like you said are security, a lot of emphasis in 2015 on engineering and solving a lot of these security problems. We are addressing a lot of really cool stuff.
Well, it's a two-part question, right? Part of that question is we are seeing a major shift in compute workloads. We have been living in a classic virtualized workload. That's not going away. You go to a large enterprise in the US and a lot of them still run Cobol, IBM mainframe applications. A lot of those are probably not going away in my lifetime. Virtualization is not going away. There are robots, businesses where there's no ROI to change it. But greenfield and brownfield workloads can almost all be containerized. I mean it’s a bold statement but I think in web scale new workloads are just containerized.
In enterprise, a lot of the current shift in thinking is greenfield should be on some form of containerization. It hasn’t quite made that transition but the point is, the answer to that first question is there are shifts in workloads. So a lot of what's happening now is Docker delivering robust architecture solutions that will fit those kinds of new workloads. Which means not just containerized workloads but robust orchestration. So we have recently announced something called the Docker Data Center which concludes our suit of orchestration which is Swarm, Compose, Machine and the Docker Trusted Registry.
And now this is our kind of offering of a license for an enterprise cadence. If you think about our open source deliveries, every other month we deliver a new version. Now we have got a suit of software that's enterprise where we have - I don't know the exact case but like six months cadence of release cycles and it is very catered to an enterprise, by pattern. So part A is that the workload shifts.
There was a second part to that question, a kind of roadmap. I think more of the same: more security, more robustness, more robust in the orchestration that we're delivering now. If I talk about year two being a discovery, that was just a general discovery: enterprise, web scale, a lot of the open source feedback. I think - again, in my opinion - 2016 will be a lot of discovery of the enterprise. Now that we have a DDC, the Docker Data Center, we're going to be hitting a lot of enterprise sites with this new commercial offering. We're going to get a ton of feedback, the feedback groups are going to be very positive. And so I think, just as we’ve seen the open source offerings get extremely robust in 2015, we'll see the enterprise solutions get very robust via feedback loops.
Manuel: Are there any other enterprise concerns, besides the orchestration architecture, that you think might need to be addressed? You mentioned more security.
You know, containerization in the enterprises is a nascent space, right? So it's improving across the border and it's listening to the enterprise. We have got really good traction with the enterprise now and just listening to them, adjusting.
The nice thing about an open source company that works – again, these are all my opinions -- that delivers a commercial offering for enterprises is you still have that flexibility and agility like an open source. So if you're a staunchy legacy software vendor, you're just not tooled to deliver software. Now, if we are listening to our feedback loops correctly in 2016, from the enterprise, we won't be like our competitors that actually live in non-agility, non-software delivery, with software engineers that are not used to every other month cadence of delivery. I think our feedback loops in delivery are going to be much tighter.
Manuel's full question: If I may change a bit subject, your talk here at QCon is not technical at all. You are going to talk about a really important issue in our industry which is burnout and in particular how we're seeing an increase in suicides due to burnout. Why do you think the stress levels are going up like that and shouldn't in theory the propagation of DevOps be helping reduce stress and make delivery more frequent and things like that?
Yes, this is an interesting conundrum. To give a little back story, early 2015, there is a conference out of LA. I have gone six years in a row now. It’s called SCALE, it's a local regional Linux user enthusiasts conference. I think it’s the largest US regional Linux conference. I have been going for many years every year you get to meet people, you go to the same conference. Sometimes the only place you meet them is at that one conference.
And there is this young man about three or four years ago, Carlo Flores. There was something about the kid that I liked. I'm not doing a post analysis, I mean everybody felt this way about the kid. I met him because I was pedaling Chef and he was a Chef user. He was big in the DevOps community -- LA has a really robust DevOps community. And then two years ago, I remember having a great conversation. He was thinking about doing a start-up and I, like I do with anybody, gave him all the do’s and don'ts of startups, make sure you do this, don't do that, etc. I show up the next year and I find out he has committed suicide.
I look at his tweet stream and he was crying. You could see. I had two other incidences of people who committed suicide. One I don't really know why, the other I know -- actually the other one was not suicide, was somebody completely left the industry for burnout but also had said in a public presentation they thought about committing suicide because of burnout. It really destroyed me. When I was in the room, it was an open session of the DevOps track, and I walked out. I was crying, I called my wife “I need to come, I don't want to be here”. I lost it. I stayed at the conference and I wrote a blog article and the reaction to that article was insane. Hundreds of emails within days, phone calls, 1500/2000 tweets of the article and it was just resounding.
In my presentation, I used the Edvard Munch picture, which is famous. It's called Red Virginia Creeper and it's a house being strangled by fire. And I think that, my God, our industry… I knew I was blown away about this one young man and my experience with the two other people. But I had no idea our industry was so pent up. Even over the last year, at conferences, people tell me “John, I've read that article and I'll tell you a story” and it’s people that we know are famous in our industry, young people, and I realized that this is serious stuff. And so I was asked to do a couple of keynotes at DevOps Days. It was cathartic, it was like my plea in the article and my plea in the presentation was “if you're out there, call me”.
So yes, we have a problem and I think there’s two sides of the DevOps story. Yes, there is the side that there are practices that I think can create healthier organizations, healthier humanity if you will. You know Gene Kim, the author of the Phoenix Project and a good friend of mine -- I'm a co-author of the DevOps Handbook with him and Jez Humble and Patrick Debois --, he always said that the reason he started IT revolution was to help a million IT professionals live better lives.
You think about the classic IT professional that wakes up at 3 in the morning to get yelled at because of something like the classic 90% disk full on an Oracle database. So a database where “yes, it's supposed to be 90% full, I'm going back to sleep!”. But then what happens? You wake up in the morning and the kid is like “Daddy, can you look at…” and you answer “Get away from me right now!”. We, as an industry, we torture ourselves. This IT stuff can be very punishing. So I do believe there are first order principles of DevOps that can make organizational and personal life easier. They can be any patterns or positives against stress. But in general, a lot of us don't do it right. Even though we preach these first order principles of DevOps, the net of most organizations is there are a lot of things that are stressful.
So Randy Shoup, who’s running the “Optimize You” track today, asked me to do a presentation on DevOps, I mean I'm sorry, on burnout. And I was just going to do the same one. And then I wrote the abstract and he's like “by the way, can you add in how to help people?”. Oh my God, that was never the intent, other than I will be the person you can call and I will listen to you for hours on the phone to get you off the cliff. I'll be that guy anytime, anyplace, for anybody that knows my blog. That was the only advice that I was prepared to give. But what I did is I learned a lot over the last year.
And so I'm very excited about this presentation. It's not just a cathartic. It is actually the research that I have picked up over the year. And really good research: statistical psychometric surveys that actually help people understand where they fall in a classic definition of burnout in terms of exhaustion, efficacy, cynicism. These are classic definitions based on the research. So I have learned a lot and I'm going to share a lot of information today.
Yes, I mean certainly we need to be on guard. Like I said I didn't set out to change the world when I wrote this blog article but I will tell you that a pocket of our industry has changed. O’Reilly’s Velocity [Conference] is running now three consecutive burnout tracks and every one said that was because of my article. Even discussions in the tweet stream right now, I see this happen a lot: if you make a flip comment that otherwise would just be considered cynical -- this happened to me a couple of times throughout the year where I said something and I didn't mean it the way it was interpreted but it sounded like I was crying for help -- and I have seen this happen a number of times this year where people were like “are you okay?”. Or a [Twitter] DM [direct message], like “John, is everything all right? I saw your tweet”. I didn't see that happening in 2014.
So answer number one is we need to understand that this is a problem. We need, as a community, to basically not be afraid to talk about it. The first thing you learn from a psychology or if you have seen a psychiatrist -- I can't imagine anybody gets through this life without checking in at least once -- you'll find that the biggest hurdle is realizing you are not alone. You are not the only one. When you hear somebody else talk about it it’s like “oh my goodness, listen to that guy. He looks like everything is perfect and he or she has that problem”. So talking about it, listening, making yourself vulnerable. But here’s the thing that I learned through the research over the years: let's all be on guard, let's talk about it, let's not hide. Tell your stories.
Manuel: Not have the illusion of success, right? Sometimes you think “oh, this person is successful so they must have everything right”.
Yes or just be willing to have an open discussion about things that feel eeky -- who wants to say they went to a psychiatrist. But here’s the interesting thing I found through the research: a lot of it is self-assessment. It sounds obvious but the bigger problem is you have to help yourself. Understanding that you can actually go get clinical health. The right psychiatrist or the professional will actually help tease out these things. There are online self-assessments for burnout, I’m going to talk about these in my presentation. And so I think there is a responsibility for you as a person to self-assess because if you don't know where the stressors come from, you can't fix them.
There is a strong suggestion that people should actually figure out what are the things that stress you. When you actually put it on paper or self-assess, you start identifying them. “I just didn't realize that was something that every other day ruined my day” and knowing that is like: A - how do I get rid of it; or B - how do I deal with it; or C - do I really care. but not knowing that it's a stressor. So the self-assessment I think is a big part. But to the root of your question, there’s Christina Maslach who is considered the foremost authority on burnout. She has created something called the MBI, the Maslach Burnout Inventory, which is a survey that is the industry standard for assessing burnout. Three categories: exhaustion, cynicism and efficacy.
Efficacy: do I feel worth? What's my sense of worth? I'm not talking about it today but there is also, from the same woman Christina Maslach, further research on what she calls the six mismatched patterns. And this is where it gets really interesting. The question is always: is it an individual or is it an organization? Certainly there are toxic individuals and there are toxic organizations. But those are the simple outliers. The truth of the matter is it really has to do more not with “organization bad, organization good” or “person good, person bad”. It’s the misalignment of organizational culture and personal traits or things that are easy stressors to a person.
So the real beauty is figuring out who you are from a personal sense. These six categories include workload -- do you feel that an organization gives you the right level of time or appropriation to do the work that you have? What feeling do you have as a sense of control, sense of fairness? Another interesting one of the six categories or mismatches is community. And another one is values. Here is the thing, this is the beauty of that kind of mismatch. The organizational values and community may fit a group of people perfectly, an organization might be Machiavellian by design and maybe white lies are part of that but you come in, you have got a belief system where no kind of lies is appropriate. If you don't know that mismatch, that doesn't mean “bad org”. It means mismatch.
Another organization might be purely liberal. I mean that in the startup world, there are companies where the CEO is more transparent about that and some are less transparent. So now all of a sudden, it's an organization where everybody kind of thinks the same way and you come in and you got really strong conservative beliefs and that's a stressor. There is a fine line between going to lunch and talking about liberal thoughts and “oh by the way, did anybody see that report the other day?”. Anyway, I'm going to try to dissect this idea about the mismatch. I think the mismatch is the really interesting part.
One last thing, if you look at these six patterns for mismatch, classified and codified by leading psychologists in the field of burnout, those are actually the anti-patterns to team collaboration and DevOps patterns. So it's interesting that what we find is the things that are clearly indicators of burnout are the exact anti-patterns of what we promote in DevOps and team collaboration.
Manuel: We need to do more DevOps.
Again, it goes back to your original question but it's easier said than done. What I hate is the idea that DevOps fixes burnout. We have to be really careful there because the truth is it's the mismatch. One more case to support that -- you’ll never want to interview me again. Netflix, a classic example: they got Reed Hastings as CEO and the famous culture deck. One of the lines in the culture deck is “adequate performance gets a generous severance”. We're not screwing around. It's going to be hard work. If that’s how you work, that’ll be great and we're going to pay a lot of money.
People would say Netflix is a poster child for DevOps. But somebody who gets stressed easily on certain things could go there and really have a tough time. So it doesn't mean Netflix is great. It doesn't mean Netflix is bad. It doesn't mean the person who goes there is great. By just saying DevOps fixes burnout, we miss an important part of assessment which is the mismatch between where this organization thinks it is, how the organization actually lives, how they want to be and how this person assesses to that.
Manuel: So from a management point of view, I guess one way to help is to be transparent about your purpose and how you work. Is there anything else, maybe more at the team level, that a manager can try to do to prevent stressful situations or before it gets to the point of burnout? “We need to go through this, maybe a workload peak or what can I do to make it a bit little bit easier on my team”
You know, there are toxic organizations, there is good leadership, there is bad leadership. There are good organizations with all the principles of DevOps that in general have less stress. One of the things in terms of your manager would be the same thing applied to our community: what can we do to help this community. There are certain telltale signs. Again, I'm not a clinical psychologist. So this is my assessment of research I have done. But “I have got to get out of this industry. This job is killing me”, these tend to be indicators. In broad strokes, one of the categories is cynicism, the other two are exhaustion and efficacy. In cynicism, the end stage, the dark place you get to in a cynicism category is depersonalization. For example, “I just want to do my job, leave me alone”. That actually is an indicator that you’ve isolated in. You are fed up with everybody else in the organization, “I'm just going to do this”.
I think there are some indicators but I think the broader answer is back to assessment. I like Netflix because -- I don't think they deal with it at the psychological level but -- they try to be transparent about “here is how we are”. Adrian Cockcroft on my DevOps Cafe Podcast said that when he was there, if you took an interview and you hadn't read the culture deck, interview was over. It's like our broadcast of “here is who we are”. If you come in here, you better know it.
A lot of companies, like Google has presented some of their team work patterns. Spotify actually does a lot of stuff on their engineering culture. Etsy has Code as Craft. I think that's all great. Etsy is a good example, they're very strong on diversity. So if you happen to be a knucklehead, like “why do we care” – that’s not going to go over well at Etsy. It shouldn't go over well anywhere. So Nicole Forsgren works at Chef now. She's a PhD, he's got statistics. She is performance and operations or operational performance at Chef now but she used to be a teacher at University of Utah. She works on the DevOp survey.
Yes, the Puppet Labs DevOps survey, also with Gene Kim from IT Revolution, they’ve have done the four year survey. One of her specialties is something called psychometrics. Psychometrics is interesting, it's the combination of knowing how to do psychological profiling with statistical analysis. So you can actually apply statistics behind and that's what she has applied in the last couple of years in the DevOps survey. She actually runs an internal kind of psychometric built at Chef and she has talked about this at a couple of conference at least last year, her first year at Chef “sciencing all things” or something like that.
There is a cost of burnout. There are lagging indicator costs: turnover, healthcare. There are a lot of efforts right now to classify burnout in the same category as PTSD because it has the same characteristics. There is health care, there is legal possibilities, and the optics. In the company Carlo worked for, a week later somebody else in the same company, same group, committed suicide. I don't imagine anybody in the DevOps community -- who can get a job anywhere -- is going to work for that company anytime soon. The optics of this happening, you don't want two of these in your company. It's just not going to look good.
Those are the lagging indicators but there is some research that implies that the people who burnout the most are the high performers, your best employees. By the way, there is kind of a ramp to when they go from feeling frustrated, angry, the apathy to actually what would be clinical burnout, that's a journey. During that journey: missed opportunities, not as crisp on the new ideas, maybe a little degradation in what they deliver in terms of their analysis of threat.
Interviewer: [0:34:11] Maybe just the relationship…
John: The relationship. Right, the decay, all that is kind of hidden -- think about the cost of that. Especially when they’re your top people and it isn't like they did something wrong. This is a clinical problem but you don't even know that until it's like “turnover, left the industry”. All goes out the window. If we think this problem is deeper than even what we think it is, there is going to be an incredible cost to it. And so maybe there is an opportunity to be more like Nicole. Hire people or bring in people who stop treating psychology as a dirty word. Let's apply it to our organization and let's find out where do we match in our alignment with the six categories.
So there are six mismatches. Let's figure out through a psychometrics surveying what we think we are, what we are and help employees self-assess to find out how they fit. That's what I'm going to talk about today – a wild speculation: what if in the industry we took psychology more interestingly and less taboo? Maybe the opportunity of what we would get out of that could be really interesting. And really what it could be is if we flip it from “burnout bad” -- what we lost -- to an anti-burnout strategic weapon for an organization.
Manuel: Thank you very much, John. That was very insightful.
Cool, yes.