The guide to DevOps: Ops will need more developer skills in a DevOps environment
The Atlassian Summit is behind us but now’s the perfect time to roll out the interviews with Atlassian executives. We talked to Sid Suri, Head of IT Strategy at Atlassian about everything DevOps, including pillars such as monitoring and automation, the importance of Ops and more.
“In a DevOps world, service needs to be there”
JAXenter: Could you tell us more about your job at Atlassian?
Sid Suri: I manage marketing and strategy for Atlassian products for IT and Ops teams, including Jira Service Desk and now Jira Ops. Atlassian has a big presence in the developer market and a growing one in the IT market.
JAXenter: What are the habits of the highest performing IT teams?
Sid Suri: We wrote an article about this a year and a half ago, and my answer since then has not changed much, which is quite interesting. I would say that it is their ability to collaborate with the business. In some ways, that is not very new for IT, but in some ways, it’s still the most important. I once interviewed our CIO and he talked about how the most important thing an IT person can do for their career is to take business classes, not technical classes, and to go to business conferences. For example, if you work for IT in an insurance company, understand what the insurance company does and how it works. That way you will actually be more valuable and effective at your job in IT. It will be more worthwhile to take a business class than another Java class.
Having that deep understanding of the business is important. Fundamentally, what IT is doing is marrying two sides of an equation: technology and the business. If you only understand one side, you will not be successful with the other side.
The most important thing an IT person can do for their career is to take business classes, not technical classes, and to go to business conferences.
IT people need to think like product management does. An internal Atlassian employee told me that a product manager cannot take it for granted that people will use their product. They have to build the best product. It has to be updated frequently and at a reasonable price for someone to use it. If you have a product or a service, if it’s easier for a customer to use something else, they will use it and your product will go to waste. You have to think of it as offering a product to a customer who will only use it if it’s good enough. It’s a shift in focus from providing the infrastructure to providing the product.
JAXenter: We did an interview with some DevOps influencers and they believe that devs run the DevOps world. But what about Ops?
Sid Suri: DevOps is breaking down the traditional structure. Previously Dev and Ops would sit separately and report to different people. The change of DevOps can sometimes be uncomfortable for people. Now some operations people are wondering why things have changed. In some ways, the operations job is more important than ever, but it won’t look like the same job from the past. It’s not going to be as well-defined or have a well-carved out space. It’s going to be a more distributed and embedded role.
I think Ops is changing and there will be some heartache, but I do believe that operations will be more important in the sense that there’s no point to having a service or product without them. If you don’t have sound, strong operational policies, you can’t move fast, you can’t have the team focus on new things. They will always be focused on fixing the old things and the company will fail. I think Ops needs to look at it from that standpoint and not how their job is looking different.
JAXenter: What skills will Ops need in this new environment?
Sid Suri: I think Ops will need more developer skills to some extent. I’m hearing that from a lot of our customers. They are starting to hire more developers than operators since operations is being thought of as more code. Your configurations are code, your release process and everything else is all created. I think they need more development skills, and I don’t think Ops would be opposed to that idea. It’s maybe the next level.
A lot of our customers’ teams makeups have changed. Ops are a little bit of an unequal partner where they don’t have a lot of influence. Rather, they get the release process created for them. But Ops can do that with the right skills. Obviously, collaboration is always going to be a needed skill. It was needed in the past and it will be needed even more in the future. That’s a big reason why we are really getting into the Ops space and the IT space in a much more focused way.
There’s a collaboration on one side of the business and then there’s the collaboration on the other side with the developers. IT is the glue between that whole chain. In some ways, Ops has become the hardest job of all but they have the opportunity to help the company much more than development does.
If you are a developer you have a project, but the IT team is looking across all of the projects across the company. The huge ability for influence cannot be ignored, but there is a strong need for collaboration. At Atlassian, that has been our mission for the last fifteen years. We have been helping developers collaborate with the business and IT, but there’s the same problem from the other side of the coin.
JAXenter: Would you like to talk more about Jira Ops?
Sid Suri: I think Jira Ops is that middle piece between the two big pieces we already have. The first big piece is Jira Software which helps developers become agile and collaborate. Then you have Jira Service Desk on the other side, which is after the product is released you interact with the customers. There’s also QA testing which you can think of as part of the devs. In the cloud, there are big operational pieces. So, by launching Jira Ops, we now have a product that goes all the way on one platform. Even though it’s several products, they all share one Jira backend. They have the same processes, the same data store, and everyone can see what another person is working on.
There’s communications through the ticket system. The agent can then see when things will be fixed and everyone has access to the same information, which is really powerful for a company. It streamlines processes and allows for open collaboration. Information can be shared all the way from Devs, Ops, and even support. So I think from that standpoint, it’s going to be something that customers also pick up on.
It underlines our focus on IT. The product itself is focused on incident management. Not just small incidents, like not being able to log into your email, but big incidents such as Jira is down or something where there’s significant destruction. For those customers what JiraOps tries to do is pull together all the different solutions that customers have to date.
I think Ops need more development skills, and I don’t think they would be opposed to that idea. It’s maybe the next level.
So you will have a support system going through tickets and talking to customers. Jira Software will track the follow-up tasks that happen after the incident. Each of them is very important, but a small piece of the puzzle. JiraOps tries to be a single dashboard. The single view of your entire toolchain can layer workflow, automation, and analytics. If you’re an incident manager, you can look at your incident numbers on a month to month or week to week basis. All of your data will be all in one place.
JAXenter: It sounds like automation is a very important part of all of this. How much automation is too much?
Sid Suri: I think with incidents, there isn’t enough automation. There does need to be a balance, but right now it is way too manual. Even simple things like auto-replying to tickets during a major incident to say we are working on it. It would save a lot of man hours. There’s a lot of low-hanging automation that is not happening today that could help.
How much is too much? We are far from there. You do want a human to be able to intervene and move on to something else, but it brings a little structure and order to the situation.
JAXenter: Are there skills that are more important than others to automate?
Sid Suri: I think what we talked about, the collaboration of the business, and understanding what the customer wants is important. You need to know what the customer wants and needs. I think those skills can be automated. Those are going to be the most valuable skills and will become more valuable in the future. The stuff that is getting automated are things that I don’t think people would want to manually do. The more you can automate that, the better. Does that mean that in an office of a hundred people you will have less IT people? I don’t know. That’s a question for the company to answer in regards to what their needs are.
“DevOps will change service”
JAXenter: Is the service desk becoming disrupted?
Sid Suri: I think it is being disrupted. The service desk has a really important function of bringing structure to what can be a chaotic environment. If you don’t have a service desk, then everyone is coming to an IT person for help. But I think what has happened to that is it has created a bit of an overly formal and distant relationship between IT and the customer. IT doesn’t worry about the customer’s problems. The disruption that is happening is trying to have a more conversational and human approach to service. We want a more open approach.
If I can see what’s on an agent’s backlog, I might not be such a hurry. Or, if I’m using a chat tool, I can speak to the IT person and ask for help and create a ticket. The system will make sure that everything happens on the backend. I think there’s a lot of ways to use a more human, natural interaction patterns for help that I think is missing from a lot of service desks, especially older ones. I certainly think this is a positive path of disruption.
JAXenter: What role does this play in the DevOps context?
Sid Suri: In the DevOps context, the most important thing is having access to information. I’ll give you one example: we are rolling out a lot of changes to Jira. A lot of those changes have to do with the UI and the navigation experience, and the way searches are performed. Those are really fundamental changes for people who have been using a product for ten or fifteen years. Now, let’s say you have a bug to file with the customer.
In some ways, Ops has become the hardest job of all but they have the opportunity to help the company much more than development does.
The way we roll out features in the cloud is we don’t roll it 100% on day one. We roll it out 5% at first and see if it’s okay. Then we roll it out to 15% and see if it’s okay again, and so on and so forth all the way up to 100%. Then we tweak and fix to make sure it performs. By the time it gets to 100%, we are confident in the service. All features are now rolled out in that way. We have gone away from big bang releases and gone to more continuous approaches. This is the DevOps way.
In this model, now if you open a support ticket, as a support agent I need to understand what experience you have with the product. Did you get the new update? Are you using the old system? There might be five different development things if there are five different update schedules, but you as a customer have one single experience and now you are working with a support agent who doesn’t know what version you are using. Do you have the new attachment service or the old one? You can’t help the customer if you don’t have strong information service with the development counterparts.
In a DevOps world, service needs to be there. Unfortunately, DevOpsService is not a very catchy phrase! We don’t use the term DevOps very much in our own marketing or press because it doesn’t include the customer. It stops right after Ops. But now you have to include the customer. That’s the reason you are doing DevOps! The customer has to come back in via the service team or some kind of feedback tool, like customer support.
Getting that chain to work is more valuable than just DevOps. That continuous sharing of information is going to be super valuable in the future. So yes, I think DevOps will change service. It’s just a matter of what model it will embrace. Someone with a lot of leadership, maybe Google, will start a momentum and industry-wide change.
Don’t miss our “Guide to DevOps” interview series with Atlassian executives: