DevOps for Business Operations | DevOps Connect: DevSecOps 2023

Okay. Hi everyone. Welcome to this session on DevOps for business operations.

I wanna thank you for spending some time with me today. Um, I'm excited to be here because it's a topic I'm very passionate about. Uh, I'm Adrianne Schulman coming at you from my home office in Westchester County, New York.

Uh, if you're joining live, I am here with you today in the chat. Uh, so please take a second and say hello. Um, let everyone else know where you're coming from and, uh, we'll get started.

So, because this is a DevOps event, I'm assuming everybody here is familiar with DevOps. I'm also assuming that when you talk about DevOps or thinking about it from the perspective of software development and engineering, um, but because I'm talking about DevOps for business operations, I wanna define what I mean by business operations, which is a very generic term. Um, so at least for the next 20 minutes as we're together, um, when I say business operations, what I'm referring to are really all of the internal tools and systems that your organization or company is using to run your business.

So whatever it is you're doing, you probably have some sort of customer facing product, probably digital if you're in the DevOps world. Um, this is like everything else. So think about like your marketing and sales teams, um, customer support, customer success, all of your back office finance functions, legal, all of these folks are there and they're helping run your business.

Um, and they're largely living in the world of low-code SAS systems, but they're still needing this technology to get their job done. So think about like C R M or E R E R P applications, your H R M systems, if you're familiar with Salesforce, NetSuite, HubSpot, Zendesk, Workday, um, any of these kind of low-code SaaS applications that your, um, your colleagues are using to kind of run the business. Um, that is the world of business operations and business applications that I wanna talk about and how, um, DevOps can be used in, in, uh, in business operations to get the same benefits that we've seen DevOps do for the, uh, customer facing product development world.

So I do have a question for you that I want you to answer in the chat for me, which is, do you have this function in your company? And if so, what is it called? And who does it report to?

Um, if you're a smaller company or startup, you may not have this centralized. A lot of these applications start by folks within a different silo or department just bringing these applications in. But as companies grow, I've been seeing a lot of them get centralized under, um, a centralized function.

Um, so I've seen it called business applications or business systems, enterprise platforms. Um, so I'm just curious if you have this in your organization and what it's called. So if you can answer that for me in the chat, I'd appreciate it.

Um, and I think I should tell you also my background, by the way, is an enterprise SaaS as a developer engineer, engineering leader. Um, but a few years ago I pivoted into this world of business operations for today. That's kind of what this focus is, is that world of business applications.

Um, so I told you I've, I've, for the last few years, I've, I've worked as both an operator and a consultant, and I've worked with lots of different organizations looking at their internal technology or what I call kind of that tech stack that runs the business. And everybody I've talked to and all these organizations really understand you need good technology to run your business. Um, and if you don't have good tech, your business suffers.

And all of these departments that I talked about, they're suffering as well. Um, so for the different organizations that I've been working with over the last few years, everybody has their own type of dysfunction. Everyone's got their own, um, challenges, let's say that they're working with, but there's certain similarities I've been seeing and certain common complaints across all these organizations about their internal systems.

And what's kind of sad, at least to me, is we are living in the golden age of technology and no one's happy with their internal systems. Like no one seems to say to me, I love my internal systems. And by the way, and I don't know if you feel differently, so I'd love also pop in the chat how you feel about the internal systems at your company.

What do people say about them? Are they happy? I'd love to hear, um, how you're doing.

But the, the, uh, the complaints I'm hearing when I speak to what I'll call kind of the business side, so these are the people using the tools, is that these, this applications team, or it is too slow. Projects take too long to finish. Um, this is like evergreen, right?

It is too slow for the business. Um, but one example as a company I was working with has Salesforce as their C R m, but they wanted to add a new module and they had a six month estimate for launching this module. Um, and then I was talking to the C F O who was overseeing it, and she said to me, they had been going like a year, a year and a half, and still hadn't gone live.

And not only that, it just, they just kept delaying and delaying the GoLive date and they were not so happy with it. The next complaint is around quality. So once changes to these platforms or projects, these for business applications go live, there's just lots of complaints that they're either buggy or there's issues, um, work that does get delivered.

Sometimes it's just flat out wrong. I spoke to a VP of customer support at another SaaS company recently, and he was telling me about a new support portal that they were rolling out. So he had been working with the applications team or IT team to roll it out.

They were all set for release, they launched on a weekend. He and his team goes in to check it out. And he just told me it was just wrong.

Like, the screens were wrong, user experience was wrong, it's not what he expected, and they ended up having to roll it back completely. So these are common complaints from the business side about the IT teams running these applications. But if you talk to the teams running it, they have their own complaints.

