OK, I admit it. Thinking of Maslow’s Hierarchy of Needs and DevOps doesn’t seem like an obvious connection. But Omed Habib of AppDynamics gives us the connection of how Maslow’s theory applies to developers and DevOps people. Because after all, they are people too, right? Right?
Anyway, this is a great conversation that I think you will enjoy. As usual the streaming audio of our conversation is below and the text is below that. Enjoy!
Alan Shimel: One, two, three. Hey, everyone, this is Alan Shimel, DevOps.com here for another DevOps Chat. Today’s guest on DevOps Chat is Omed Habib from AppDynamics. Omed, welcome to DevOps Chat.
Omed Habib: Thank you, Alan. Pleasure to be here.
Shimel: Thank you. So, Omed, I would imagine most of our audience is already very familiar, at least pretty familiar, with AppDynamics. You guys have sort of become just a huge success in the APM market, though some may call what you guys do not exactly “APM”—I’m not even sure if AppDynamics calls it “APM” anymore—but, nevertheless, company that’s had tremendous amount of success. What’s your role at AppDynamics?
Habib: Well, I originally joined AppDynamics as a product manager. My first couple of years, very proudly brought our PHP, Node.js, Python APM agents to market. And, as of a couple years ago, I joined the product marketing team, so I’m now helping lead the strategy behind all of the outbound product responsibilities.
Shimel: Sure. So, Omed, in simpler times, just three, four years ago, it was easy to put AppDynamics into that sort of APM bucket, if you will, but that’s not necessarily the case anymore, is it?
Habib: You know, the term “APM” itself, like you said, is starting to put into question. What AppDynamics does, at least in my opinion, is very simple. I think what is becoming—the definitions that are changing right now are the processes within the software environments and where AppDynamics plays a role or, rather, where AppDynamics—sorry, APM as a concept plays a role. Historically, we’ve had divided teams, right—operations are responsible for production monitoring, and so they would have the production-monitoring tools; developers had their siloed environments—they would ship their code—and so they had their decouple tools.
But what we’re starting to see now is a shift in runtimes becoming far more sophisticated, and the barrier to entry to production is so much lower now that developers and operations—I’m gonna introduce a whole new term; we call it—it’s not new, but I’m just gonna call it “engineering teams,” “application teams,” are now responsible for the entire software development life cycle of the product, so developers are now deploying code; operations folks are now responsible for not just the infrastructure and the production monitoring, but also they’re starting to look at everything from an application perspective, versus an infrastructure perspective.
The other thing that I’m noticing, Alan, is that we’re starting to see far more abstraction here of the infrastructure and the deployment models of applications. In other words, teams are no longer responsible for spinning up servers and configuring hardware and configuring the specs behind the infrastructure. All of that’s becoming abstracted, and so it’s causing—again, I’m not gonna call it “dev teams” or “ops teams” because I see these two teams merging, I’m talking, five years, maybe possibly in 10 years, possibly even sooner than that, down the line. I’m just gonna call it “engineering teams.” Engineering teams responsible for the application, the product itself.
And I see these roles starting to merge. We’re starting to already see _____ the ops responsibilities. You know, Google’s introduced the SRE role, right? The site reliability engineer. And the nature of that role is someone who comes from a developer background, facing the challenges of operations and the idea behind that is to have a developer mindset of “How much of this can you automate using code?” And so they’re trying to solve—again, it goes back to the abstraction idea, right? Everything becoming abstracted. So what they’re essentially trying to do is automate as much of the infrastructure as possible so that, end of the day, a developer can do what they do best, which is checking code and work on features and work on the backlog.
What we’re seeing today, right now, is the crossroad of development teams starting to take a step back and realize that, “Hey, what the heck is going on here? We have this giant backlog full of features and we’re doing nothing but putting out fires all day long. We have bugs; we have performance issues; we have database issues; infrastructure issues.” Right? So if you were to look at it—[chuckles] it’s kind of funny. I get very Maslowian here, but if you look at Maslow’s Hierarchy of Needs, right?
Shimel: Mm-hmm.
Habib: I’m getting kind of philosophical here, but I got a point. [Chuckles]
Shimel: No, no, go ahead.
Habib: Maslow’s Hierarchy of Needs, essentially, states that everybody, every human with a purpose, goes through this journey, but they have to go through levels, and it starts with the foundational layer, right, into the second layer and a third and fourth layer. But the very top of that pyramid is what they call—what he calls “self-actualization.” And self-actualization is when you, as a human being, as a person, you get to actually do what you were on this planet to do, where you solve for everything else—shelter, security, your social needs, your physiological needs. And so you get to a point where you say, “Well, what is it that I was here to do to begin with?” Right? And so you get to actually work on the things that are larger purpose of you as a person.
Developers, I’ve noticed, are actually going through a Maslowian hierarchy. The very premise, the very foundational premise, of what they do is their toolset—their development environments or sandbox environments, their pre-production environments—and so what we’re noticing here is that developers are starting to go through their own Maslowian-style pyramid, in that the foundation of the pyramid, essentially, is a development team solving for their proper development environments, sandbox environments, embracing a DevOps culture, ensuring a pragmatic, iterative software-dev life cycle, ensuring for proper infrastructure, making sure that they have the proper monitoring tools in place. And so, as they continue to move forward and advance from one layer to the other, they no longer have bugs in production, they’re no longer solving for bad code being shipped, because they’ve already solved for that. Right? The teams that have not are stuck at the bottom of the pyramid, and the teams that have advanced forward are hitting a point of self-actualization.
And so, if I were to draw a parallel with Maslow, I’d say that developers—development teams, applications teams—today, have hit a point of self-actualization, which essentially says, “Well, what are you actually here to do?” And what you’re actually here to do, as a development team, is to work on moving the business forward—work on the backlog, work on the features. And what are those features? Those features come from a road map and have been prioritized, from business strategy perspective. So you’re essentially getting your development and engineering teams back in line with what they were there to do to begin with, which is “Now let’s start to move the business forward.”
From a philosophical perspective, that’s what DevOps was to begin with, right? That’s what developers and operations teams are hired to do to begin with. Unfortunately, because of the lack of sophistication in the tools and the processes, what we’ve seen in the last few decades is that, developers and engineering teams and operations teams, they’ve been stuck in this rut on the first foundation of that pyramid or the second level of that pyramid. And it’s change blindness, right, from a psychological perspective. It’s, when something happens, some kind of change happens, so slowly over time, you don’t notice it whatsoever, and so you start—you eventually start seeing these development teams accept. Unfortunately, they’re trying to accept their roles as, “Yeah, I just fix bugs all day long.” Right? “I just put out fires all day long.”
Shimel: Yeah.
Habib: [Chuckles]
Shimel: And you –
Habib: That’s because you’re stuck at the bottom of that pyramid.
Shimel: Yeah. And you know what? It’s funny you say that, Omed, because I’ve been in technology, oh, 25 years, and so we used to call it “They’re working in the sausage factory, but they really don’t know how we make sausage.” Right? And this happens. I see it in software’s life cycle and supply chain, where everyone kinda does their job but they don’t realize how their job is part of the larger picture. Right? If someone’s just stuffing meat in the sausage machine, in the back of the sausage machine, but they never see what the sausage looks like when it comes out or what it tastes like, it’s very hard for them to imagine or to empathize with the guy who has to eat the sausage. And, all too often, that happens, especially in software development. I’m sorry to say, but –
Habib: Yeah, no, you’re absolutely correct.
Shimel: Yep. So –
Habib: What’s funny is that not only is the pyramid very similar to how software developers evolve, but Maslow also said that, if you’re stuck at any one of the foundational layers or, for example, if you don’t even have the foundation, that actually goes into the symptoms of what a person experiences. For example, if you don’t have a roof over your head and you’re constantly worried about the elements, right, the symptoms of that is gonna be anxiety and paranoia and discomfort, right? Development teams—I mean, you can draw the exact same parallel and say, “Well, if you don’t have a proper DevOps environment, then the symptoms of that are gonna be X, Y and Z,” right? Anything that is lower than self-actualization is gonna have symptoms, and those symptoms, obviously, are bugs in production, application issues, the backlog growing ever so bigger without you actually even touching it, technical debt increasing, so on and so forth.
But it kinda reminds me—when you talk about the guy that works in the sausage factory, it reminds me of the famous story of the three—I might butcher the story, but it’s the three workers that were working on a cathedral. A passerby comes by and asks the first person, “What are you working on?” and he says, “Oh, I’m just—I’m working on this stone and I’m just hacking away at the stone.” And then he goes to the next person and says, “What are you working on?” He goes, “Oh, I’m just working on this wall, and it’s something that’s gonna be used on this home.” And he goes to—and, by the way, all three of them are doing the exact same thing.
Shimel: Mm-hmm.
Habib: He goes to the third person. He says, “What are you working on?” And he says, “Can’t you see? I’m working on a cathedral.”
Shimel: Hmm.
Habib: So, when you’re at the bottom of that pyramid, you lose sight of what you’re doing to begin with.
Shimel: Got it.
Habib: When you’re at the top of the pyramid, a point of self-actualization, right, where you’re supposed to be to begin with, where you’re supposed to be doing what you’re actually supposed to be doing, then you begin to realize the big picture. When you realize the big picture, then, as an engineering team, you are realigned back to the strategy of the business. And self-actualized engineering teams understand not just what they’re working on and how they’re working on it but also why they’re working on it. And with that comes the additional responsibility of, “Well, if you know why you’re working on it, then how do you measure success?” ‘Cause you already measured success at the bottom of the pyramid, for your application, but, if you’re now at the top of the pyramid—and, as a self-actualized engineering team, you’re not just measuring the success of the application, right—performance of the application, the technical performance of it—but you’re also measuring the success of the business performance of your application.
Shimel: Sure.
Habib: And that is what we’re starting to see today. A lot more engineering teams who are moving to the top of that pyramid are now getting reintroduced to having a seat at that table of “Hey, I’m not just a software developer. I’m not just an IT cost center. But I’m a partner in the business strategy behind this application.”
Shimel: Yep. “And I deliver customer satisfaction.” Fantastic. This was a great—great conversation, Omed. Very insightful. Unfortunately, well, we’ve gone way over our time, but we’ll deal with it.
Habib: [Chuckles]
Shimel: Omed, we’d love to have you back on at some point, though, ’cause our audience is so developer-centric and ops-centric too, but “tech-centric,” I guess, is a better word, that I’m sure they identify with this, and I’d love to continue this conversation. So perhaps we’ll –
Habib: Yeah, it was a pleasure chatting with you.
Shimel: Yeah. We’ll find some time and do it—do more of it. Or maybe you wanna write about it on DevOps.com. We’ll talk about it offline. Anyway, Omed Habib, AppDynamics, thanks for being this episode’s guest on DevOps Chat, and thank you for everyone listening, and we’ll see you again on another DevOps Chat. This is Alan Shimel for DevOps.com.
