DevOps 2020: An Interview

We sat down with our friend and community expert, Jono Bacon, to ask him about his views on the future of DevOps.

Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, developer workflow, and other services. He also previously served as director of community at GitHub, Canonical, XPRIZE, OpenAdvantage. His clients include Huawei, GitLab, Microsoft, Sony Mobile, Deutsche Bank, HackerOne, Mattermost, SAP, data.world, Creative Commons, and others. He is the author of the critically-acclaimed The Art of Community, is a columnist for Forbes and opensource.com, founder of the Community Leadership Summit, and co-founder of the Bad Voltage and LugRadio podcasts.

See the full interview transcript below:

What would you say to executives that are considering implementing DevOps practices? What is the first step they need to take/thing they need to consider?

I think what I would say to an executive considering a move to a new model or methodology is to really understand what it is and what the benefits and the risks are. DevOps and the DevOps way of working has shown pretty consistent benefits. It typically reduces time to market and improves quality. It makes your engineering staff happier. It improves cross functional collaboration after it reduces overall costs. But it’s not a silver bullet and there are going to be some risks attached to that.

What’s interesting to me is when you look at something like DevOps is we often talk about the pipeline and workflow. How do you write code and build it and do tests and package it and do configuration management and deployment and all these different pieces? And we typically talk about the infrastructure and the different pieces that glue it together. But there’s also a significant cultural component. If you’re moving from one way of working to another way of working, then typically you’re going from one culture to a different culture and that’s got all kinds of psychology and expectations and tooling and all these different pieces that are involved.

So what I always recommend — well, let me tell you what I think you shouldn’t do is a lot of companies that I’ve seen who do this, they essentially say, “This is the new way of working” and they build this big machine and they roll it out to the company and they get limited traction. And the big chunk of the work that I do with startups is helping startups to move to a new way of working or building a new culture or a different culture. What I found that works best is to start small and say, “In the next two months, we’re going to do this. We’re going to build this thing. We’re going to put these pieces in place. We’re going to incorporate some of this in some limited teams” and then to do it and see how well it works, to get extensive feedback and to design for failure. Presume that this is going to go wrong. What happens when it goes wrong? Because I think when you’re building things for people, I think the answers to how to do it the right way are invariably sitting in the heads of the people you’re building it for. If you want to build a great developer platform, developers know the best way to write code invariably. So the key thing is to do something to get that feedback, to suck that information out of those people’s heads and then to iterate and improve. The other benefit you get there is that you’re building something that people can adapt to. You’re not presenting this big new thing and saying, “This is the way of working.” I find that approach makes it easy to transition to something such as the DevOps workflow.

Is there an ideal profile of a company that would most benefit from DevOps?

Not really. I think that DevOps can be applied to most companies. Obviously, you typically need to have some kind of development and operations involved. If you’re making wool for a living, it’s probably not very interesting to you. But I’ve seen DevOps as a methodology applied in a bunch of different companies from large enterprise organizations to small startups. I think it’s particularly noteworthy in those companies that are going from a small startup into a much bigger company where in the earlier days, you’re just like get on with it and do what you need to do and you provision resources and you provision infrastructure and you write code. It’s a one-on-one relationship with a certain set of people. When you get much bigger and you’ve got many more teams involved, it can get much more complicated to do that. You can’t necessarily be as agile. And I think that’s why DevOps provides a nice framework and a modeling which you can operate. I think it can apply to most companies.

What is the benefit of applying AI to DevOps? Is there a downside?

I think there is a huge opportunity for artificial intelligence in DevOps and beyond as well. When we look at methodologies such as DevOps, they’re really designed to optimize for certain types of behavior and outcomes. And there’s methodologies designed to mitigate against the kind of negative behaviors and negative results that you typically tend to see when people collaborate together in a perfect way. But still, inside those methodologies there’s lots and lots of details. How people write code and how people file issues and submit pull requests and how people write and run tests — there’s all these different components that fit into that. I think AI shows huge promise for essentially being a virtual agent that is able to look at some of those actions and to help guide that collaboration in the right kind of direction.

As an example, a lot of companies and projects deal with the problem of bug triage. People file loads and loads of issues not just for problems but also for feature develop or things they’d like to see. And then you really need to triage those issues to make sure the right resources get assigned to them. AI could arguably be looking at those issues and do that triaging on your behalf and then to be able to resource it sufficiently or at least put it in the hands of the right kind of people. There’s huge promise for how AI can, not necessarily replace humans, but to augment humans with the right kind of information, with the right kind of decision making to optimize how that collaboration works. And there’s not a lot of that in place right now and that’s where I think there’s going to be a huge opportunity in the future.

What would you say to those executives who believe DevOps is just reinventing the wheel of Agile, CI, CD, etc?

That’s a great question. And I wouldn’t blame an executive for thinking, “This is just reinventing the wheel.” My view is there’s lots of different ways of working. There’s Agile, there’s DevOps, there’s objective key results, there’s Scrum and things like continuous integration and deployment, etc. And what I would recommend is to look at all these different things that are available that you hear from your colleagues and friends or associates in the industry, to understand them at a high level and to see what you think is going to offer value to your particular company. No single one of these is going to be perfect. No single one of these is going to be a silver bullet. It’s best to look at them and see what resonates most with you. The thing I think is neat about DevOps specifically, though, is while it’s not a specific platform, it is a fairly consistent methodology and process that has shown pretty consistent results. I think it’s a great place to start and I don’t think it’s necessarily the reinvention of the wheel. I think it just fills in a big chunk of the puzzle. But there are other bits of that puzzle that will still be missing that you’ll want to glue in there as well. That would be my take.