Um, a lot of them just feel too busy. So they're like just inundated with so much operational work, tactical work, day-to-day stuff, running these platforms that they don't feel like they can work on strategic initiatives that leads to a feeling of burnout. So over time when all you're doing is working on kind of the tactical stuff, you can't do anything.

They, they describe a sense of like running on a treadmill but not going anywhere. There's lots of complexity in these orgs. So you have this centralized application team, but your stakeholders are across your different silos in your org.

So your marketing and your support, legal and finance. So the teams that I talk to report, Hey, we're spending more time talking about work, talking about what to do and how to do it than actually doing any work. And that's a lot of fr causes a lot of frustration for everybody involved.

And all of these lead to just this general mistrust and a lot of finger pointing and blaming. It's kind of that traditional IT versus the business dysfunction. Um, I actually took a job a few years ago overseeing some business applications and in my first 30 days I do my kind of listening tour to, uh, to learn what I needed to learn.

So I went and talked to the different department heads, um, internally of who were using the applications that my team was supporting. And they all told me the same thing, which was like, Hey Adrian, it doesn't understand the business. They don't understand the customers.

They're not asking the right questions. You guys are clueless. And then when I spoke to my team, they were all kind of saying similar things, but it was, Hey, the business doesn't understand how hard our job is, how technical we need to be, how complex these systems are.

So it was just like a lot of finger pointing and blame game. So in the world of business applications, what makes this a little bit more complex is you're fighting this perception that it's supposed to be just work and be easy. Um, everybody has our cell phones and access to applications that work when we want it.

And that's the expectation for these systems. Um, there's very little appreciation for how complex it is to maintain these environments. Um, if you remember Clouds promise, when SaaS applications first came out, it was like, you don't need it anymore.

And the truth is, is you didn't. Cuz a lot of these organizations, it's not it bringing them in, but the different departments. So if marketing needs a new marketing tech, they bring it in, sales needs a new C R m, they're bringing it in and they didn't need it.

But the trick was as these systems grow and they're not static, they're dynamic, they're changing, you need to customize them for your organization's specific needs. So the truth is they really do mirror software systems even though they're considered these like low-code SaaS platforms, but you're fighting this perception and because they were kind of considered these business low-code applications, a lot of times they get consolidated and they report up to someone who is not technical. Um, I've seen this report to A C F O commonly a Chief operating officer, chief admin officer.

I have seen this function report to A C T O, but more times than not, I noticed the C T O tends to not care as much about these applications because they're focused on the r and D side. So my question to you, and again, answer in the chat, um, does this sound familiar? Do these common dysfunctions in the world of IT and low-code systems, does it sound familiar to you?

And I'll answer because it sounded very familiar to me. Cuz remember, I pivoted from the engineering world into the business operations world and all of these complaints were the same complaints that I had seen in software development. And not only that, these were the complaints that I had seen in software development.

As companies grow and get larger and where I've seen DevOps being able to address all of these, I'm on a mission and it's kind of become my personal mission over the last few years to take these practices from software development, our DevOps practices, start introducing them into the world of business operations to solve these problems. So what I wanna share with you today is just what that looks like. Um, I wanna remind you the, the DevOps for business operations.

It's an emerging field. It's a super fun place to be. Um, so everything I share with you today is just my own personal experience, both as an operator and consultant talking to lots of companies.

Um, I'm not coming from the ivory tower with all of the answers, but I'll just share from my experience some things that I find really interesting about ways to address those common dysfunctions and start to create higher performing better business applications and business operations functions. So when I've worked with teams, uh, the first thing I do is I look at how they're managing their work. And very often the business applications teams are do not have any sort of one system of, of work to manage everything they're coming in.

They may have a Jira type system for managing like the large strategic projects. Hey, we're implementing a brand new SaaS system or a brand new module on our C R m, um, but they may be also getting Zendesk tickets or other tickets for kind of some of the operational work. They tend to also be getting a ton of shoulder taps and emails asking for support, one-off requests questions about how something's gonna work.

So these teams do feel at, uh, almost like just inundated with the requests from all over, over. Um, and of course you can't manage what you can't see. Um, so the first thing to do is really just creating a r a a system where you can actually visualize all your work because once you can visualize and categorize, you can start to make, uh, decisions about what to work on because most likely you're working on things that are actually not the biggest priority and that don't need to get done.

If you're familiar with, um, there's a book by Dominica DeGrandis called Making Work Visible, um, which I used in my engineering days, but I pull a lot of that, a lot of themes from that book into, uh, into the business applications world. The next thing I do is look at environment strategies. And this is really all about creating that pipeline for deploying changes into the SaaS and low-code systems.

So for the most part, when you get a new SaaS environment, you're starting just with a production environment. Um, and that's typically all you need in the beginning. Of course, over time as things get more complex and you're growing and you're working at a bigger company, maybe you introduce a test environment or a staging environment.

Um, but even that, everything is still all manually. You're still manually putting changes in staging. People are manually testing, you're manually moving changes, or you're not even really moving changes so much as just doing whatever you did in staging and repeating it in production.

Um, so I work with teams just to introduce the concept of this is a digital product and creating that pipeline for how you can safely deploy changes into the platform. Um, so that's all around environments. There actually are plenty of tooling that's, uh, coming out for these systems to do automated tests and deployments.

Um, but the hard part here is really just around kind of just, just even introducing the concept of, of the pipeline. Um, and then the third thing I focus on is to help these teams recognize that they're running a product. Um, they're not in the IT service business.

They're not order takers. This is a complex product that is strategic to their organization and that if they can run it like a product, their organization will do better. So it's really around kind of creating that, uh, run, running these systems like a product.

Um, as an example of of of what this might look like. I worked at a company that had a C R M and we had 10 different industry fields for our customers. How do you get that way?

It's when you're starting, you have your team supporting these business applications and your head of sales and Europe says, Hey, I need an industry field to track my customers. And the person who knows the system goes ahead and adds that field. Then someone in marketing needs industry, they ask someone else on the team, they go ahead and do that, right?

So you're kind of whatever anyone wants, you say yes, you add it. Um, and you can end up with these 10 industry fields, unlike if you're running it truly like a product, which means yes, you've got multiple stakeholders across your organization, people ask for things. You don't just become an order taker, you don't just say, sure, you bring it into your backlog, you're analyzing it, you're using empathy.

You're asking questions not just about what they want, but why do they want it. And you're bringing also these siloed departments together so that they can talk about the platform. So now when someone asks for an industry, I can say, well, let me look and see, do we have other industry fields?

How is your industry different than what finance asked for? And you're really able to create, um, the platforms that are much simpler, um, and, and better able to scale with the company as you grow. Um, and then being able to do this as the technical person, you're also thinking all about the architecture, scalability, and UX concerns.

So that is the kind of overview for what DevOps might look like in the business applications world. As you can see, business applications, they aren't, it's not software. And so it's not the same as software development.

You're not writing code. Um, but there's so many similarities in you are doing something to a digital system. It's a dynamic system.

It's constantly changing. You have to customize it to your unique needs, to your various stakeholders, different customers, and you need to be deploying changes safely. Um, and you wanna be able to work as quickly as your business demands.

So these are just kind of just three examples of what DevOps looks like in this world of, of business operations. So now let's say you agree that DevOps is a good way to address some dysfunctions in the business applications world and you wanna get started with it. So what do you do?

So let's roleplay a scenario. Let's pretend I am head of the business applications team. I work in it, I report to A C F O, I come into my new role and I, and I see all those dysfunctions projects are taking too long, lots of defects.

We push changes to production only to get them rolled back often because we're told we do the wrong thing. I talk to my team and they're telling me how burnt out they are and they're too busy to do anything important. So what do I do?

It's clear to me. I know we need DevOps. So I'm gonna ask my C F o, uh, for some budget to do a DevOps transformation.

So we're gonna role play this. I want you to pretend you're my boss, you're gonna be the C F O, I'm gonna tell you what I'm gonna do and I want you to react to it in the chat. Hey boss.

So I've been in my new job for a few weeks. I see what's wrong. I know exactly how to fix all of these problems with our tech systems.

DevOps is the answer. We're gonna do a DevOps transformation. It will fix all of the problems.

All I need is some headcount. So I'm gonna hire a product owner. I need to hire two DevOps engineers to automate the pipeline and do automated code deployments and automated testing.

Um, I need to reorg the team a little bit and I need budget to buy some DevOps software to automate, um, automate my deployments. What do you say? So yes or no, what's your reaction as the cfo F O?

So, so I know if that's me and I'm the C F O in this scenario, I am saying heck no. And I laugh myself out of the room or whoever's asking, so here's what you can do instead. And again, and this is from my experience, having worked with multiple organizations who are trying to improve their business applications, um, teams.

The first is again, and this is, um, you as the kind of leader of the business applications team. The first is really to understand the mindset of your executive C-suite leaders, technical or not tend to want certainty. So, hey, you wanna do a DevOps transformation?

Great, tell me exactly how much it's gonna cost. Tell me when it will be done and tell me exactly what my benefit is and I'll do an R O I calculation. And if I, and if you convince me, then I'll give you budget.

But we know in the digital world, there's no such thing as certainty. Um, so I know that I can't answer this question. Um, and we don't really want to anyway, so what do you do?

