Creating the Best Environment for DevOps Transformation in the Enterprise with DevOps Expert Adarsh Shah
Adarsh Shah recently joined Contino as a Principal Consultant. He has extensive experience in analysis, design, development and implementation of enterprise software applications using agile and lean techniques. He has keen interest in building systems that add business value and is passionate about helping clients achieve continuous delivery by improving their DevOps practices. Contino President Jason McDonald sat down to talk to him!
Why don’t you tell us a bit about your background?
I’ve been working in the tech industry for last 13 years. I started as a developer working with web technologies and some web designing (which I’m not so great at, haha!) and have worked with various languages & technologies over the years. I have a keen interest in building systems that add business value, and am passionate about helping clients achieve continuous delivery by improving all 3 aspects of DevOps (people, process & technology). I do this chiefly by working with client teams in a co-sourced manner, making sure that their DevOps transformation journey is as smooth as possible. I’m excited about working with distributed systems architecture and cloud technologies these days.
Why did you make the move from engineering to consulting?
I had previously been working as an engineer in the financial sector – for a bank as well as a financial product company – which was challenging and fun but quite repetitive. I missed working in different domains and across varied technologies. I had enjoyed consulting internally: rolling things out, talking to different teams within the company, coming up with best practices, running internal conferences to get people communicating and so on. I was always interested in helping internally, so why not go to different clients in different domains using different technologies, rather than focusing on just one? Consulting also gives you exposure to a lot of different companies and their unique challenges, which helps you grow as an individual.
You mentioned DevOps transformations...what does a smooth (or not smooth!) DevOps journey look like?
Clients often struggle when they overlook the importance of combining all three pillars of DevOps: people, process and technology. They concentrate on one (almost always technology) and forget the others and then fail. And that’s when they call us most of the time: when they have tried reading books and articles and realize that what they actually need is a hand from someone who has done this before.
Our experience doing DevOps transformation work at many different enterprises means that we can see the various gaps, identify any functional silos within the organization and decide how best to move towards product-focused and cross-functional teams. The technology part comes with locating the gaps in automation, i.e. identifying what’s still being done manually and eliminating those in so far as is feasible.
Another behaviour that I commonly observe is people tending to try one thing over here...and then another over there...and then another somewhere else, rather than looking at the overall picture and fixing the gaps they see. Carrying out an exercise like value stream mapping is incredibly helpful here. This involves tracing a product from start to finish and determining where there are bottlenecks, what is causing them and how to remove them.
What are the key things to remember when value stream mapping?
In many places the main challenge is gaining people’s trust so that you can even start mentioning some of the gaps that you find during value stream mapping, because at a lot of places they simply aren’t recognized!
Another important aspect to remember is having empathy for the teams. Understand that they are in a complex environment and are dealing with complex problems...and they still need to keep the lights on! Build that empathy and trust and then talk to them about introducing some (slow!) changes. Drastic changes should be avoided; DevOps transformation is a long journey where things need to change slowly, being validated along the way. There is no one-size-fits-all solution, in some cases you will want to go a different route due to different challenges or different regulations in certain industries (e.g. in financial services as compared to healthcare).
Lastly, working with the teams closely and including them as much as possible in the journey is critical.
How do you go about including client teams in the journey?
If you do an initial assessment or lighthouse project make sure that you get their input, understand what their pain is and then work with them to create something small. Then have them be part of decision-making and presenting the results to upper management so that they are part of that initial project. It’s key that we go on this journey with them.
Lastly, crucial for all of the above is finding the right people that have the right mindset, skillset and the willingness to change and working with them closely.
What would be your message to C-levels who are looking to transform?
Other than looking at the importance of combining all three pillars of DevOps that I mentioned above, one of the most basic problems that I’ve seen in too many organizations is misaligned incentives. Individuals and teams alike are simply not incentivized to do the right thing. If the incentive for a cloud engineering team, say, is just to check a box and say “we’re in the cloud” then that promotes bad behaviour. The teams will not be addressing an actual business KPI but just checking that box!
Setting incentives that are more business-driven is critical because it helps teams to think in the right way. For example, imagine that there are a number of siloed teams: the database team, cloud engineering, release management, etc. All these teams should be incentivized towards a common business goal, rather than only thinking about their own silo. This also gets teams talking to each other, as reaching that common business goal involves different teams.
How can we think about incentives in a more in-depth, business-oriented fashion?
Fundamentally, this revolves around thinking in terms of product versus projects. Instead of incentivizing teams on part of a particular project, make sure they are incentivized to make a particular product better. A more product-focused approach means they have to think more about the overall picture from start to finish, rather than just a slice of a project.
Let’s say you are part of cloud engineering team and taking the same example mentioned earlier of moving an application to cloud. The incentive for the team should be to move application to cloud but taking advantages of cloud native features. Looking at existing business problems like scalability during peak season or low customer conversion rate due to lack of site reliability and making sure that they work towards resolving those problems while doing the migration.
Setting the right business incentives or KPIs for the team will lead to better developments practices, for example, cloud engineering teams that work closely with the delivery team to refactor applications to take advantage of cloud native features, or delivery teams adding automated tests to improve the quality and reliability of the software.
How can enterprises deal more effectively and efficiently with security and compliance?
When it comes to security and compliance if you look at a typical enterprise you have separate teams that are driving each of these concerns. This creates a problem similar to the siloed teams we discussed a minute ago, namely, if the security and compliance teams are siloed and not talking to the delivery teams then collaboration goes out the window. It’s incredibly common that these concerns are raised when the deliverables are nearly out the door, when it’s too late to actually make the necessary changes. Then everything is delayed!
Instead, collaboration and communication need to be promoted so that delivery teams start thinking about security and compliance early on. The reg and sec teams, instead of dictating rules, become evangelists that enable other teams to understand those aspects of the work and look at automation to help embed these early on in the software delivery pipeline.
What do the next five years hold for enterprise DevOps?
As enterprises increasingly grasp the importance of DevOps and cloud, the challenges around security and compliance will keep growing. Once you think about going to cloud you have new challenges around data security, personally identifiable information (PII), app security, as well as getting your head around all the tools like HashiCorp Sentinel (for policy-as-code) that help with these things.
And whilst security is important now, it will only become more so, especially as data and applications in cloud proliferate.
And do senior management get the message you’re trying to convey?
I’ve seen a mix. There are plenty of C-levels who ‘get it’, but they might not have been through the journey themselves. Others have some theoretical knowledge based on something that they have read, still others are struggling to understand the ‘new way’. And that’s why there are different challenges in different enterprises and at different levels.
Sometimes it’s the C-level that understands that change is needed, but middle management is struggling to grasp that, or simply busy dealing with challenges on the ground. I’ve seen new CXOs come in and understand that the company needs to change, but they have difficulty spreading that message successfully within the company.
This is where previous experience comes in as a critical differentiator, especially when transforming across people, process and technology.
What do you find most rewarding about DevOps transformation? What keeps you coming back?
I like addressing the people and processes aspects of transformation that are so often overlooked along with technology. You can use the latest and greatest technology but if you don’t have the complementary structure figured out it doesn’t help you!
Another aspect that keeps me coming back is helping those people in the enterprise who are really open to change along their transformation journey. Identifying them and seeing the transformation unfold in front of our eyes is really rewarding.
What do you see that frustrate you in your enterprise projects?
The most frustrating part relates back to people and process part and setting the right incentives...when an organization wants to change but it’s done in a tick-box fashion so that you don’t gain business value from the change! And changing those incentives itself from the top down is a massive challenge in and of itself…
Are the consequences of this tick-box approach bad enough to nullify a transformation effort?
Absolutely. Nullify, decelerate, impair...all of these things. Once you start looking at a solution just to satisfy some non-business matrix you start making poor transformation decisions.
Any other frustrations?
Our mantra is not just getting things done, but enabling client teams so that they can take things forward themselves. A central challenge is trying to convince those people who don’t want to be enabled! This is a standard part of consulting and something that I’ve been doing for a long time. It’s particularly prevalent when the drive for transformation comes from someone higher up the food chain who wants to just get things done, rather than focusing on that enablement. I work with a variety of techniques to convince the more reluctant to change, but this is also frustrating because it takes away a lot of time when you don’t have buy-in for things like that.
What kinds of techniques?
Gaining trust, including them as much as possible in the work, and, critically, showing them some small, quick wins (e.g. an assessment or a lighthouse project to prove the concept). Once you’ve done that, proved yourself and gained trust then it’s time to talk about the other critical changes that need to be made.
Following on from that, if an enterprise has lot of different things to change then prioritizing them correctly is critical. Start with something small that can be used to gain trust & show value.
Lastly, what do you do in your free time? :)
Three things mainly…
Firstly, I love cricket! I love playing in the summer, going on tours with my cricket club. Last year I went to Spain, not the first place you think of when you think of cricket but it was a blast. Secondly, travel. Going to different places and getting a local experience is what I enjoy. Thirdly, whiskey! I love trying new whiskies, particularly Japanese and Taiwanese ones lately.
Thanks, Adarsh!
Thanks :)