What is the downside to implementing DevOps? Where do companies get it wrong?

I think there are two main mistakes that a lot of companies make here. The first thing is they build this big, comprehensive machine that they expect people to move to. It’s almost like the philosophy here is we need to move from this one thing to this new thing, DevOps, so why don’t we just rip off the Band-Aid, build the new machine that we’re all going to be using, and then we’re done. Yeah, there will be some bickering and complaining at first but it will pass. I think that’s a mistake and one of the main reasons why that’s a mistake is it doesn’t provide an opportunity for your audience to actually feed into the design of the thing that you’re building. No matter how smart the people are who are going to be leading this transition to DevOps, they will become smarter when they learn from the audience that’s going to be consuming it. That’s one of the reasons I always recommend having a cadence around this. Let’s say it’s two months. You say, “At the beginning of a two-month period, we’re going to do these things. We’re going to put these pieces in places — this infrastructure, this tooling, this workflow, this training, this outreach, whatever it might be. We’ll do that for two months and learn from what we did and then we’ll use those learnings to inspire what we do for the next two months. And then you iterate, you iterate, you iterate.

The other mistake that a lot of companies make in this area is they force it onto people. They build this big machine and they say, “That’s now how it works.” And that’s just not how people’s brains work. People typically need time to adapt and adjust. If you go through that iterative process where people can play a role in that, where they feel like they’re playing a functional component in how this new methodology is going to be brought into the company, not only is it easy for them to make that transition but they actually feel a level of ownership in that transition. There’s all kinds of behavioral economics and psychology that backs that up. So if you’re view is, “Let’s build it and they will come,” I would build some of it and invite some of them to come along and I think you’ll get better results.

DevOps, top-down or bottom-up — what’s the best approach?

I think this is a great question and I get this question all the time from my clients. Is it better to move to a DevOps way of working with more of a top-down approach or more of a bottom-up approach? I really think it’s both. What we’re really talking about here when you move into a new methodology is that it’s a new workflow and a new culture. And I think you can’t succeed in building that workflow and culture unless you do it in a permissive environment. And that’s what the top-down approach gives you is that you want your leadership team basically saying, “We’ve evaluated this new way of working. We think it’s good for the company. We think it’s good for all of you folks. We think it will help you to do better work and have more enjoyable ways to work and we’ll build better products and services that serve our customers better.” But it needs to go beyond that permission and actually be inclusive as well. You want to say to a team, “We want you to join us and help shape this and feed into it and to mold it into a way that works best for everybody. We want you to fail and to learn from those failures so we can all succeed in a much better way.” I think that’s really important.

But that’s not enough. I think you need the complement to that approach which is the bottom-up approach. That’s the execution. You need to have infrastructure that people can get access to, clear processes for how people use it and training. You want to bring on board different teams and have many roadmaps for them to adapt to it and have mentoring programs in place. I think that complement of that permission from the top-down approach and that execution from the bottom-up approach, with that short cadence of cycles, a couple month cycles, is really the best way in which you can make this work.

What does DevOps mean for the future of ops and software development teams?

That’s a good question and I’m going to level with you. I’m historically very, very bad at predicting the future. In fact, if I predict something is going to happen, it’s typically the opposite of that thing. I thought the iPad was going to be a gimmick and look how that turned out. So take what I say with a giant grain of salt. I think there’s going to be two things that are going to happen in the future for ops and software development teams as related to DevOps. One is that if you look at DevOps and Agile and objective key results and other things, it’s about taking big problems and breaking them down into smaller more manageable pieces. And then understanding each piece and understanding how that piece glues to the other components in that workflow. I think we’re going to continue to see that happen. I think we’ll break things down more and more until we fit the optimal unit size because the risk that we face, of course, with this is you break it down into too many pieces and then you’ve got a million different pieces and it becomes very complicated. So I think we’ll understand more and more and more how all these different pieces connect together like how does the project management piece connect to the engineering piece and how does that connect to the sales piece, etc.

But also, when we look at those individual components in these methodologies and workflow, we’re often managing those different pieces with lists of stuff. Like you’ve got lists of repositories and lists of issues and lists of pull requests, etc. And I think we’re going to start augmenting these workflows with AI and machine learning and virtual agents that are effectively understanding what our optimal workflow is and being able to serve it. And I think that’s going to be a key piece of how we scale because there is a natural limitation to how quickly and how efficiently humans can operate. But I think when we’re replacing the grunt work with machines and when we’re able to derive insight from machines as well on very human problems, I think we will continue to grow and continue to become more efficient and continue to improve the results that we get. I think that’s what we’re going to see in the next few years.

Is the future bright for DevOps?

Yeah, I think there’s a really bright future for DevOps. It’s been amazing watching this transition in recent years as more and more companies and industries have been learning about DevOps and how to embrace and bring it in and benefit from it. What I’ve loved seeing as well is that there’s a humility to it. I think DevOps is a great way of working for a lot of companies but it’s not necessarily the best way. It’s not like we’ve reached the pinnacle of human collaboration. There’s still lots for us to learn and explore and experiment and try where we can keep evolving and iterating on how we work efficiently together. I think what we have today and the general approaches and methodologies of doing DevOps today are great. But I think there’s still so much more scope for how we can continue improving and helping people to work more efficiently together and build environments that are not just productive but they’re also just really rewarding for people to go to work and to build great products and services and projects.

Originally published at blog.signifai.io on May 4, 2017.