One of the fundamental tenets of DevOps is that working in closed, departmental silos is counterproductive for creating quality software. Rather, work is done best when groups are composed of members from across the business working openly and cooperatively. Experience shows time and time again that open, multifaceted teams made up of a variety of viewpoints work better than ones that are closed and monolithic.
Yet, when we move beyond the landscape of DevOps into American society, things look different. In his book, “Coming Apart,” published in 2012, author and political scientist Charles Murray makes the following point: Sixty-three percent of the population of the United States—white Americans—is separating into a two-class structure in which one class enjoys an increasingly stable, healthy, knowledge-driven prosperity while the other experiences declining wealth, health and educational achievement accompanied by a loosening social cohesion. This loss of social cohesion perpetuates the continuing decline. And, there is no relief in sight.
Murray points out that while class distinction in the United States is nothing new, what is different now is that these two classes exist in silos that are closed and disconnected. While in the these past classes have intermingled, now each lives apart from one another—so much so that the classes have become almost unidentifiable to each other.
For example, back around 1960, it was entirely conceivable that a CEO of a manufacturing business shared many of the same experiences as the less-wealthy employees of the company. They might go to the same restaurants, watch the same TV shows and maybe even drive the same make of car. Their children might attend the same schools. Today, however, it’s each to his own; shared experience among classes is becoming more rare.
There definitely was a class system in force onboard the ocean liner Titanic. The well-to-do traveled first class, while the poor went down to steerage. But everybody boarded together, and Leonardo DiCaprio’s pauper character had a slight chance of interacting with Kate Winslet’s wealthy socialite—maybe even fall in love and get and stay married. And, when the ship went down, all aboard were at risk, rich and poor alike.
Today, the average Joe flies in a cramped seat in economy. The CEO flies private. The economy flier probably has no idea what it’s like to board a private plane, let alone fly in one. The thought of packing a lunch beforehand to save money while traveling is completely foreign to the CEO. Each lives in a world the other can’t imagine. Again, this trend is not reversing.
What Does This Have to do with Automation and DevOps?
Tech culture is a prime example of this exclusive segmentation and clustering according to class. The average salary of a DevOps engineer is ~$138,000 a year, which puts the profession in or around the top 10 percent of wage earners. And, just getting hired at most tech companies requires a college degree. This is a self-selecting dynamic. Birds of a feather fly together: People who make six figures tend to hang out with others who make six figures. Likewise, people with college degrees tend to hang out with others who have college degrees. If you’re in tech, chances are you do not know many people in your day-to-day life who had difficulty in school, have worked on a factory floor or smoke cigarettes. When you and those around you make money by thinking, it’s difficult to have empathy for those whose muscles ache after spending each day stocking shelves at Walmart. You just can’t imagine it.
Intrinsically, such homogeneity is not bad. The cause for concern is that now, once the boundaries are set, it’s difficult to go beyond them. In the past, the prevalence of shared experiences made moving up into that other, affluent world possible. Today, however, it is becoming nearly impossible. And we in tech are not making it easier. Why? One reason is automation.
Automation replacing human labor is nothing new. It’s been going on since before Otis figured out how to make elevators go up and down between floors without requiring human intervention. Yet, this is simple stuff by today’s standards. As automation becomes more sophisticated, the degree of smarts required to work in an environment in which automation prevails grows. An engineer capable of refactoring a piece of software that does speech-to-text transformation has had significantly more education than a stenographer—which, by the way, is a profession automation is replacing.
Automation is making it more difficult for those with only a high school education be employed. Yes, some sources claim that automation will actually create more jobs. But, how many of these new jobs will require nothing more than a high school diploma? And, once hired, how long will these new jobs be available before they are replaced with another piece of automation?
Now, combine this trend in automation with Murray’s assertions about the growing extreme in class separation. One group is happy, healthy, pretty wealthy and productive. The other group stagnant, poorer, in ill health and continually being replaced by automation. Add in another troubling statistic: The rate of divorce in the happy, healthy, well-educated group is going down. The divorce rate in the other group is going up. (Page 146, Coming Apart, Murray) In addition, the number of single parent households among the less educated group is increasing, while the rate of single parent households for the happy, healthy, wealthy group remains low and substantially less than the other. (Page 159, Coming Apart, Murray). One group has the stability necessary to promote health and wealth in its offspring. The other group is barely keeping its head above water with little hope for better life now, and for generations to come.
What does this mean? It means that things are coming apart.
Probably one of the most important lessons we’ve learned in DevOps is that open systems, genuine accountability and blameless reflection combined with a cross fertilization of ideas between different groups makes for a better, more productive work environment. This thinking can and does go well beyond software. Anybody who has experienced the waste and frustration of a closed, siloed organization understands that open is better. We in DevOps understand the the smarter we all are the better off everybody is. Sharing knowledge and expertise is not a zero sum game.
According to Murray, we are no longer all passengers on a common ocean liner. Today two ships are sailing side by side. One has an able crew with enough supplies and lifeboats for everybody aboard. The other sails along somehow, with dwindling resources and a few lifeboats. We in DevOps are are snug and secure in the first ship. For those in the other ship, the clock is ticketing and the ship is taking on water. Those of us who care about the Big Picture understand that things need to change, that we need to come together rather than come apart. The question, how? This is the question I will leave to you to answer.
I look forward to reading your ideas about how to bring us together in the comments section below.
Abraham Maslow proposed in 1943 that healthy human beings have a number of needs arranged in a hierarchy, which he constructed in the form of a pyramid. The theory suggests that certain needs, such as physiological and safety needs, are more primitive or basic than social or ego needs. The premise is that higher-level needs are addressed only once lower, more basic needs have been met.
By FireflySixtySeven – Own work using Inkscape, based on Maslow’s paper, A Theory of Human Motivation., CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=36551248
A similar path can be uncovered when we map out the evolution of technologies. As technologies fulfill their intended roles, developers pursue greater achievements and solutions to more complex problems. It’s a pattern that exists at every new stage of technological growth as we are driven to satisfy loftier motivations. It’s also happening now in organizational structures as our work becomes more tied to the capabilities of technology.
This progression deserves particular examination in the role that DevOps strategy plays as organizations grow and mature. DevOps encourages a mindset of communication, collaboration, integration and automation among software developers and IT operations, but it can also be swept up by a motivation to go beyond the scope of its basic needs and seek constant betterment. Through this lens, it’s helpful to look at how DevOps culture strives to keep up with the need for a more holistic approach to the end-to-end software delivery life cycle (SDLC), and how it will continue to mature as needs change and evolve.
Physiological Needs
Maslow begins at the base of the pyramid with basic needs. For humans, these needs are physiological, the physical requirements for survival: air, water, food, shelter, etc. To make the analogy in technology, this is the realm of manual processes, where operators flick a switch, crank a handle or spin a wheel. It’s the basic functions of machinery.
The base of the DevOps pyramid is the notion that I have to use software at all, much less manipulate it to fit my business objectives. Not until that basic need is recognized can further development begin to take shape. Initially, Dev teams built applications and passed them to QA teams to test them. The production environment in these early stages got the job done, but at a basic level it lacked cohesion. Teams could harbor mistrust and production environments could become destabilized by poor communication or diverging points of view. Like a simple machine, tasks were performed separately and passed from team to team only after the basics were completed.
Recognizing the need for software was the first step, in fact it’s a basic requirement for most of today’s businesses and organizations. To make progress and mature an organization must take the next step toward addressing more complex problems and make choices that promote structural growth and organizational progress.
Safety Needs
Moving up Maslow’s pyramid, human motivation addresses concerns for safety and well-being as choices of preference are made and a degree of order is sought. Organizationally speaking, burgeoning DevOps teams seek greater usefulness and functionality. It’s not enough for teams to perform a basic function, they need to adapt and find a way to get beyond a lack of cohesion. Organizations need a level of comfort (compared to Maslow’s concept of safety) in knowing that the development and operations teams can work together and have the best intentions for the project. This stage promotes an upgraded approach to software delivery and a reduction in production issues.
Once the realization that software is a basic need for companies and organizations, their sights turn to how best to make it happen across multiple teams with a common goal. And, if a level of internal stability and order can be achieved, the organization can begin to look beyond itself to develop outside relationships in the manner that Maslow describes in the third layer of his pyramid: belonging.
Social Belonging
In the third stage of Maslow’s pyramid, after the physiological and safety needs are met, human motivation shifts to interpersonal relationships and feelings of belonging. In terms of an organization that services customers or constituencies, once internal structures are in place, greater resources can be allocated to outward pursuits. This stage in the business mindset is when the focus on outcomes shifts from being vendor-focused and satisfying internal needs to the servicing the customer. They ask the question: What answers or solutions does the customer want from me? Just like in Maslow’s acceptance stage when humans consider what it takes to be a friend or to find love, organizations try to answer what it takes to provide customers what they need.
In this stage, the automation of DevOps contributes as teams integrate into a structured or organized community that can provide those answers. Teams begin working together and develop the early stages of a feedback loop and full visibility into the SDLC. The workflow takes on an increasingly automated role as a cultural shift toward full lifecycle ownership occurs and teams take responsibility throughout the deployment life cycle, not just in stages.
Esteem
If organizations succeed in putting customers first, they can take the next step to reacting to the customer’s needs at an accelerated pace. In Maslow’s pyramid, the next stage, commonly referred to as the esteem or status level, is divided into two elements: the internal and the external.
Maslow classified these two categories as: (1) esteem for oneself through dignity, achievement, mastery and independence, and (2) the desire for reputation or respect from others. To achieve everything that organizations want to for the customer, internally they must improve how the organization functions, and externally they must demonstrate to the customer that they are listening and the goal is to respond to the customer’s needs directly.
Internally, the organization requires its teams to communicate, collaborate and integrate better, and it puts pressure on its production activity to be responsive not just prolific. If this is achieved, it not only demonstrates that an organization is listening to the customer, but also that it can provide solutions at a cadence that makes the customer more successful.
Self-actualization
The final stage of Maslow’s hierarchy is self-actualization: the point of realizing potential and being the most that one can be. In any organizational structure, this may not be an end goal, because striving to be better should always be a core tenet. However, it might be argued that when the brain trust at the top—the CEO, the CIO, the board, etc.—are fully aware that the components of their organizations are working together and of what they are achieving, a level of corporate-actualization can be claimed.
Far from being the end, this is when thoughtful soul-searching should occur by asking the essential question: Is it all working? This is the most important question an organization can ask itself with regularity, and doing so is a sign of great maturity.
You can recognize your basic needs; build structure into your organization; service your customers, listen to their needs, respond promptly and make them more successful; and recognize internally what make your organization successful. But if you don’t consistently and rigorously ask if it’s all working, you risk slipping backward.
Once an organization reaches a mature level, how does it maintain or even enhance its hard-earned growth? The best thing it can do is to consistently define itself with the use of qualified actualization tools and reporting engines. True self-actualization and corporate-actualization require tools that can quantify how mature an organization is and where it stands by comparing how it’s doing against its competitors. Organizations need tools that can correlate data against a variety of peers in the vertical or in common geography, etc., and provide comfort in knowing what works and that they are leading the way.
In a recent episode of the Continuous Discussions (#c9d9) podcast, a group of industry experts discussed why DevSecOps is officially more than just a buzzword, tips on how to get everyone in the organization to own security and some of their own challenges and experiences baking security into the software delivery pipeline.
The panel included: Alan Shimel, editor in chief at devopsy.kinsta.cloud; Chenxi Wang, managing general partner at Rain Capital; Derek E. Weeks, VP and DevOps Advocate at Sonatype; Paula Thrasher, Chief Architect, National Security Division at GDIT; Geetika Tandon, director of technology at Federal Civilian CTO Group; and Electric Cloud’s Sam Fell and Anders Wallgren.
Continue reading for some of their top takeaways!
Why DevSecOps?
DevSecOps is really more about a cultural shift, said Shimel: “DevOps is DevOps. It’s not just about Dev and Ops, though. DevOps is about the whole organization adapting a common cultural way of interacting including security, and bringing security into that culture, into that software ordination assembly line.”
Integrating security into development practices takes a lot of collaboration and communication, per Wang: “It’s easy to say security should be part of the process. But in practice, it’s difficult to do. When you have a security testing process that takes days to complete from the input to the output, and then you have developer teams releasing 500 releases a day, those are two very different cultures. It’s usually an iteration process but it takes a lot of team communication, a lot of sitting down, figuring things out for security to be part of it, and so it’s a not an easy process.”
Why DevSecOps and not just DevOps? Well, security people weren’t necessarily invited to the party, explained Thrasher: “It’s a cultural challenge that security hasn’t necessarily been an integrative part of a lot of the DevOps transformations. I think ‘DevSecOps’ exists because either we’ve left security out or they’ve stayed outside this transformation that’s happening.”
There really shouldn’t be a trade-off between security and quality, according to Wallgren: “I long for the day when we don’t distinguish between security and quality because, yes, there are different disciplines to them in some extent, but as far as the end user is concerned a bug is a bug.”
Weeks wanted to let nonbelievers know that DevSecOps is real and more than just a buzzword: “DevOps and security can integrate with each other and integrate successfully at scale. There are organizations of a couple of hundred or even a couple of thousand people that have a DevSecOps practice in place that are continuously improving it, adding an automated security, so it’s definitely gone beyond buzzword status.”
Including security in the release process should be a no-brainer, according to Tandon: “I think of it as common sense. I don’t even understand how security has been left out. I don’t understand how we have these huge pipelines, we’re releasing a hundred code releases a day and then, boom, we’re stopped. We’re stopped for scanning.”
Common Barriers to DevSecOps and Patterns for DevSecOps Success
Progress takes time, but Shimel remains hopeful of the future: “We’re not going to boil the ocean or change the world in a day, but we will change the world and we will change the way software is delivered so that software and security is synonymous with quality.”
Wang explained how one company is utilizing automation to successfully bake security into their process: “A company that I have worked with is in the container world and they have what they call a Brown’s registry. So they have code that is assembled by the development team and then goes into a Brown’s registry. No other code can get in to the Brown’s registry unless it’s from their own team. Then from that Brown’s registry the security team automatically goes in and scans it and then only those that pass the scan gets put into what they called a Gold registry. And from there then they could deploy it to the server.”
Everyone in the organization should practice and be prepared to respond to security incidents, advised Thrasher: “The people that need to practice responding to vulnerabilities the most actually aren’t the security people. They’re used to responding to security issues. It’s the ops and the developers who aren’t used to responding to security incidents and they aren’t equipped, they aren’t trained on how to respond. So when your vulnerability happens it’s a bad new story.”
Many security issues have been around for a notorious amount of time, which is where the software delivery industry can improve, said Wallgren: “Where are most of the exploits coming from? The vast majority of them as I understand it are coming from well-known longstanding security issues that have been out there for a long time or, at least long by technology standards. And so a lot of it is just simple stuff that we need to be better at.”
Security as code is the next step in truly integrating security with DevOps, explained Weeks: “I was just talking to someone in Europe at a big telecom company, and they were saying, ‘I’m on the security team, we’re working with development, and we’re getting closer. We have all these rules and things that developers need to follow and we’ve been working with getting them to follow them more.’ And I said, ‘That’s really cool. Any of those rules or policies instrumented as code?’ And he responded cross-eyed like, ‘What? Code?’”
Tandon shared an eye-opening experience with a customer: “I’ve seen a situation where we were about to go to production—it was DevOps with security toward the end—and we got 4,000 hits and we had to go to production, most of them were ignored. So are we really securing our system or are we making our own system even more insecure by doing that?”
Watch the full episode:
Want to dive deeper into DevSecOps? Industry expert John Willis, co-author of “The DevOps Handbook” and “Beyond The Phoenix Project” and VP of DevOps and Digital Practices at SJ Technologies, is scheduled to lead a full day hands-on workshop immediately following DevOps Enterprise Summit in London and Las Vegas. Register soon—space is limited!
There may be nothing more difficult in a DevOps transformation than aligning the business with its technology organization—and vice versa. Dealing with skills gaps and information gaps, while addressing communication breakdowns and cultural hurdles can keep even the most seasoned practitioners and leaders up at night. How do we align disparate business units accordingly? What practical tips can people take and implement along their journey?
These are topics we immersed ourselves in during a live video podcast ahead of the DevOps Enterprise Summit (#DOES18) in London. I was able to sit down with Carmen DeArdo of Nationwide and Jayne Groll of DevOps Institute to take a deeper dive into the DevOps transformation patterns and practices. This discussion centered on a major theme of DOES18 this year: business and technology alignment for the modern enterprise.
We hit on many important issues that I think we can all learn from and apply in our organizations respectively. One of the things we’ve learned over the course of the years is that, in DevOps, the focus is heavily cultural, but it has to be squarely on nurturing and getting buy-in across the organization. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. That’s a tall task.
Watch the full video replay below, and/or read through the full transcript to see what key points were made and how we can adopt best practices to move our businesses forward.
Carmen and Jayne will both be speaking at DOES18 London this year and I will be leading video panels that you can see exclusively on DevOps TV / devopsy.kinsta.cloud. Hope to see you there!
Alan Shimel: Hey, good day, everyone. Thanks for joining us. This is Alan Shimel of devopsy.kinsta.cloud. And I’m here to talk to you all today with a few friends of mine about the upcoming DevOps Enterprise Summit in London. This will be a live panel discussion ahead of the London DOES event, which, by the way, is June 25th to the 26th at the Intercontinental Hotel, sometimes called The O2. Our panel today, I’m happy to say, are two really good friends of mine. Well, one is one of my business partners at the DevOps Institute: Co-founder and CEO of DevOps Institute Jayne Groll, and a speaker at DevOps Enterprise Summit London. Jayne, welcome to our hangout today.
Jayne Groll: Hi, Alan. Hi, Carmen. Thanks a lot. Really looking forward to it.
Shimel: Okay. So Jayne has already sort of introduced our next guest there, another good friend of mine, a recognized DevOps leader for many years. He really kind of kicked off a lot of the kind of groundbreaking DevOps work that we’ve seen at Nationwide over the years. Also a great Pittsburgh Steelers and Pittsburgh sports fan, Carmen DeArdo. Carmen, welcome.
Carmen DeArdo: Welcome Alan. Welcome. Hi, Jayne. It’s always great talking to you.
Shimel: Thank you. So all kidding aside, both of you are kind of experts and leaders within the DevOps Enterprise community, and you’re both presenting at DOES London this year. You’ve actually both presented at previous DOES events as well. So thank you for coming here. You know what? When you guys first started kind of preaching in the wilderness about DevOps and so forth, it was a bit of the wilderness, but it’s becoming commonplace in businesses and organizations throughout the world now. Our goal on this chat, guys, is to learn about the patterns and practices that leaders have identified for business and technology alignment, and really what we’d hope is just to share your experience and thoughts with our audience so that maybe they can learn something and they could integrate or assimilate that into their own transformational journeys and escapades.
And just again a reminder, this is about DevOps Enterprise Summit London, June 25th to 26th, and you can get more information on the event at events.itrevolution.com. You’ll find on there, by the way, the entire conference agenda, and beyond Carmen and Jayne, it is a gangbuster lineup of speakers. If you’re interested in DevOps and any kind of related type of technologies and frameworks, etc., it’s really a can’t-miss one for those of us, you know, who follow this space, or even for those of us just getting involved in it.
That being said, though, I’ve spoken enough. Let’s get started. I’ve given a little bit of your background, but maybe I haven’t said everything that needs to be said. So, Carmen, since I see your lovely face on the screen ahead of me here, why don’t you go first? Give us your background, your company role, etc., professional accomplishments.
DeArdo: Okay. Thanks, Alan. So I actually spent most of my career in telecom working for Bell Labs. Thought I would retire from Bell Labs like everyone else at the time, and then the telecom bust happened, and we all had to figure out what we were gonna do with the rest of our careers. But it served me well, because I think a lot of those concepts, even though we didn’t call them DevOps, but, you know, certainly, creating high-availability, high-reliability capacity systems, you know, those concepts are still, I think, pertinent obviously today. I moved into Nationwide to really help with trying to get Agile set up about 12 years ago, and then, you know, as I think you see the case with a lot of companies, they start somewhere in their value stream. They may not even think of it at that point like an end-to-end value stream, but they’re starting somewhere. They start with Agile.
You know, we were very successful getting all our work done there, but then realized, okay, that’s only part of the story. The cards getting into the backlog through iterations is great, but we aren’t getting flow of work from the business into the teams, and we certainly aren’t releasing into production frequently. So about, I’d say, five years ago, you know, somewhat in affiliation, some of the work I was doing with, as you know, Rosalind Radcliffe, Hayden Lindsey, you know, started to talk about what’s this DevOps thing. Was lucky enough to end up at the first Gene (Kim) conference speaking with Hayden. Wasn’t sure what I was getting myself into, but it’s been a wonderful experience. You know, got to meet you, Jayne, and lots of great folks from Gene’s community.
In Nationwide, we’re just continuing to work, how do we make that end-to-end flow and lead time, you know, what do we do to make it better? What DevOps practices can we bring? But as you noted at the beginning, how do you get the business more online? How do you get work to flow? And how do you address culture, which we know is probably more important than technology?
Shimel: Excellent, dead on. Jayne, how about you? You have more hair than both Carmen and I. You’re the lovely face we should see on the screen here. Give us a little background and accomplishments.
Groll: So I call myself an accidental technologist. So I started my career, got out of school, ended up in the legal field for about 15 years working on the business side. So I wasn’t a lawyer, but I was one of the early paralegals for a big Wall Street law firm that adopted UNIX a long, long time ago. I don’t even want to say when, but screens were black and green back then. And so everybody had to learn UNIX. And so I was very fortunate to be given an opportunity to accidentally become a technologist, and I know even with my technical skills, I’m a little self-taught. Was able to move up into some senior management roles across several different verticals, leaving the legal space.
And then in 2004, kind of fell on ITIL and really started to see a paradigm shift in IT that technology is important, but your practices, your principles, your processes are important as well. And people, process and technology became a mantra. And so co-founded ITSM Academy with Lisa Schwartz and really saw the growth of maturity in IT. You know, I always say we love our frameworks. IT, we love our frameworks more than any other business unit, and really started to see that percolate. Met Gene and some others through that experience, but really, landing where we are today. In 2012, I was able to attend an early DevOps day, frankly, at Gene’s invitation and really saw something percolating there that was pretty much common sense, but not common practice.
So we started to see, you know, should Dev and Ops collaborate better? Should there be a faster flow? Should there be less silos? Yes. Should we use automation more? Yes. We automate the rest of the world, we don’t automate ourselves as much. And really started to see something grow there, and, Alan, as you know, in 2015, we launched the DevOps Institute primarily because the practices around DevOps unlike other frameworks were really emerging in the wild. You know, you said it before. They were emerging in the wild and making some sense out of that, you know, as it crossed over into the enterprise space was important and requires a lot of research.
So, you know, we don’t have a single body of knowledge in DevOps. Thankfully, we have a collective body of knowledge in DevOps. So for me, I think part of my, you know, pride is my journey has not been a linear path. Really blessed to be, you know, where I am today, and, you know, DevOps Institute right now is, what, 32 countries that are talking about in doing DevOps. I mean, that’s really kind of surprising and remarkable all at the same time.
Shimel: Yep. And just to excuse, I don’t know if you guys can hear. We have a train, the 11-08 Cannonball Express, going via the office here.
DeArdo: Just like my cousin Vinnie here, Alan? Is that like …?
Shimel: That’s “two yutes.” The way I talk, we’re not far off. Anyway, though, guys, let us move along here. You know, one of the things that I’ve learned in my own exploration of DevOps and digital transformation, etc., is that a lot of businesses, large enterprises, they may think they do, but on the whole, they don’t really understand technology. Yeah, some of the guys in IT understand some of it or what have you, but do you think most businesses understand technology? Carmen?
DeArdo: I think it’s … Obviously, people are exposed to technology. In fact, I talk about this all the time, that sometimes we’re still in the book writing business or book production that we still feel like we got to produce manuals of paper material … The disconnect comes as, How we can effectively utilize the technology that we have to meet the business needs? And I think that’s maybe where the disconnect goes. It’s not that, you know, people certainly are … they have Alexas. They have stuff in their home. They may be even, you know, great at programming their home devices, but how are we actually taking advantage of that to serve our customers? And I still think thinking about things kind of in this … you know, Jayne talked about silos, but I actually think the last frontier really of DevOps is in the left part of the value stream, not the right part.
I think they code the cloud. There’s patterns, maybe not everybody’s done it. I know it’s not easy to do. That’s pretty well-defined from a pattern. The front part is not, and I think understanding that, you know, you have to basically be an IT business. We hear this all the time. If you’re not an … consider yourself an IT business, someone who is good at IT is gonna disrupt you. So it’s not that I don’t think they understand technology. They’re certainly capable of it. It’s just, do we really understand how we can use it the best way in order to meet business needs? And, you know, things like the system of engagement. Well, the system of engagement is gonna change. We’ve already seen it change. It changed from web to mobile. It’s going to voice. It’s gonna go to different engagement models.
That’s fine, but you still have to have the back-end technology, and the microservices, and the APIs, and the ability to deliver more quickly, and I think that’s the part of it, the gap we still haven’t bridged. And how can we actually get …? You know, one of the things that Nicole and I are talking about at the conference is the project-to-product model. And I think large companies like ourselves are kind of flailing at what … you know, that makes sense. It makes sense to align around a value stream, but how do you really define what those value streams represent so that you can actually get that flow and then use technology to help get that quick deployment and, you know, feedback? So I think that’s where we see a lot of the gaps, you know, from that perspective.
Shimel: Sure. Jayne, before I have you answer on that, you know, I got an email of pitch. I get a lot of pitches as you can imagine, but I got one the other day that, to me, really nailed the issue. The issue was they pitched me about how great their solutions and their services are, and they said it makes IT costs less. Instead of … so they’re still thinking of the IT department as a cost center instead of a profit generator. And to me, when you say that, that means you really don’t understand technology, you don’t understand the role of IT in the modern enterprise, and you’re just not doing it right. Jayne, your thoughts.
Groll: So I think you’re right. I think, you know, the modern enterprise has a few challenges ahead of it. Carmen, I absolutely agree with you. I think every business knows they need technology and they need to accelerate their use of technology. I think they don’t understand how to apply that, and more importantly, I think the big paradigm shift, and, Carmen, you said it, is that most companies don’t realize that they are now technology companies. It isn’t even just IT does for you, is the core company as a technology company. And those that kind of recognize that, I think, are those that move ahead. Those that are still kind of hanging on to a legacy … Now, you know, I’ll add kind of something into that recipe that’s a little scary.
With the way technology is moving and how fast it’s going, I mean, the acceleration is remarkable, and, you know, Carmen, you said it. It was cloud. It was mobile. Now it’s voice. That it feels like, you know, this kind of moving target that if I’m a business leader, not a technology leader, although Lord knows that, I think, has a plan here, you know, where do you put the dart? You know, do you invest in mobile? Do you invest in voice? Do you invest …? So it’s such a moving target, and it’s going so fast that I think it can be very daunting to figure out, okay, where do we make our play, and, you know, where do we use our technology spend? And I would say something funny, Alan, because you’re right.
You know, in my years in senior IT management, I almost always reported to the CFO, because I was a call center. And so it was nobody understood quite what I was spending money on, but they figured if I reported to the finance guy, that somewhere along the way the cost would be controlled as opposed to let’s optimize the capability. Let’s look at this in investment. So I really think organizations are trying to figure out, first of all, are we a technology company? And I would say unequivocally the answer is yes regardless of what vertical you’re in. And then where do I invest? What technology do I start looking at? And if what I do today is gonna be obsolete tomorrow, how do I make that investment for my company further?
Shimel: Excellent. So, guys, you both have a little bit of a background, more than a little bit, in training and so forth. Do we train people outside of the IT organizations on what technology can do for you? Do we put up sort of Uncle Sam’s “We want you. What can I do for you?” posters? How do we get the business to understand the technology aspects, the technology side of things? Go ahead.
Groll: I mean, you know, the “we want you …” unless you can promote something that says what’s in it for me, me as an organization, me as an individual, me as a leader, I think that’s difficult. You know, doing road shows on here’s what technology can do for you isn’t something that you can tell. I think it’s something that you have to prove. And I think IT sometimes runs into an uphill battle trying to prove that, because it is costly and it does change a lot of the way people perform on a daily basis. I know what I did today, and tomorrow you want me to do something differently, and I may not be as successful as I was yesterday.
So there’s a little bit of a proof of concept usually, you know, done through piloting, whatever, but I think the, “How do we tell them?” I don’t think we tell them. I think we have to show them.
Shimel: Fair enough. Carmen?
DeArdo: Yeah. I mean, I think we’ve gotten a lot of appreciation. I mean, I’ve told … you know, and Cindy Payne and Jim Grafmeyer told the story at the last conference about Hurricane Harvey and how the business was able to respond within a day to what was a wind event and came a rain event with all our flooded cars and how we got the website optimized to handle those, to take the load off of our customer service center. They’re starting to get that, “Gee, having this capability to deliver things more frequently …” We now have some of us who deliver daily whereas before everything was going into a monthly release. So that’s a great accomplishment.
On the other hand, we’re running into the things that, you know, Topos talked about with compliance, with legal, with … and just, you know, how do we … Most of our time now on lead time is going from the idea to the backlog of the team, not from going from the … you know, the team getting the work to deployment. So I think going into, you know, that view of how do we start to think more about, you know, the other things that are getting in our way of lead time, because it’s not just the IT part of it. It’s now the business part of it, and we have a couple areas now who actually have true product owners sitting with their lines and are almost at the point now where they can deliver, you know, stories and storyboard them and move them all the way through production, you know, much more quickly.
So I think that’s an example, and I think that’s what you need. I always talk about you need stories, you need examples of how this can actually be done at your company, because reading about it, hearing about it is great, but then when you see the team next to you doing it, and even if it’s not perfect and even if you know it can be improved, that’s where really you start to change the culture of not just IT but of the business. You want something like that. And then, you know, I think you got something going that you can really build on top of. Jayne.
Groll: Yeah. I mean, I think that conferences like DevOps Enterprise London, Las Vegas, other events, local events, I think, also let individuals and organizations know they’re not alone in this journey. You know, part of the challenge in DevOps right now, I think, is we’re going from what is DevOps to how do we do this. And it’s not finite. It’s not, you know, you open a recipe book and it says, “Start here. Add these ingredients. You know, stir, bake for 350 degrees, and you have DevOps.” It requires a lot of higher-level thinking, requires some experimentation. And so I think that, you know, access to what have other people or organizations done … Carmen, I think you’re absolutely right, what have other teams done, really kind of making it a community of enablement is very, very important in this space, because everybody’s trying to figure out where do they start. And unfortunately or fortunately, the answer is it depends. It depends where you are, it depends what you’re trying to achieve. So I think that’s part of it as well.
Shimel: Yep. So, guys, let me try to tie a bow on this section before we move on. The reason I asked about the technology and technology education issue is I think it’s imperative for organizations to understand that in order for us to get what I call business and tech alignment, and what I mean by business and tech alignment is that we’re all pulling in the same directions for the same reasons with the same goals, and we’re following hopefully a road that we have agreed upon, and we all know the road we’re traveling, because, again, you get back to DevOps, guys. You know, when you guys are out there talking about it and we were covering it at devopsy.kinsta.cloud, what do we always hear? What exactly is DevOps?
There’s no real definition. What does it mean? You know, how do we define DevOps and so forth? And I think one of the things we’ve learned over the course of the years is that, you know, in DevOps, the focus is, you know, heavily cultural, but it has to be squarely on nurturing, buying across the organization for this “DevOps initiatives,” you know, that we’re starting. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. And that to me is business and tech alignment. If you guys don’t agree with that, speak up, but if you do, let’s move on to our next part, but can we wrap up, Carmen, Jayne? Are you fair to say that what we’re really talking about here is business and tech alignment?
Groll: So I’m gonna jump in just for a second, because … So you know I come from the ITIL space. And so in the ITIL space, they were coining the term BITA, business IT alignment. And so for years and years and years, there was a lot of conversation about BITA and its semantics. But alignment means that we’re kind of standing side by side in lanes next to each other. The reality is it isn’t alignment. It’s really unification. It’s really we don’t need to align with the business, we need to become the business. And, again, I know it’s semantics, but that word alignment gets tossed around a lot, and it implies something like, “Well, I’ll drive my car next to yours, and we’ll travel at the same pace, and we’ll get to the same journey,” as opposed to, “Let’s be in the same car.” And so you understand what I’m saying?
Shimel: Yeah.
Groll: And I said the term BITA is sort of falling away a little bit, but it was thrown around a lot during the years when ITIL in particular, you know, was kind of front and center.
Shimel: Yap. Carmen, any thoughts on that before we move on?
DeArdo: No, that was great points. And, you know, I refer back to Mark Schwartz’ last book, “The Seat at the Table,” and where he really talks about IT really should move beyond trying to get a seat at the table and move towards, you know, as Jayne said, you’re actually moving together, and you have to merge really these concepts of what the business wants, you know, has to be very much aligned, more than aligned. It’s part of what IT need to be doing. So that merging has to take a fact, and I think as much as we’ve seen the culture issues in Dev and Ops, that’s gonna be an interesting culture issue. But we’re seeing the companies who are successful are already doing it. They are working together. And, you know, if you walked up to some of the teams I just talked about, you wouldn’t be able to say, “Oh, well, such-and-such is a business person, and, you know, Jayne’s a business person, and John’s an IT person.” No, they’re a team working together to achieve something for the good of the company, and that’s the way it has to be.
Shimel: Yep. Guys, let me broach another subject then, because I think we’ve covered this one. You know, I read an article yesterday about AI, and automation, machine learning, and we’ve all seen these before, and, you know, how it’s changing. But automation really is changing the job market, especially for people younger than the three of us. I mean, we’ve both seen our … all three of us have seen our 21st birthday recently and …
Groll: Just recently.
Shimel: Recently, but really the folks coming up behind us, and we’re talking about our children and so forth, automation and the job market that they’ll grow into is paramount. And one of the reasons is that we have a tremendous skill gap. You know, my background is obviously in infosec, and now we call it cybersecurity. I hate the term. But there’s a tremendous gap in the security space. There’s also a tremendous gap in the DevOps space, obviously, and that’s one of the reasons we see such a high demand, even for people who may not be certified or classically trained in DevOps, I mean, take some sort of DevOps class. If they’ve learned to work Puppet or Chef or Jenkins, you know, they’re in high demand here.
And so with this skills gap, it doesn’t hinder our DevOps transformation. Is it a drag on the entire DevOps industry or community? Jayne, I’m gonna ask you to take first crack at that. I mean, you must see this with DOI stuff.
Groll: I do, and, you know, it’s kind of like good news, bad news. So the great news is, where else do you get to work in an industry or an environment where you are now encouraged to learn something other than what you’re essentially good at? I mean, you’re now encouraged to grow new skills to evolve. Organizations are funding skills modernization programs. So, you know, we groomed … and Carmen referenced that. You know, we groomed an IT based on silos. And in every silo, you were a developer, or you were a QA person, or you were a security person, and you lived in your silo with other people who had the same skills as you did. And now, cross-functional skills and, you know, what they call T-shaped people where you need to still have a specialty but you’re absolutely required to have very large breadth of different skills means that organizations are supporting and funding that.
So the continuous learner is more the norm today than it was before where you will be a developer … experience, and I think it’s a great day to be in technology truthfully, because you are encouraged to think, and learn, and practice, and train, and do, you know, all sorts of other things. And I think companies are starting to see that. I hear the term “skilling” a lot. We not only talk about training, we talk about skilling. We need to skill our force. We need to skill our teams. We need to reskill or upskill. You know, those are really terms that are starting to enter our common vocabulary. And the day of the generic, “I’m a master, I’m an expert, I’m a practitioner,” and I’ve got a few of those credentials as well, those are so ambiguous that now the skills are very, very tangible, and organizations are hiring, I think, hiring and funding individuals to develop not only technical skills but practice and principal skills, too. So we’re all gonna be upskilled, maybe outskilled.
Shimel: Perhaps both. Carmen, how about you on this one?
DeArdo: Yeah. I mean, automation is obviously nothing new. I mean, I’m really dating myself, but I can remember when people didn’t trust the output of compilers. Like, are we sure the compilers are producing the right machine language or assembly language? I don’t know. I can bring the assembly language better than this compiler. I mean, I think automation and learning is just … obviously, you know, if you spent, you know, four decades like I have, and, you know, none of us are spring chickens, but you’ve got to learn a lot and keep learning. Now, I think the great thing, and I agree with you and Jayne, the great thing about Nationwide is they have invested in learning and upskilling their people. We had this thing called Teaching Thursdays where twice a month we have two hours which is set aside for peer-to-peer learning, and it’s really not … and it’s peers teaching people, and people love to be the teacher.
I mean, at the last forum, Jason Cox was talking about … We had a subgroup focused on operations, and Jayne was there. And talk about … you know, he had some folks on his team, that they have to become engineers. They have to become coders. And one of the guys who initially maybe wasn’t so crazy about it, once they became kind of the expert in their area and they were teaching other people, well, you know, they were really engaged then, because, you know, they were involved and they were the one now from a peer-to-peer learning perspective.
So companies, I think, like Nationwide, Disney, other companies that are leaders in this space need obviously to invest in that. And then, you know, it also means that the associate themselves, you know, needs to take advantage of that. I mean, we can offer those capabilities. We know the jobs are gonna change. We can make those skills available, and then folks need to take advantage of them, but yes, I mean, people have to become more broadly skilled and be able to become more of what I would call problem-solving engineering mindset as we move forward.
Shimel: Sure. So, guys, though, you know, so we have skills over here. And on this side, there’s another thing that creates a tension with the skills, and that’s what I call the information gap. So we have a skills gap, and you guys have both addressed that really well, but we also have an information gap. And I alluded to it when I talked about training. If an employer or an organization thinks that someone who can write a recipe in Chef or has heard of Jenkins is a DevOps engineer, if there’s such a thing as a DevOps engineer, or is someone who, you know, is gonna really help build their DevOps team, to me, that’s not a skills gap, that’s an information gap. How do we understand … How do we make organizations … How do we fill that gap on information so that organizations recognize, A, that there may, in fact, be a skills gap, B, how to fill that skills gap and bring the organization up to it?
I mean, this tension, this chicken-and-egg, if you don’t know it, you don’t know. How are you supposed to know? And so I’ll put it to you. What do you think is more important? The information gap, the skills gap? Are they equally important? Do we tackle them concurrently, individually? Carmen, how do you guys do it at Nationwide?
DeArdo: I mean, I think one of the things that IT hasn’t been good at is treating IT as … we’ve been a very bad customer to ourselves. So if you look at our pipeline, we don’t treat it as a product. If you actually want to get faster at delivering a capability from idea through deployment, you need to consider that as a product, not a bunch of different tools. It’s not Jenkins, and New Relic, and UrbanCode or, you know, the AWS. It’s not that. It’s a pipeline that’s gonna enable you, and it doesn’t start at code, it starts at idea to get you all the way through that deployment. So then what … do you have a team? Are you doing thinking across the pipeline? Are you doing architecture? We don’t do things like value stream architecture or architecting the pipeline as a product. We want to buy a bunch of technologies. We can hire people good in those technologies, but as you said, that’s not really gonna get us where we need to go.
So I think the first thing is, do you really treat your product … One of the first things, do you treat your pipeline as a product? Do you have a team that can actually support that product all the way? Do you have a product owner who can drive continuous improvement across that with funding and prioritization? And do you have one of your best architects, if not the best, to actually create the architecture and do value stream architecture, which is something, you know, that Mik Kersten and I have been talking a lot about. I think that’s one side of it that we don’t get, is teams could … if you ask a team, they can kind of figure out, tell you like a Deming quality circle, how they can go faster. And you can experiment, but then if you’re gonna operationalize that, you don’t want 200 teams doing things in 200 different ways. You can then take that and say, “How do I address that as part of my delivery capability?”
And then I think what you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, “How do I optimize this as a whole?” They want to get into the weeds. They want to get into the tool selections. There’s people that can figure that out. You need to really focus on the strategy and how you can optimize all this great information you’re getting to make sure you’re removing barriers and allowing teams, you know, doing the learning, making sure they can be upskilled, investing in their ability, and allowing them, you know, to be able to innovate and improve your delivery capability. And I think that’s what I just said quickly. It’s easier said than done. And I think that’s where I see a lot of the struggles, and I think where we’re trying to address this is how do we start to put some of those pieces in place so it’s not just a bunch of, you know, divergent disparate technologies we’re trying to bring in and hope that that’s gonna make us get better. Because those things and having skills just around those things is not gonna actually get us to where we need to go.
Shimel: Fair enough. Jayne, I’m gonna give you a chance to comment on the DevOps skills versus information gap.
Groll: So I think the two are really related, and I think Carmen brings up some good points. You know, I think it all comes down to silos. So let’s look at our silos. Well, within our silos, we speak the same language. We use the same acronyms. We use the same tools. We live in a common community where everybody kind of understands what’s going on and what’s happening. And then when we leave our silo and we try to talk to a different silo, we don’t speak the same language. We don’t use the same tools. We don’t have the same processes. So I think the skills gap doesn’t fully overcome the issues with the information gap, but, certainly, there’s help there that if we’re looking to share information, we have to share it in a way that everybody kind of has some type of uncommon understanding.
The other thing with information is, you know, information is really interesting to me, because everyone thinks they communicate a lot. People generally think that they communicate well. You know, teams generally think they communicate … like I told you that. You told it to me maybe in language I don’t understand or it wasn’t clear. It was some report that, you know, I don’t even know where it is. So I think, you know, kind of the flow of information and from a vocabulary perspective, from an understanding perspective, from a “Did you understand what I shared?” is something we all need to overcome. And I think, you know, again, they’re so interrelated to each other that if we start to create a broader set of skills, hopefully, that helps to improve the communication. I think the other side of it is we talk a lot about collaboration, and there’s a really fundamental difference between communication and collaboration.
And so information flows through communication, but communication is pretty much one way. I tell you, you tell me, and somewhere along the way. Collaboration is I start to ask your opinion, and that’s a really big, big difference. And so when we’re starting to share information, there’s a respect that comes across the skills gap. There’s a lot of things that go across that that, again, there’s separate gaps, but hopefully, the long term, and as Carmen said, not easy to fix, is by overcoming some of the skills gaps as well.
Shimel: Fair enough. I think we’ve covered that one well. Let’s move on to another area if we can. We have 20 minutes or so. You know, one of the things that really does my heart good is this concept of DevOps everywhere as far as the eye can see, like the meme with Buzz and Woody. We have seen DevOps move from just Dev and Ops to QA, DevSecOps exploding on the scene where, you know, a couple days, the 28th, a day or two after DOES London, John Willis and team are rolling out our second DevSecOps Days, which I’m involved in, and devsecopsdays.com for those interested. But even beyond IT, we’re seeing what I call DevBizOps, where DevOps’ Agile sort of practices are starting to take hold in HR, in sales, in finance, in, you know, accounting, etc.
And let’s be fair. This is not unique. The fact of the matter is a lot of the lean terminology, a lot of the lean stuff that was built into DevOps didn’t come from IT, it came from manufacturing. And so, you know, it’s like pay it forward. Now we’re seeing these kinds of DevOps principles move into other areas of the business. First of all, is that a good thing? I think it is. I can’t imagine it’s not, but I’ll defer to the both of you. And then, secondly, you know, hey, at the end of the day, remember, it’s all about the culture, stupid. And so what human factors, cultural factors should we be thinking of when we talk about a broader DevBizOps opportunity? And, Jayne, you’re on my screen, so I’m gonna tell you to go first on this one if you can.
Groll: You know, it’s business transformation. You know, it’s not really DevOps transformation. Digital transformation is not limited to IT. It’s really business transformation. And so it goes back to, you know, we talked about a little while ago, where, you know, every organization has to recognize that technology is their business, and so some of the practices from the business start to assimilate into IT and beyond. I saw this in service management where there’s now movement towards enterprise service management, where you’re gonna make changes, you do it the same way.
I think when we start to look … I mean, I can tell you from the content perspective, you know, we use tools in content development, even though it’s not software development, that are very, very similar to that. So I think it’s fantastic. I was talking to a gentleman from an organization on the Netherlands recently, and they actually took the Spotify squad model and applied it to their entire business, and not a small company, by the way. And so they applied it to their entire business where their business is now broken into squads. And, you know, some think that that’s only for a tech company, and by the way, this is not a tech company. It’s a large financial organization.
So I think that’s great. I do think there’s some … I think there’s good news, bad news. I think there’s a little bit of risk that, you know, with DevOps and some of DevOps practice is still emerging that it becomes, “This week, we do it this way, and this week, we do it another way.” And, you know, “Oh, that didn’t work because …” You know, fill in the blanks, but I do think that kind of having a one business and getting away from this we love our frameworks and IT, and every year, we have a new framework that supposedly supersedes the other framework, you know, that’s a maturity issue. And I think if the business embraces it … you’re right, Alan. Lean Six Sigma. That was a business initiative that a lot of organizations underwent that weren’t necessarily manufacturing organizations. So, you know, as we get closer to that, I think the unification becomes stronger.
Shimel: Great. Carmen, how about you?
DeArdo: Yeah. So I think of things like … It is a great thing. So I think of things like lean concepts. We have leaders across the company that we have gone through lean education and lean concepts. So when you talk about value streams, when you talk about lead time, when you talk about wait states, people understand those concepts, whether they be on business or IT. I mean, this whole idea that Dominica, I’m sure, would have talked about, about making work visible, Kanbans. I mean, we actually had an explosion of people who wanted to use some of our tools that initially were brought in for work out of management because they wanted … you know, it’s like, “Gee, who knew, you know, this Kanban stuff would work for us and WIP.” WIP limits. And so people certainly want to apply those kind of concepts.
So I do agree that, you know, the basic concepts, you know, really can spread everywhere, and the whole concepts of even the things, like we talked about it, the three ways. The three ways don’t just apply to IT. The three ways apply to anything that you’re trying to do and get better at. I think when it comes to information sometimes, though, you know, it’s kind of like the robot story and the goal. We have lots of KPIs, but are we actually focused on the goal? So the goal is not around keeping this person utilized or that team utilized. The goal is about, can I get faster from one end of my value stream to the other? And do we have data that shows flow? And that’s why I’m excited with some of the things that I’ve been … you know, that Mik’s talking about. You know, he has a book coming out that is gonna show actual flow of work, because up until now, we have not been able to actually see work flow all the way through that delivery pipeline. And so we guess a lot of times. We think, “Oh, well, if we just add more developers. Oh, we’ll add more testers.”
Well, how do we know? We don’t really know, because we’re making maybe educated guesses, but we’re really not all focused on understanding where the work is and those concepts that can shine a light on it. So I think it all does come back to a lot of those concepts that, growing up in Bell Labs, I was lucky enough to experience with Deming, even going back to Shewhart, around doing those experiments, getting better, seeing the entire end-to-end value stream, but these concepts apply. I mean, “The Phoenix Project” is really not a book about IT even though I teach part of it. It’s a book about how do you get better at doing whatever business you’re in and trying to, you know, stay in business and improve what you’re doing for your customer. So I think those concepts will continue to go, and I think, again, as we’ve talked about today, there’s a thread here of everybody needs to be on board with these concepts: legal, compliance, the business, everybody, because they all play a role in allowing you to do a better job, delivering more quickly to your customers.
Shimel: Fair enough. Guys, let me … You know, Carmen, you hit on some great things there. The Kanban board or even here at devopsy.kinsta.cloud, frankly, we run our entire customer engagement, not practice, but now into farming, on Trello cards, which is sort of an electronic Kanban. And it’s a great project manager. I’ll give you another thing. You know, there’s the cultural aspect of this of taking that sort of DevOps culture and expanding it throughout the organization, but there’s also the bits and bytes and tools aspect of it. Kanban’s a great example. I’ll throw another one out at you. Get up. Why does it have to be source code for programs? Why can’t it be source code for contracts or any kind of digital document or, you know, things that we work on?
So I think we’re just starting to scratch the surface on how we can take that DevOps can do or Kanban and, you know, move it out across the entire organization. And we’ll all … I think we’ll have better organizations as a result, but let me now turn it back around. How can we take some of the business culture positives, some of the things that have worked in other parts of our business, and reflect it back into our DevOps and IT processes? How can we enhance our DevOps by adopting broader business principles and practices that seem to work? Carmen, I’ll let you take first crack at that.
DeArdo: So I think, actually, a lot of our test and learn activities started with the business who had actually hypotheses around, “Well, if we offered a policy in a different way or if we made a tweak to something, would we be able to sell more of those things?” So we had people who … and there’s a lot of statistical rigor that you have to bring to that. So we actually had people on the business side who had these ideas about, “I have a hypothesis. You know, is there a way you can allow me to test that hypothesis to see if it, in fact, will yield some positive result in terms of actual policies being sold?” So it was a very scientific-type experiment that they actually wanted to run, and at the time, we really didn’t have a way to support that from an IT perspective. And it kind of forced us to do some things to support, you know, how could we actually get this out and offer it to only a subset of people, which we now might call canary launch or some other terms that are DevOp-ish terms, but really nobody was reading a DevOps book at this point. They were just trying to figure out, “How can we support the business’s need here to try to adapt more quickly and have a high plan around?”
And that started, I think, some of the things that actually were successful that then led into once we started to get into DevOps, like, “Okay, what we actually did there was DevOps.” We didn’t call it DevOps, but those are principles that really we need to support not just in this one’s case, but for all kinds of business hypotheses that we want to get out and turn around real quickly. And doing that really does bring everybody together, because it’s exciting. It’s exciting if you can sit at a business and you can think up, “I have ideas for this product or that capability. You know, how can we more quickly try to see if that would be a good idea?” rather than writing a 12-month business case and trying to do, you know, a protracted study.
So the whole idea of experiments and gain things out quickly, I mean, everybody will resonate and get behind that if you talk about it in that way. If you start talking about Puppet and Chef and things like that, that’s not gonna cut it. But if you talk about it in terms of business and what it can mean for the business, then that resonates and gets a lot of people excited.
Shimel: Excellent. Jayne, how about you?
Groll: I mean, I think Carmen is right on point. And, Carmen, you said something I think that was … you’ve said a lot of very insightful things, but I think in particular that the experiment came down to, “How can we sell more policies? How can we make our business more successful?” And I think if you look at kind of the past in IT, sometimes, we didn’t know how we were contributing to the bottom line. So we were introducing a lot of technology, and we were doing all this cool stuff. But how did that convert into an increase in revenue, an increase in market share, increase in competitive advantage, things like that? And so I think that this unification with the business becomes more significant when IT sees themselves as an enabler of the goal. The goal of every business is to make money. And so sees themselves, and it goes back to information and communication as well, that they understand that what they’re doing is actually helping to sell more policies or increase market share or stand above the herd or anything along those lines.
Now, again, if you’re the CIO, you probably know that. If you’re in senior management, you probably know that. If you’re a developer and you’re one of a few hundred developers, you may not know that. And so I think that it is that kind of bottom-up top-down approach where understanding that what you do every day is contributing in a very, very substantial and tangible way. And then I think the other part of it, and, Carmen, I think you said it really well, is encouraging those experiments where the business and IT work together. And maybe it is that 1 in 100 coder that’s working as part of that team to say, “You know what? I have an idea.” Everything starts with a great idea. It could be from the business. Hopefully, from the business, that says, “I have an idea. Let’s see if we can, you know, bring that to life and what it will do to our bottom line.” And then there’s really a great collaboration between IT and the business.
Shimel: Agreed. Agreed. So, guys, we’re coming up to the top of the hour here, and I guess we need to wrap up. Otherwise, we’ll just be on air all day, and I know Jayne has a show in Vegas and so forth, and Carmen has stuff to do. But first of all, Carmen DeArdo, Jayne Groll, thanks for being our guests here on this hangout as we, you know, continue to build up to DevOps Enterprise London, DevOps Enterprise Summit London. Just a reminder for anyone watching, it is June 25th and 26th in London. There are still some tickets left, I think. I don’t know how many. I wouldn’t wait. You can get updates about the event as well as get tickets at events.itrevolution.com. It’s obviously on the web.
By the way, this year, as in past DevOps summits, devopsy.kinsta.cloud is a media sponsor. We’re partners. We’ve partnered with Gene from the beginning. We will be doing videos again this year at DevOps Enterprise Summit. I think it’s gonna be a little different this year. We’re doing some interesting roundtables. You’ll see them on our YouTube channel, DevOps TV. So stay tuned for that. All right. Guys and lady, or guy and lady, I had a great time today. I’ve learned a whole bunch. I hope our folks listening and watching this have learned as well. You know, you guys have done, not just today, but, Carmen and Jayne, you’ve been instrumental in helping to bring the gospel of DevOps to the world, if you may, or at least maybe not the gospel, but at least some really good learning and understanding.
So thanks again, guys, for being with us. We’re gonna call it a wrap. Carmen, any last word? Three words.
DeArdo: Three words. Project to product.
Shimel: Okay. Jayne? Last words from you.
Groll: Pittsburgh Steelers. I don’t know.
Shimel: We finally got her. Carmen, we converted her.
DeArdo: I should have said, “Let’s go Tens.” That’s three words.
Shimel: Okay. Hey, everyone. I will see you both in London June 25th and 26th. Hope to see many of you listening or watching this in London as well. If you’re there, stop by, say hello. I always like to meet people who have watched us online. But until then, this is Alan Shimel for devopsy.kinsta.cloud and IT Revolution. Thanks for watching, everyone, and hope to see you soon. Bye-bye.
As the head of Sonatype’s product development engine, I’ve spent the last six-plus years scaling and hacking on the design and evolution of our fully remote organization. Over this period, we’ve learned a lot about what works, why it works, how to keep things running smoothly and what should be avoided. But none of that would matter at all if it were not for the fact that the fully remote organizational model gives us significant competitive benefits.
Results
As a small and growing company, we’ve had—and continue to have—an impact globally on software development, where roughly $2 trillion is spent each year. Our products and services are used by millions of developers every day with users of our open source Nexus Repository Manager, now in the millions, growing 68 percent last year.
It is rare to have the ability to blaze trails that end up materially helping the world do something better. That’s the epitome of meaningful work, and it’s awesome to be part of it. Sonatype has significantly influenced the way software is developed not just once, via contributions to Maven and its numerous progeny including npm and NuGet, but twice, with the Nexus Repository Manager. And a third big innovation is well underway, with competitors working furiously to try and catch up. Nexus Lifecycle lets development teams automate the effective use of open source.
These innovations with their consistent themes of “Better software, faster” were the work products of our fully remote product team.
What Does the Team Think?
There has been a steady stream of innovations and the business is growing, but how do the members of the Sonatype team feel about the company and the environment within which they are working? Can we accelerate progress and continue scaling the organization?
We are currently rated an A+ (4.9/5.0) and have been trending up over the last year. The high scores here are indicative solid engagement by team members and positive trends are effectively leading indicators of future engagement levels. Additionally, our overall annualized employee retention rates have been >95 percent for the past three years in an industry where the norm is 77.6 percent retention. The remote model certainly doesn’t seem to be hurting us here.
Side note: The dip in the ratings graph was us breaking through a scale point that required some notable changes in organizational design. It seems change is still challenging regardless of the remote model.
The Remote Model
It is still early days for the remote model. The remote organization design is not a common pattern for venture capitalists to match against. For VCs, unfamiliar patterns equate to unknown risk and I’ve been asked about this during board meetings. “Are we riding a tiger here? When are you going to open a local R&D center?” I will readily admit, I had some healthy skepticism very early on; however, my experiences as we have continued to scale have reinforced my position that this is a material competitive advantage for us.
While this is by no means a scientific assessment—Sonatype is invariably a single data point—what follows is at least based on a small mountain of empirical data collected as our product team has scaled beyond the 100-person mark. And I can see an appealing path to 500 and beyond.
Fallacies
“People just work better when they can interact face to face.”
Right … There is so much wrong with that statement that I just smile when I hear it, and I hear it often. While this judgment might seem intuitively correct on the surface, it is not based on anything but gut sense and is always made by people that have no significant experience with a fully remote model. These folks usually have experience or have heard about experiences with the (fatally flawed) mix of co-located and remote models. These are destined to fail for reasons covered a bit later.
What does “work better” mean, anyway? (Yes, those are often the exact words used.) This statement is extremely narrow in scope when you consider broader workday activities. In a typical office environment, how often do you absolutely need to interact face to face to be effective in achieving organizational goals?
Don’t get me wrong. The high-bandwidth exchange of information possible via face-to-face interaction can be extremely beneficial in the more limited cases it is needed and cannot effectively be compensated for through other means. But there is no reason that people cannot get together this way with the remote model. In fact, we do this multiple times per year.
What is conspicuously ignored here is the material “tax” tied to persistent, often ad hoc, face-to face-interactions, which are often (poorly) compensated for by headphones, closed doors and other distraction-reduction techniques.
“You have no idea if people are just off screwing around.”
While I don’t hear this one as much as I used to (is Taylorism finally dying?), do your visual senses really answer this when everyone is on site together? Ever hear of the “boss” key? Regardless of organizational model, you have to be able to trust and verify. There are certainly mechanisms for accountability that don’t require standing over someone’s shoulder. Expectations must be clear and people must have what they need to achieve what is expected. This is standard stuff that has nothing to do with co-located or remote scenarios.
Upsides
There are a number of key benefits that collectively lead to significant gains in organizational effectiveness. The communications are balanced and self-optimizing, distractions are reduced, quality of life is higher and the number of amazing people you can recruit is enormous.
Effective Communications
The most significant benefits I’ve seen in the remote model stem from the level communications playing field that emerges. Everyone is equally “disadvantaged” in not having ready access to high-bandwidth face-to-face interaction. The people we have hired have been quite adept at compensating for this, and we have not had to specifically select for this ability in our hiring.
Another subtle but material advantage is that all communications endpoints are equidistant. It is just as easy to communicate with someone on your team as it is someone on another team or someone in a different department or even the CEO. Everyone is a phone call, email, chat message or video chat away.
It is also largely unappreciated (until you’ve experienced it) how many advantages offset the “limitation” of infrequent face-to-face interaction. First, the communications pathways that form are very often driven by business necessity versus seating location, political motivations, after-work interest or other factors. Second, at least in a product development context with a bunch of technical people that just want to get stuff done, there is more focus on the work and the corresponding results than the political or social aspects of the workplace. Finally, as noted earlier, you can still get together—and should. These engagements are targeted, focused and effective rather than the more ad hoc engagements in the co-located setting. We hold these get-togethers when kicking off significant initiatives and we also get the entire organization together for our annual (open spaces format) meetup.
We also (judiciously) allow people to shift between teams as resource needs ebb and flow, which strengthens the overall fabric of relationships organizationally. It is hard to quantify the benefits here—and they likely span all organizational models—but this reinforces optimal communications and has been very beneficial as we have scaled. We have a far more ambulatory group of people with an extensive network of personal and professional relationships and diversity of expertise across our technology portfolio.
Life is Good
Not having to contend with a soul-sucking, energy-consuming commute on a daily basis is a major quality of life benefit for people. This also comes paired with plenty of options for a more reasonable cost of living for members of the team.
There is something that you do need to watch out for, though. There can be a tendency for people to burn the midnight oil. While this might sound like a big benefit to members of the C-suite, product development is ultimately an ultra-marathon. You have to watch for signs of burnout and ensure people that are falling victim sufficiently dial things back to their maximum sustainable pace. The cost to replace a talented member of the team is far greater than the short-lived incremental productivity of someone working too much.
Near Infinite Expertise
Hiring the right people is a perennial challenge in any discerning organization, especially when you are just starting out. In a co-located model, you are competing in specific geographies, often with better-capitalized companies that have a lot of brand recognition. In the remote model, the number of amazing people you can connect with is effectively infinitely larger. We are able to open a really big door. When you are also able to eliminate the commute and offer challenging work that matters, a lot of exceptional people can be convinced to walk through it.
One Note of Caution
Time zone overlap is a key consideration. There must be adequate overlap and we have this around the U.S. Eastern time zone. We span 10 time zones overall, from Central European Time to U.S. Alaska Time, and that is a stretch in some respects. Team members at the edge compensate by shifting earlier or later into the work day when needed, and this has worked well. Regardless, sufficient overlap is critically important. Spreading out any further than we are today is likely untenable, as the time shifting would likely lead to unsustainable quality-of-life challenges for people that are geographically distant.
Avoid a Mixed Model at All Costs
While scorned by many when she abolished remote working at Yahoo, Marissa Mayer was ultimately right to unify the model … she just chose the wrong model! (Actually, she probably didn’t, given the existing scale.) You can’t effectively mix co-located and remote models across an organization. This is because it is impossible to create a level communications playing field, or maybe you could but the effort required to level the field would drive effectiveness to zero. It’s simply human nature at work.
Co-located members end up forging stronger communications channels and the channels with remote members weaken. Remote members become more isolated as seemingly innocuous interactions among the co-located people occur without them.
This isn’t to say that people can’t work from home occasionally in the co-located model. This certainly works. However, you cannot achieve optimal organizational communications at scale with a primarily remote group of team members mixed with a co-located group.
Perhaps you can mix modes, as long as you have a consistent mode across individual autonomously operating teams. We have not tried this, but I also sense this is not without material challenges and I have heard of some failures. I’d argue that many of the challenges tied to offshore development share similar root causes, leading to debilitating communications imbalances.
At scale, there is still the equivalent of a team (or teams) that ultimately support these autonomous teams, often with some members of these supporting teams being part of the autonomous teams as well. This forces you to contend with a mixed co-located and remote model one level up and likely leading to (again) imbalanced communications. While this perhaps can be made to work, the real question is whether it can work with a sustained, high degree of effectiveness at increasing levels of scale. I remain skeptical.
Compensating Mechanisms
While there are significant benefits, the remote model has some challenges. These are the kinds of things you might expect, but thankfully, there are effective ways to respond.
Product development is a team sport and the remote model affords a lot of opportunity to go off on your own. The lone wolf might flourish for a bit, but to scale, you need people who will reach out to others and solve problems with them, proactively. While this is true in any organization, I’ve found that it requires more vigilance to keep this in check in the remote model. Do not let bad habits develop.
Similarly, it’s more difficult to stay mad at someone when you see them on a daily basis. I think most humans are probably about 99 percent irrational and 1 percent rational. Unicorns might have a 90/10 split. Regardless, many of us are absolutely amazing at seeing negative things that just are not there. The remote model can exacerbate this, and it can “take a village” to keep everyone grounded in reality (rational thought) rather than assuming the worst and starting a downward spiral. Just being aware of this goes a long way, making it easier to keep the irrational majority in check. Having a “no a-holes policy” is certainly useful, but pretty much anyone can still appear to be acting like an a-hole at times. Don’t console those griping about someone else. Push them toward reconciliation.
The Lounge
We created a chat room many years ago called “The Lounge,” a sort of virtual water cooler. Many other remote organizations have done similar things, and for us, this has been enormously beneficial in bringing “humanity” into the remote workday. It also helps connect people in otherwise distant parts of the organization. While it is not the same as getting together with people in person, it goes a long way in giving people a social outlet during work. Abuse has not been a problem, either.
We’ve more recently started a number of special interest groups and guilds, all of which have their own chat rooms along with more topical banter. And most recently, we created a Google Hangout version of “The Lounge,” which has been a surprisingly effective social exchange. It seems hearing and seeing real laughter goes a lot further than reading “LOL” or observing some emoticon or emoji.
Get Together, Live
As noted a few times already, it’s important to get people together, in the same location, at key points. This is common advice in most of the other literature I’ve seen on remote models. These face-to-face meetings strengthen individual relationships that tend to slowly erode over time given exclusively remote interaction. We’ve found that a year is just too long and I’ve picked up on subtle cues from the organization as we have approached the nine-month mark. While there are numerous factors in play, my experience tells me that six months is likely the sweet spot for this. The timing might vary from organization to organization depending on the nature of the work, but reasonably strong social bonds are an important factor in holding everything together.
Online Interaction
In addition to getting together, the effective use of video goes a long way for multi-party exchanges. Body language is often useful, especially in the cases where vigorous discourse is needed. For 1:1 interaction where you don’t need to exchange visual information, voice is a personal preference, primarily because with my wireless headset I can walk around, keep my blood flowing and concentrate far better, really listening and picking up on subtle cues voiced by the person on the other end. Random factoid: My FitBit reports that I’ve walked a few half-marathons during some days without ever setting foot outside.
Wrapping Up
When contemplating a fully remote model, be prepared to go all-in at the point you do. Do not, under any circumstances, attempt a mixed co-located/remote model. That is a certain path to failure. Beyond a certain organization scale, the fully remote model is likely impractical if not impossible to migrate to effectively. I have no empirical data to support this, but if your organization is fewer than 20 people, the challenges of adapting to the remote model are going to be simpler. Beyond this scale, there is inevitably a lot more organizational complexity, not to mention business risk tied to the short-term productivity drop as everyone adapts and learns how to work in the materially different operating context. I’m not stating outright that you won’t be able to make the move beyond 20, but you should expect the challenges to be far greater and the time to stabilize longer.
With the experiences I have had and the advantages we’ve realized with Sonatype’s remote organization, I cannot imagine choosing the co-located model if faced with the challenge of scaling an enduring product development organization from early days. I still have fond memories of sitting in a bullpen environment on University Boulevard in Palo Alto years ago. Without a doubt, the bullpen is a great model at the outset, when things are fluid and the requirement for high-bandwidth exchanges is nearly constant. However, the moment you are ready to scale beyond that initial bullpen, remote should be a serious consideration. If you are growing, the option won’t be available for long.
As DevOps Enterprise Summit San Francisco (DOES17), slated for Nov. 13-15, inches closer, event founding partner Electric Cloud hosted a special episode of Continuous Discussions (#c9d9), featuring some of the conference speakers. During the discussion, the speakers shared some of their recent DevOps transformation stories and a bit about what to expect during their talks at the conference.
The panel included:
John Esser, senior director of IT and data center operations at AdvancedMD;
Gary McKay, scrum master at Somos;
Aloisio Rocha, agile product owner at NetEnt;
Manish Aggarwal, software engineering manager at Intel;
Marc Priolo, global software configuration manager at Urban Science;
J. Paul Reed, managing partner at Release Engineering Approaches;
Marc Hornbeek, principal consultant – DevOps at Trace3;
Gary Gruver, founder and CEO of Gary Gruver Consulting; and
our very own Sam Fell and Anders Wallgren.
Here is a list of the most memorable takeaways from the discussion:
Every company is different, so approaching a DevOps transformation will vary based on the organization, explains Esser. “Every company has a different set of constraints, a different culture, different things they value. So you can’t just say, ‘Oh, I’ve got this DevOps hammer, and I’m going to start pounding away.’ We understand the principles, but how to apply those and how to execute those principles are quite different.”
McKay on the success of moving from mainframe to microservices with his “Team Dragon” concept: “Team Dragon was formulated to make sure that our CI/CD process as well as our deployment and release processes were consistent. Coming from a mainframe environment to, say, a distributed microservices environment, there are differences not only in culture, but processes and technology. We wanted to make sure all that was managed efficiently and effectively, so that we could do deployments when we needed to do deployments.”
Rocha on the NetEnt DevOps journey and what inspired the transformation: “We’ve gone from a place where the business was expanding, but deployments and deliveries were not scaling with the business to working on how to tackle it with automation, working with the deployments and making the deployments visible to everyone.”
Aggarwal will be talking about the DevOps journey at Intel at DOES17: “I will be covering as to how a lot of organizations, including Intel, are trying to board the journey of DevOps. They are successful to an extent, but how to make sure that the quality, which is the sole purpose of this journey, does not get left behind.”
Priolo on his pipeline-as-a-service strategy: “We have a pipeline-as-a-service strategy. That’s where we want to make sure that our developers can concentrate on developing instead of trying to figure out how their code is getting into our production environment.”
Gruver’s simple advice on starting your DevOps transformation: “In the beginning, you need to create some positive momentum. You need to find the things that are the most broken in the development and deployment operations. You need to highlight them. You need to get them fixed. Then you need to market those changes, so that you get some positive momentum for the transformation.”
Don’t forget about the human factor of release engineering, says Reed: “[At DOES17] we’re going to be going through a little bit of the human factors that are related to release engineering. There’s a couple of facets of that. It’s sort of, ‘How do you go about doing the work,’ and then also a bit about how we treat others, the net system.”
It’s important to include all teams on your transformation journey, per McKay: “The secret is inclusiveness. Making sure that the mainframe team is part of the microservices process and making sure that we, in our haste to get things done very quickly and very effectively, make sure that we bring them in. We make sure that their roles are purposeful and that they’re part of the process and not just, ‘Oh, you’re just some mainframe guys. We’re just going to ignore you.’”
Esser on the core values of DevOps: “DevOps as a whole is not limited just to an architecture. DevOps, at its core, is about working better together and increasing the flow of value across the whole value pipeline.”
It’s important to find the right balance between allowing your developers to be unique, but also adhering to the rules, says Priolo: “The real challenge is trying to find out a way to allow developers to still have their snowflake ability, while still complying with the standards of the company. It’s not to make everything stringent and follow the same exact path. It’s to create a pipeline that gives them the flexibility, but still gives us the ability to do auditing, to make sure that the code is being checked at its proper place.”
Sometimes it takes a big mistake or bug to make you realize you need DevOps, explains Rocha: “Our process was intense before, to say the least, especially when some scary bug came or a heavy compliance requirement came in that we had to fulfill in a short amount of time. That made us realize we have to fix this.”
Wow – Aggarwal’s team at Intel went from almost complete manual testing to 100 percent automation in seven years: “When we started about seven years ago, 99 percent of our testing was manual, and everything was repetitive. The work was getting more challenging, and the sheer amount of it was growing with every release. So it was very important to bring that under control. The only way of doing that was end-to-end automation. When I say, ‘end-to-end,’ it’s not 99 percent. It’s 100 percent totally touchless automation.”
Reed on the human factor of versioning: “Versioning really is about humans communicating with each other. They’re trying to encode information into that version number, which is, I think, one of the reasons you see people bikeshedding that a lot.”
DevOps can expose your longstanding problems, says Gruver: “When you start trying to increase the frequency of build/test cycles or deploy cycles, you see inefficiencies repeating. You see the trends. There’s a bunch of tools in the DevOps toolbox that enable you to go after that.”
Moving from monolith to microservices is not an overnight transition, explains Wallgren: “Time and time again we hear the difficulties that everybody has with legacy applications or monolithic applications. The transition away from mainframes is not an overnight kind of thing. They’re not going anywhere, anytime soon.”
There’s still value in mainframes, and getting that to customers is key, explains Fell: “There’s a ton of value locked up in mainframes and being able to get that out to other people in a service-oriented sort of way. It’s a hard migration to do, but that cultural aspect of making teams feel like they’re comfortable working with one another is critical to getting through that part of the process.”
Watch the full episode:
About the Author / Anders Wallgren
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.
There is quite a bit of conversation about tools versus culture, and sometimes, those constantly involved in the back-and-forth forget that not everyone is so steeped in the finer points of the conversation.
Tools is the easy part. There are a ton of tools available to optimize IT operations, from small bespoke products such as the Antsle Private Cloud Server to CA’s broad suite of Dev/Test/DevOps/ARA tools. There are plenty of places to find lists or charts of tools, and I’ll leave you to them, just mentioning the two I’ve written about in the not-too-distant past: Xebia Labs’ Periodic Table of DevOps, and CA/Automic’s Continuous Delivery Landscape.
My youngest just built a Cube-solving robot, so this picture inspired me.
But what of culture? When pundits and old hands talk of culture, what exactly are they talking about?
Well, it still varies a bit from organization to organization, but there are some definite underlying foundations.
Increased Cross-Team Communications
Even if an org is full-on DevOps, there is still the requirement of cross-team communications to make sure everyone understands what is going on.
One of the things that this does not make abundantly clear, I will belabor a bit (sorry, old hands). Communications is not just talking. It is not just email exchanges, it is not just sitting in another team’s meetings while researching your current problem on your phone.
It can be these things, but it is a breadth of options. People are using Slack channels to keep everyone updated, common notifications or even pub-sub systems to make certain information about the state of IT, operations and builds are getting wide distribution. Increase communication, not chatter.
Organizational Change
You hear that a lot, and it can mean complete overhaul of an IT organization, but in an enterprise setting, it rarely does. The reason is simple. There may only be one or two Cisco specialists, or one or two EMC specialists, and these people don’t properly belong on one or two product/project teams in the long term. The same goes for security and a whole further swath of operations team members.
So in the enterprise, what “organizational change” often means is moving those responsible for development and core deployment closer together on small, product- or portfolio-based teams. Networking staff, security staff and infrastructure staff will join the teams as needed, but are not part of the core team.
Management Change
This is another often spoken-of mantra that easily can be misunderstood. In short, managing a small, agile, entire product lifecycle team is not the same as managing a pool of resources that pop from project to project and are either (a) not involved in the operations portion at all, or (b) not involved in the development portion at all.
For a great set of perspectives on this topic, I’ll recommend our partner The DevOps Institute. It has an eBook and a certification course (DevOps Leader) on this topic.
Decentralization, Yet Increased Oversight
This is often a confusing pair of messages we send when talking about what DevOps culture change does. It really is not that complex—pundits just assume everyone already knows, and, honestly, those knee-deep in DevOps do know.
Decentralization, as taught in the DevOps Leader course mentioned above, is about driving as much decision-making as possible down to the team. When teams are built around a product or group of products, then those with the most pertinent information about what is best for the product quite often can be made within the team, speeding decision-making and implementation.
Increased oversight is an acknowledgement of two things. First, there is more information available in an agile environment, and that information is available more frequently. Standup meetings offer some, while milestones offer other data. Second, tools are starting to allow rollup of information in a uniform fashion for CIOs, CTOs and business leaders to look at. This means they can quickly see the status of projects they have a vested interest in and provide feedback into the process. To go from, “Oh, this roadmap item is going to take a lot more work than we thought,” to, “Great, we have a plan, let’s keep moving,” is shorter when there is more information available to the decision-makers on both the business side and the IT side.
There is no doubt plenty I have missed, but these seem to be the core things that those of us discussing this topic a lot assume others know, and that those just looking into DevOps really don’t. Hopefully it will help someone push through the clutter and come to a decision on DevOps in general, or culture changes in particular.
The DevOps approach has several clear-cut benefits with the value centered in several key business areas: improved market agility, increased quality and revised culture of cooperation and effectiveness in staff operations. By promoting and implementing a DevOps culture in your SME’s business, Dev and Ops teams align much closer together and can better share in-between knowledge. This lets you create products more fluidly and increase deployment rates. The time for evaluating the business idea, development, testing and moving the finished product into the operations department is reduced dramatically. Quality margins improve, and this feeds back into the ability of your teams to continually fine-tune the products you offer.
Businesses see a point in adopting DevOps only if it is directly contributing to the company’s increased effectiveness, productivity and, of course, profitability. The only way that it is possible for small and medium enterprises (SMEs) is when their IT and DevOps teams are working in sync and streamlining the provision of tech solutions that solve the business needs. And only a successful and timely DevOps adoption inside your organization will help your company beat competitors and stay afloat as the development across the industry speeds up.
In the last years, we’ve seen a tremendous application delivery shift in businesses. We’ve moved away from the old ways of having large-scale system implementations based on one single project and its continued maintenance. SMEs now perceive application delivery as a continuous evolution. DevOps plays a leading role, as this software engineering trend ensures that such a major shift is possible. It brings all of the different parts of the enterprise together: business, development and operations teams collaborate on a different, more in-depth level with a goal of automating processes. This helps eliminate the usual constraints and takes the time-to-market issues off the table.
In the latest ECS-Digital research on adopting DevOps in businesses, 57 percent of SMEs have partially implemented DevOps practices in their daily routine. The key benefit of DevOps for them is improved inter-departmental collaboration. But for the 43 percent that haven’t yet adopted DevOps, the collaboration issues are among the last priorities on the list.
Step-by-Step Guide to a High-Level DevOps Life Cycle
According to IBM Cloud Director, the end goal of a relevant DevOps practice is to cut the development time and improve enterprise’s efficiency. A growing business has to start from the “business needs” of the company and go down the road to make it come to life. The goal of adopting DevOps in your company is to push your business needs into production at a quicker pace more reliably. The goal in any DevOps practice is to cut the time and increase the efficiency of processes. You need to move from the “business need” to the “it’s live!” stage.
Business Needs are a DevOps Priority
But does your business have to get involved? Of course, your SME leadership focuses on the “business needs” of your company. But when we look at organizations that have implemented proper DevOps practices, the internal structure of the company shifts to focus on delivering great business results across the whole life cycle of your product/services offering.
DevOps also ensures that employees have the ability to correct their work direction during the whole lifetime of a project. Things and goals tend to change, competitors may roll out some features that may make some of your project’s parts trivial, and all of this makes the need to adjust your project accordingly. This is easily done when your business need is close to both the Development and Operations teams that are able to steer and drive this alignment of goals.
Have a look at the infographic below that clearly shows how a DevOps delivery cycle looks like:
The Clash Inside Organizations
Measuring the impact of DevOps on the things that matter to business is vital. Most SMEs are experimenting with DevOps, and there are some within the company who want to prevent DevOps adoption. The culture within enterprises is shifting too drastically and dramatically, although the effects are mostly positive.
Such a shift is impacting all operations, with software development impacted the most. SMEs have it easier to change and adapt compared to larger businesses, and this lets them move the workplace culture a step ahead of their larger counterparts.
If we look at business, operations and developer teams from a historical point of view, it was never a goal to establish inter-connection between them. The teams started cooperating only when it was absolutely necessary to get the other team’s input. SMEs are still faced with such a separation, as most responsibilities are set in stone for each team and the individual employee. All business units are used to working in their closed-in niche, and there is a lack of will to leave the comfort zone and act outside the predefined roles. Such actions in the past could have been viewed negatively.
While most businesses that want to implement DevOps have employees who want the business to prosper, it can be difficult to force people to act outside their duties. However, to reach the end goals of any business—namely, ensuring fast and quality product delivery—and solve issues on the go, people must interconnect their duties and reach outside their business unit. With proper DevOps application, such collaboration can be smooth and result in the improvement of cross-functions.
DevOps Represents Change in Internal Business Structures
Many SMEs are faced with internal structural issues that limit the company’s prospects: Engineers are not willing to be on-call, the Ops team has a negative attitude toward those who write code and executives are slow to embrace automation. Organizations must overcome the culture war to be able to approach the agility and productivity gained by a DevOps model. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.
DevOps culture looks very different from organization to organization. However, regardless of the business implementing a DevOps approach, the potential benefits are the same. From faster deployments to increased efficiency and cultural changes toward experimentation and away from rigid planning, a DevOps culture has the ability to transform an organization completely. Wholeheartedly adopting a DevOps culture has real implications on how well a business is positioned to take on the market. With many industries facing uncertainty and a host of upstarts disrupting the status quo, shifting to a DevOps culture can be an important weapon in repositioning your business.
Empathy is the Core of DevOps Adoption
One of the foundational ideas behind DevOps is mutual empathy. Having empathy from operations toward developers and vice versa, as well as empathy in other business-related and non-technical company units, remains vital. It’s not about patting your colleague on a shoulder. We are talking about the moral mandate of a developer who just creates their part of the software and doesn’t care about how it can be deployed in production. The goal is to push employees to think outside of their small task, and to take into account the outcome of their work: Is the developed app secure? How hard is it to deploy it? Is it easy to keep it running? etc. If those questions are not accounted for, the developer’s colleagues on the Ops side will pay the price if something goes wrong past the release.
By ensuring that the SME has empathy for each other at its core, businesses will deliver better products/services. And doing just that is what DevOps aims to bring to companies. Until this idea is ingrained, DevOps will face a cultural war of sorts.
Your Most Valuable DevOps Resource
By considering to adopt the DevOps approach to running your SME, you can better rethink the ways your organization operates—how it deploys its teams across the enterprise and how often it addresses structural problems that appear over time. Now you can lay out a new foundation for your SME based on the culture of cooperation and experimentation. With proper guidance in the application of DevOps culture, you can address the waste of time, human resources and money in your business.
Becoming a DevOps organization is no easy task and taking up on such a challenge requires faith that changing the existing processes will bring its benefits. Reworking and optimizing organizations is the new norm, regardless of their size, industry, and goals. The faith in DevOps culture is driven by the firm and quantifiable statistics, but the intangible benefits to corporate culture are just as compelling. Many businesses are looking at implementing DevOps, and even more, SMEs are in the active process of its application. When your company is delivering quality ahead of time, there is a strong chance your competitors will be left behind as you are getting the bigger piece of the pie.
Key Takeaways
To stay current, businesses need to adapt to an ever-changing environment, respond to competitors and stay on top of the innovation cycle, increasing customer value via responsiveness to change.
Increased service quality depends on both the availability of the service and being able to restore the service to an error-free state. Thanks to fast feedback loops and high release velocity, service breakdowns can be removed much more quickly than in the past.
DevOps are built on the sound principle of waste reduction such wait times and process overhead due to continuous improvement. This helps to improve agility and has a positive impact on costs.
Fostering continuous learning and improving culture through efficient principles is what DevOps is all about. In a fast-paced, unpredictable environment, non-stop improvement is paramount for sustaining your competitive advantage. It is also important for attracting exceptional talent and keeping employee satisfaction at a high level.
About the Author / Stephan Pushkarev
Stepan Pushkarev is the Head of DevOps Practice at Squadex.com and CTO at Hydrosphere.io. Co-founded and managed engineering teams for eCommerce, IoT and Ad-tech companies. He is responsible for the full products stack: math models, infrastructure & operations, enterprise applications as well as recruiting, establishing engineering culture and delivery processes. Stepan combines strong technical and managerial skills, and entrepreneurial spirit. Connect with him on LinkedIn.
The automation of software development does not obviate the need for a collaboration between IT and the lines of business, or the development of a culture of quality on the part of the development team. Achieving that quality culture requires more than a change in mindset as developers seek to align quality with the speed and automation goals of DevOps.
There are five items required for a quality-driven DevOps environment:
Understanding the proper role of “minimum viable product”
Collaboration between IT and lines of business
Having metrics in place
Across-the-board buy-in
“Quality culture is characterized by employees who are motivated to consistently strive for the highest level of quality,” said Al Riles, principal consultant at Tunnell Consulting, a firm providing solutions to the complex problems faced by life sciences and biopharma companies. “That’s one key component of it, as well as the ongoing process of continuous improvement.”
Minimum Viable Product and Continuous Quality
Aligning quality with the speed and automation goals of DevOps is critical to success, and part of this is gaining a deeper understanding of the role of “minimum viable product” and understanding when that approach contributes to the development process.
“The concept of ‘minimum viable product’ does not, as its name would suggest, contribute to a substandard product,” said C.R. Venkatesh, CEO of Dot Com Infoway, a CMMI Level 3 IT company. “Quite the contrary, the concept is the basis of continuous and iterative improvement, and encourages the use of user feedback, which often results in insights that might be missed by the in-house team.”
The concept of quality culture and MVP are not mutually exclusive in a DevOps environment, so long as continuous improvement is part of the equation.
Collaboration Between IT and Lines of Business
The collaboration that is a key part of DevOps is also a key part of quality culture. “You have a culture in place where everyone embraces that fabric that includes the right type of behaviors and the right values, including communication, reward and recognition, as well as clarity on roles and responsibilities,” said Riles. “That working fabric gets well-defined, because everyone is functioning around the same key elements that constitute that strong corporate culture.”
“Collaboration has always been important in a DevOps environment,” said Venkatesh. “But we need to define precisely where that collaboration exists. In an internal environment, that collaboration is between IT and lines of business. Increasingly though, IT and development is an outsourced function, and in such cases, that collaboration must be preserved. What this means is that it exists not just within the confines of the outsourcing provider, but also between the provider and the client. The developer must seek out alliances not only with the client’s sourcing manager, but also with other internal stakeholders in the project.”
If You Don’t Measure, it Doesn’t Exist
Quality initiatives require an active role in changing the mindset of all stakeholders, but mindset alone won’t get the job done. Metrics must be in place and tied to those quality initiatives. “Even in the smallest of development projects, defined quality metrics must be set ahead of time, with clearly defined outcomes,” said Venkatesh. “By asking what we hope to accomplish with a development project, clearly defining the goals and adhering to a set of predefined quality standards, developers—whether in-house or third-party—are able to accurately predict what the outcome will be.”
Riles’ process involves a quality management maturity grid, which identifies multiple dashboards. “It allows the organization to become familiar with what a quality organization consists of, and then you can use this maturity grid to measure where the organization is once you embrace this initiative. Then, you can implement the initiative, and come back and re-evaluate yourself to see the progress you’ve made,” said Riles.
Everybody Has a Seat at the Table
Incentivizing all stakeholders, throughout every level of the company, is paramount and, according to Riles, “It has to do with communicating what the vision is, and having a clear quality message that’s coming from leadership. Then, there has to be a shared quality mindset among all staff.” Riles notes that the quality mindset is shared by everyone in terms of understanding the organization’s objectives, policies and procedures and their roles in hoping to achieve them.
This is reinforced by leadership at all levels, who are actively engaged in supporting the development of a quality culture, and they engage and motivate others to do the same. For it to be sustainable, we realize that success is based on the sum of all parts of the organization. They must be continuously monitored and fine-tuned as the organization grows, and this includes communication, reward and recognition, and engagement.
Allow me to share a secret: My handwriting is atrocious. If it were not for the keyboard upon which my fingers are tapping and the laptop that is processing the result of my taps, this article would not be happening.
I’ve always had poor handwriting. But, it’s gotten worse over time. Other than the occasional grocery list, I don’t write things out by hand anymore. It’s just me and the keyboards on my laptop and phone. Luckily, my mind still works—sort of. The stuff I produce has gotten better. Using a computer allows me to edit faster. But, I don’t retrieve words as quickly as I used to. I find myself using online tools continually during a writing session. I could blame age for the impediment. And that may be the case. But still, a part of me says, “Why remember words when I can just grope around a thesaurus to find what I need?” That I can still spell most words correctly is a bit of miracle. But then again, a computer has been correcting my spelling for the last 25 years.
I’ll share another secret: I don’t remember phone numbers anymore. At one time, I had all the phone numbers associated with all those close to me committed to memory. I knew the phone numbers of my sister, parents, in-laws, friends, steady customers and even my favorite restaurants. I didn’t have to look anything up online. I just carried the numbers around in my head. Now, the only numbers I have memorized are my own and my wife’s. When I want to talk to my sister, I look up her name in the contact list on my cell phone and hit the “call” button. When I am in my bluetooth-enabled car, I just say, “call sister.” The machines do the rest.
I can still sum a short list of numbers in my head. Also, I can multiply two numbers together as long as neither number is greater than a thousand. If I want to do multiple operations—say, add some numbers up and then divide by another—I need to use a calculator. I haven’t tried to do this sort of arithmetic on paper in a long time. Maybe I can, maybe I can’t. Dunno. It’s just easier to use a calculator.
I still read a lot. But I find that I spend more time learning things by watching videos on YouTube. In fact, I just got through brushing up on JMeter by watching a playlist of 20 videos on the topic. It took me about two days. I can’t remember the last time I spent two days completely engaged in reading a technology book. It’s embarrassing to say this, given that I am a technology writer.
But, there is good news here: I can still make change. I learned how to do this before cash registers reported the change to give back upon purchase. You start with the sale amount and work your way through the cash drawer taking out coins and bills until you reach the amount the customer gave you. Funny that I should remember this small piece of mental acrobatics. But, then again, I haven’t used a cash register in a very long time. Making change has yet to be made simple for me.
However, the computers I use continually throughout my day make things very simple. They allow me to write out my thoughts clearly. They tell me when to pay my bills. They correct my spelling. They make going to the grocery store a breeze. I just take want I want from the shelves, put my credit card into the card reader at the automated checkout line and pay only what is due—no cash required, no change made.
Automation has made me really smart in a few areas and helpless in most others. I can design an elegant microservice. I am wicked good at working my way through the ins and outs of Amazon Web Services. I can create the automation code that tests my software so that Jenkins can move everything along the deployment path easily and reliably. Yet, I have no idea how to fix my car when the warning lights go off. I don’t know how to repair my cell phone when it stops working. If my voice-responsive TV no longer delivers video on demand, I’m not even sure who to call. The cable company? Netflix? Linksys? Samsung? Denon? When my microwave breaks down, I throw it out.
My world is simple on the surface and yet terribly complex underneath.
At one time, the complexities were more apparent. Information was not at our fingertips. Research meant hours in the library poring over the card catalog. Chemistry was part of professional photography. Acting meant memorizing a script that had to be recited over a period of hours, not minutes. Things were more difficult then. But, we sort of figured it out. We had the ability to negotiate the complexities of life. We had no choice. The machines had yet to be invented.
Now the machines have been invented. Overall, they have been good to us. Smallpox is gone. Lasik is here. Doors open before us automatically, no pushing required. Delivery is overnight, if not same day. Should I want to run my program on a supercomputer, all I need is an AWS account bound to a credit card. Just 1 percent of the population in the United States feeds the rest of the country. We don’t lack for toilet paper.
Technology is a wonderful thing.
But, I can’t help but wonder what becomes of a culture when everything is automated to essential simplicity. What happens over generations when we no longer need to know how to write legibly, remember a phone number or make change? How will our minds work when the stuff that used to make our minds work goes away? I don’t know. I am still trying to figure it out. In the meantime, I’ll leave it up to you to decide.
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a 
Dan Blacharski is a thought leader, advisor, industry observer and PR counsel to several Internet startups, and author of the book “