So these CFOs, the coo, the chief admin officer, whoever it is who's overseeing this, it, first of all, they're very busy and it is not their only responsibility. Um, they don't like drama, they're hearing complaints about it. Hey, how come our systems don't work?

It sucks. Our systems suck. So they hear complaints and they just want it to work.

And this goes back again to that kind of perception that it is supposed to work cuz it's everything else in my, you know, my day-to-day life works. So that's their mindset. They're not bad people, that's just where they're coming from.

So what you wanna do is just plant the seed, paint the picture for a future vision of it can be better. So as a leader, take accountability. Say yes, things aren't great now, but don't make excuses.

Don't blame the business. Get away from that blame game. Um, and share if you're a DevOps evangelist, if you've done DevOps, just start talking about DevOps.

Not as a way of saying we're gonna force and do it, but just talk about the benefits and how you might have seen DevOps improve other, um, organizations you've worked with or other software development teams. If you're at an organization that's doing DevOps and your customer facing work and you've had success with it, that's a great place to start. Um, and to start telling your C F O, Hey, look, yeah, these are IT systems.

Sure they're low code, but they're very similar to some of these custom engineering work that we've done at our organization and then get to work. Um, so I say talk is cheap. What I have found is show the benefit of what a DevOps practice can do.

And you can do this, and I've done this, uh, multiple times and you can do this without spending $1. So you sit down with your teams, you look at their roadmap and say, what are you trying to do? Pick one of their projects, they're gonna have a project on their that they're trying to get done.

Look at it and help them introduce the concept of an M V mvp. What I have found is most of these organizations, even if they are doing Agile or or are saying they wanna be agile, they still are thinking in projects and big bang. So like if I'm doing a, uh, introducing a new module or feature from a SaaS product, it's, I need that all done.

Um, so really sit with them to introduce the concept of N M V P and help them separate the ones from the needs. Now they'll sit down and they'll say, Hey, uh, marketing told me these are all requirements. They need them all.

It's your job to sit down and really go through to say, okay, but what is minimum? Do you really need that to kind of push something to production? And what I've done is I sit down and I talk to the leaders throughout the different business operations or dif business departments that use our systems.

And I say to them, I know you want X, Y, and Z and we told you it's gonna happen in six months, but instead I'm gonna give you a little bit less than that, but you're gonna get it in three months. And then we're gonna do these fast follows and rapid enhancements and you're still gonna get it all in six months. But what it does is allows you to start working small.

And as soon as you start working small shipping, small things, being more collaborative with people who are expecting the work, it's kind of like the proof is in the pudding. They get really happy. And now you're not talking about what needs to get done or when things are gonna get done.

You're just work. You introduced flow into the system. And as soon as you introduce flow, everything changes.

People start to trust you more and they're more willing to give you a little more rope so that you can kind of continue down the DevOps transformation. So in my experience, depending on how large your organization is, how many applications you're running, how complex it is, any sort of like, you know, the, the DevOps work you're gonna do to introduce, it's going to take years. Many, many, many years.

You're probably like any transformation you're never done. Um, but the beauty of this approach, which is just starting small by shipping small and talking to people about the value of DevOps by sharing other stories, um, from, you know, other examples of how it's worked in other places, um, you're able to make a lot of progress and just get started. So this can be done in three months, six months, you just get started.

And, and that's what I recommend. So to do a quick recap of what we talked about and I'll give you some next steps, um, for us, uh, we talked about how business operations today it's run on low-code and SaaS systems, but has the same challenges as all these customer facing product developments because they are dynamic systems that are constantly changing and need to be customized for multiple different customers and stakeholders. And while we've introduced DevSecOps in a lot of our external custom software development pipelines, what I've seen is many of our internal technology is lagging and it hasn't been introduced there yet.

So I just gave you a few ideas for how you might start incorporating DevOps into your business applications environment, um, and how to get started. Not by asking for budget and saying you're gonna be doing a big transformation, but just talking about the benefits and starting small. Um, before we go, I'll remind you, emerging field.

Um, I told you I pivoted here in the last few years. I'm having a blast doing this work. My passion, I've become very passionate about DevOps because it's a way to bring joy back into work.

So if you go back to those like five common dysfunctions of people are stressed out and they're blaming each other, DevOps is the best way to break that deadlock, get people, get value flywheel spinning, get people shipping and people are happy and less stressed. Um, so that's kind of my personal passion. If you are interested in this area, if you're working in this area, um, if you wanna talk further, I'd really love to connect.

Uh, so I have my contact info here, um, email, Twitter, LinkedIn. Please reach out. I'd really like to further the conversation and see, uh, how this field progresses in the future as well.

So thanks for spending the time and enjoy the rest of DevOps connect.