Neurodiversity and the Essence of DevOps – Jeff Sussna

Neurodiversity and the Essence of DevOps – Jeff Sussna


[applause] I want to really sincerely thank the organizers
for bringing me over here. It’s great to be in London. This is a topic that’s near
and dear to my heart. I was honestly a little overwhelmed when
my talk submission was accepted. Thank you very much
for your vote of confidence. Typically, I work very hard to craft my talks,
and rehearse them, and make them as tight as I can,
and this one has been eluding me a little bit. It’s much more personal than
any talk I’ve ever given. I’m a lot more nervous than
I’ve ever been giving talk before. I’m not actually going to guarantee
that it’s going to hang together. If I stumble my way through the next half
an hour, please bear with me. I think we’ll just have to see what happens. My personal DevOps journey actually started
many years ago when I read a single paragraph in a book about AI
by a guy named Norbert Wiener and this thing
he was into called control theory. I didn’t think very much of it at the time,
I just kind of went on with my life. Fast forward, 25 or 30 years, I was in the library one day looking
for something to read, and I saw a book on display called
Dark Hero Of the Information Age. It was a biography of Norbert Wiener. I thought, “Oh, I remember that guy.
I should find out more about him.” That turned out to be a really big mistake because I became instantly captivated
with the whole idea of cybernetics. The idea of control as adaptation
and listening and allowing yourself to be influenced by the thing
that you’re trying to control. I began to see cybernetics
everywhere I looked. In particular, I recognized it as the common
underlying foundation behind Agile, and DevOps, and Design Thinking,
and Lean Startup. I found it so compelling that I ended up
writing a book about taking a radically cybernetic approach to the whole
prospect of digital transformation. Along the way as I was reading everything
I could get my hands on about cybernetics, I encountered one of the most interesting
people working with it today, Paul Pangaro, and through him,
his student, Seung Chan Lim, who had written a book called
Realizing Empathy. In it, he talked about how
he had first encountered empathy while taking a furniture-making class
when his teacher explained to him that he couldn’t just hack at the wood
to try and make it do what he wanted. He had to actually listen to what
the wood was telling him about how it wanted to be worked with. Because I have this habit of making
strange and unexpected connections between things,
I saw this as a metaphor for DevOps, both the relationship between Dev and Ops
as well as the relationship between people and the systems
that they were trying to control. About four years ago, I started speaking and talking
about the idea that empathy was really the essence of what DevOps is. A remarkable thing happened. The community grabbed hold
of this idea and ran with it. Very quickly, it reached the point where
you couldn’t go to a DevOps conference, you couldn’t have a DevOps conversation
without talking about empathy. I think that’s a really wonderful thing.
I think it’s something we should be really proud of. When you look at our industry,
you might not expect us to be the folks who make empathy the center
of an entire fundamental approach to organizational design,
but I think it’s something that we really have to offer to other disciplines
as an example of how to approach all the stuff we’re trying to do. I think we really should feel like
we’ve accomplished something special and remarkable in what we’ve done. That being said, we still have work to do. Empathy is hard. We always tend to fall back on our habits. I was at an Agile Software Conference
this year and there was a keynote about empathy and got very excited
empathy, yay empathy, yay us, until the speaker made the comment that,
“Well, you all have the capacity to empathize except, maybe,
people with autism.” I found myself getting very upset
by this for a couple of reasons. The first is that it turns out not to be true. We can thank Simon Baron-Cohen, Borat’s cousin, for the idea that an absence of empathy
is the defining characteristic of autism. Researchers have shown that
to not actually be the case. That if anything, we empathize
more intensely that neurotypical people do. As a result, we tend to get overwhelmed
by it and start to shut down, which is why it may seem
like we don’t empathize. The second reason I was upset is,
you may have noticed I’ve been using the word we, and not they. As a person who is myself
on the autism spectrum, it was difficult for me not to take her
comment personally. The irony was that I was empathizing
with her talk really intensely. There were a few momentary
glitches along the way. It wasn’t a big deal,
it didn’t detract from her talk. It was the kind of thing
that happens to us all the time. You’re going along and all of a sudden
you realize you’ve no idea what you want to say next,
and you freeze for a minute. Then you remember and you go on
and everything’s fine. I was experiencing those moments in her talk
as if they were happening to me. If autism is not defined
by an absence of empathy, what is it? Well, that’s a tricky question because
it involves a whole constellation of characteristics and experiences
and no two people have exactly the same combination. That’s why sometimes
you may hear the saying that, “When you’ve met one autistic person,
you’ve met one autistic person.” What I’ve noticed is that the world tends
to view it in general as something missing, as a lack of something. Whether it be a lack of empathy,
or a missing protein in our genetic structure, we’re not getting enough oxygen while
we’re being born or whatever it might be. I think I’ve only ever encountered one study
where researchers were trying to figure out why is it that autistic
people are better at this particular thing. The irony is that because of our very struggle,
in many ways, we are actually more capable, not less. One of the things we tend to share is anxiety. If you’re on vacation,
and you’re at the beach, and the sun is shining, and your phone is off, your anxiety level
is probably somewhere around zero. Where for us, it’s more like three or four. That can make seemingly simple,
ordinary activities a lot harder. One of the ways that my anxiety manifests
is in navigating physical space. In Minneapolis where I live,
we have something called the Skyway System, which is a series of enclosed walkways
that connect the major downtown buildings so that in winter, when it’s 30° below out you don’t have
to go outside in order to walk around. Well, I don’t use the Skyway because
I get very quickly lost and panicky. It will be snowy and icy out and I’ll be down
on the sidewalk walking around outside. I once had a job working in a building that
was shaped like a very long and shallow ‘W’. It was really easy to get turned around,
and you could literally walk to the wrong end of the building before
you realized your mistake. You could leave early for a meeting
and end up showing up late. My first three weeks at that job
were one continuous panic attack. Every time I went home, every day,
I literally wanted to quit. I had to force myself to go back
to work in the morning. I didn’t quit, I persevered. Eventually, over the course of several weeks,
I started to figure things out and I started to settle down and feel more comfortable, Imagine that you run six miles
to work every morning. Where your office is at the top of a steep
mountain and instead of driving, you hike up and down with a backpack,
50-pound backpack on your back. People would think that you’re pretty remarkable,
“Wow, look at at that, they’re amazing. They run six miles every morning and then
they do a full days work like the rest of us.” Well, that’s what we do, just showing up. Every day in our ordinary lives,
we demonstrate a tremendous amount of courage, and commitment, and determination. Not only, it’s not just a matter that
we should be admired for our ability to navigate our ordinary lives, we actually have
a lot to contribute and a lot to offer to neurotypical people
and to the world at large. When we talk about things like accommodations,
there’s this subtle idea at play that, “Well, we’re fine. You can’t quite handle things,
so we’ll accommodate you.” Oftentimes when you do things
to accommodate autistic people, it actually can make things better
for everyone. For me, things like televisions, and airports,
and open-plan office spaces are a nightmare, but lo and behold, now we’re finding out
that open-plan office spaces are a nightmare for everyone. Imagine if we turned off all the televisions
in all the airports and suddenly we weren’t being constantly bombarded
by the latest natural and political disaster while we’re waiting to get on the airplane. I’m willing to bet that we all might be
just a little bit more relaxed, and a little bit more mindful,
and a little bit more kind. Now, I’m not actually here to give
a talk about autism. What I want to do is explore what empathy
for the autistic experience can teach us about empathizing
with each other in general, in a deeper way. The key thing that I want to explore
is the need to beware of assumptions. Any time we believe that we know something
rather than leaping to draw conclusions from it, we could instead use it as an opportunity
to question ourselves. For example, don’t assume
that what you see is what you get. When you experience resistance,
or grumpiness, or lack of engagement to the new thing
that you want to introduce, don’t assume that it means
the person doesn’t care, or they don’t get it, or they’re not interested
in making things better. Don’t assume that you actually know more
than they do or you are wiser than they are. When you explain
how containers and microservices are going to solve all the problems,
and the answer you get is, “That sounds like an operational
nightmare to me.” Well, they might actually be right. You might want to incorporate
that into your thinking. Don’t assume that just because somebody
has been doing something in a particular way for a very long time that they can’t do
things differently under the right conditions. I have had the very humbling experience
of introducing flow-based work management to teams that have been working in silos
with queues and ticketing systems for decades, and some of them are only a few years
or even a few months from retirement. I’ve assumed that it would be a long and
painful process, a little like pulling teeth, and then I’ve been very pleasantly shocked
to find out that after a few weeks, I don’t even need to go to the stand up
that I set up because they’ve figured it out. They’re actually doing it right. They’ve understood the essence of what
I was trying to teach them very, very quickly. Now, the reason that
we have these friction points is because we’re trying to make things better,
and that’s wonderful. It’s what we do.
It’s actually what our industry is about. Every time you write a line of code,
every time you deploy that line of code, you’re changing the world
in some very small way, but we need to realize that there’s actually
no such thing as things by themselves. Whether that be systems,
or processes, or methodologies, separate from the people who operate
those things or live within them. We need to be careful in how we use language
and not talk about people as if they’re things. When we say things like, “Well, cab is waste.
We should get rid of it.” What about the people on the cab?
What about the change manager? Are they waste too? I become more and more careful
about how I use that word, and I’ve actually started not using it
at all and instead talking about delay, and work in progress, and handoffs. I recently met with a prospective client. He was showing me around his office, and at one point he stopped and very proudly told me
that this is where our DevOps team sits. I had to bite my tongue and keep from saying, “Well, you failed the first test because
we all know that if you have a DevOps team, you’re doing it wrong.” It’s not the kind of thing that you want to say
when you’re trying to get work from someone, but when he explained to me what it was
that his DevOps team did, I realized that if he had said,
“This is where our SRE team sits,” everything would have been fine. Sometimes it’s just a matter of perspective. Some of you may remember
the NoOps controversy. Nearly all the things the NoOps
was telling us we should stop doing were good things not to do anymore. I think the controversy arose because
what we unintentionally communicated– I’m going to make you wait for this one. [laughter] -What we unintentionally communicated
was the idea that we were so excited about declaring a whole class of people
dispensable in getting rid of them that we came up with a catchy name for it. When people ask how it is that Netflix can move
so fast, they point to trust and freedom. They can trust people because
they hire the top 1%, Now, aside from that being just
a little ironic because it’s not scalable, the more important question is,
“What about the other 99% of us?” Whether you’re talking
about the top 1%, or the 10Xers, or the gurus and rockstars, or even just the idea
that the way to innovate is to put a bunch of smart people in a room
and let them solve problems together, if we’re struggling, does that mean
that we’re just too dumb? If software really is eating the world
and if every company really does need to become a software company, that means that we need all 100% of us. So, what’s the alternative? The alternative is to seek
the wisdom in everyone, to assume that everyone we’re working with,
everyone we’re trying to bring along, everyone we think might be in the way
has some kind of intelligence, experience, thoughtfulness, something
of value that they can contribute that we might want to figure out
how to leverage and incorporate. There’s a wonderful story in the news
recently about a grocery clerk whose job was to stock the beverage
cooler in the supermarket. There was a customer who was autistic
who would come into the store every day and just stand
and watch him stack the cooler. He was fascinated by it. Instead of calling security,
or telling the guy to leave, or laughing at him, or just ignoring him, what he did was
he got him to start helping stock the cooler. He assumed that behind this seemingly
weird behavior was something of value, something to contribute. The bonus was that this autistic
person’s family was so thrilled that someone had treated their son with some level
of respect, and dignity, and interest that they started a fund
and raised enough money to send the grocery clerk to college. We work in an industry, and we live
in a society that’s become obsessed with the bid and the grandiose.
The billionaires will save the planet. The unicorn companies
that will disrupt how we walk, and drive, and sleep, and eat, and think. We tend to lose touch with the value
of the simple, and the small, and the seemingly ordinary. In Agile and DevOps,
we talk about making things smaller, but we seem to struggle with the idea
of making our vision smaller. We don’t understand how that
can work to get us where we want. This is the Robie House. It was designed by Frank Lloyd Wright
around the turn of the 20th century. When it was built, it was considered revolutionary
because the roofline is almost perfectly flat. This was in an era where most houses
were still Victorian style. They were tall, skinny, and pointy. If you look at Frank Lloyd Wright’s work
during the 10 years leading up to this, he started out designing tall, skinny, pointy houses like everybody else
and then he made it a little flatter, a little flatter, a little flatter until
he reached the ultimate expression and invented a completely
new architectural style. I hear people say that incremental
innovation isn’t enough. We need breakthrough innovation. I want to challenge
the real difference between them. To me, the difference is simply that
you don’t stop making one small change or experiment after another. The other problem with this big visions
is that people tend to get left behind. You either get cloud-native or you don’t. Not all of you will make it through
this transformation. Survival is not mandatory. Now, on the one hand,
we live in the context of companies, and organizations, and systems,
and ways of doing things that continually come into and out of being,
but on the other hand, ultimately, and to our credit, I think one
of the things that the DevOps Community has understood is that it comes
down to people. In most industries when there’s a major
disruption, there’s some assumption that we have an obligation to figure out
how to bring people along through that disruption and figure out how they can take
their ordinary wisdom and capability with them from the old
world into the new world. We need to ask ourselves whether we have
a similar obligation not just to design for change but design for the adoption
and the adaptation of that change. If we are going to truly build empathy deeply
into how we go about our work, it’s not just some thing or some state
that we achieve and then we can say, “We have an empathetic org chart,” or,
“we have empathetic stand-ups,” or whatever the case may be. It is a never-ending and never complete
process of asking questions and becoming more and more open. To do that, we need to bring curiosity with us,
what is behind that resistance? What is the insight that I might be missing?
What do they have to offer? We need bring humility along. What is it that they understand that I don’t? We need to realize that there’s no such thing
as a full-stack human being. Most importantly, we need the willingness
and the ability to listen. Agile and DevOps are all about feedback loops,
but it’s amazing how many times I work with clients that are really good
at collecting feedback, but they don’t really do anything with it. They don’t really allow themselves
to be changed by it. Often in my work, I encounter teams that are at loggerheads
with each other and somewhat times what I do is I lead them through a mutual
listening and joint design exercise where each team will have a certain amount
of time where they can talk about what they need,
about what’s frustrating them, about the relationship,
about what isn’t working. The other team is asked to just listen,
no interruptions, no questions, not even note-taking,
to just openly and receptively listen. Then we flip it. Each team has the opportunity to talk
and each team has the sense that the other team has at least made
the effort to listen to them. What I find often is that something magical
happens when they start trying to solve their joint problem together,
which is that instead of saying things like, “Well, we need you to do this
so that things will work better for us,” they start saying, “Well, we need to change this
in order to make things better for you.” When I was preparing this talk,
I ran across a quote that at the time I thought perfectly expressed
what it is I wanted to say today. This is from the 1985 Apple
to Human Interface Guidelines. Where it says interface and program,
you can just replace that with anything you’re trying to change; Agile, or DevOps,
or using Jira or getting rid of Jira, or doing scrum or not doing scrum,
or whatever it might be. You must remember that
you are dealing with a human being and tailor your interface to deal
gently with the kind of fears and anxieties that the very existence
of your program may provoke. I think that’s very true.
As I thought about it more, I realized that there’s a subtle
assumption at play here. The assumption is that we’re smart,
and we’re strong, and we’re knowledgeable, and they’re weak,
and they need us to be kind and gentle. I think we actually have to go beyond that. We have to learn to respect people’s struggle, whether it be an autistic person struggle
to find their way around the building, or a VM where administrator struggle
to understand containers and bare metal for its own sake and not try to get rid of it
or overcome it too quickly. To recognize that there is strength, and power,
and value, and courage in the struggle itself. The truth is that we all struggle. Facebook and Twitter are struggling
with monumental unintended consequences way beyond their ability to predict
and way beyond their ability to control in any traditional fashion. One of the things that DevOps
has taught us or taught me, at least, is that the sociotechnical systems
that we’re managing are complex now, not complicated. They can’t be modeled, or predicted,
or controlled the way we’re used to controlling and managing systems. The truth is that we never know exactly
where we are or what we have. In a sense, we’re all lost in the Skyway. We’re not sure where to go next. Even if there’s a signpost telling you where to go,
you can’t guarantee that when you get there, it will still be where you want it to get. In closing, one of the things that I’ve heard more
and more is the idea that DevOps is bigger than Dev and Ops. On one hand, I think that presents us
with a bit of a naming problem. Is it DevOps or does it have to be Dev sec Ops? Even worse than that,
if we go to designers and say, “Hey, designers, you should do this cool
DevOps thing. It’s really awesome.” They look at us and they say,
“Well, I’m not a developer. I’m not in Ops.
What are you even talking about?” NOn the other hand whatever we call it,
I think ultimately what we’re talking about is building curiosity, and humility,
and the willingness to listen and respect for all of each other’s ordinary wisdom, and value,
and insight into the fabric of our work. If we can do that, then I think we truly have something that we can be really deeply proud
of and that we can offer to the rest of the world in terms of how to approach thinking about work in the 21st century. Thank you very, very much. [Applause]

Leave a Reply

Your email address will not be published. Required fields are marked *