Here’s How DevOps Teams Can Refine SDLC Processes

What makes a good SDLC? To the unaware, there might be too many variables to count. Kelsey Steinbeck, Director Software Engineering, shares her knowledge.

Or listen on

Here’s How DevOps Teams Can Refine SDLC Processes

What makes a good SDLC? To the unaware, there might be too many variables to count. Kelsey Steinbeck, Director Software Engineering, shares her knowledge.

Or listen on

Description

On this episode of The Tech Trek, host Amir Bormand meets with Kelsey Steinbeck, the Director of Software Engineering DevOps at Indigo. Amir and Kelsey delve into the subject of DevOps best practices and break down various ways that teams can stay agile when working on large and small projects.

Show Notes

04:24 – Kelsey shares her strategies for determining when and how she makes adjustments to her team’s processes.
09:07 – What to do when a process doesn’t suit the capabilities of your team?
13:32 – Kelsey breaks down the real impact velocity hits have on SDLC.
19:12 – How can companies account for changes to their processes as they shift through different phases of growth?
21:34 – How can people learn to set healthy boundaries as they move into management roles?

Kelsey Steinbeck

Director Software Engineering @ Indigo

Meet our guest

Kelsey started her career at Liberty Mutual doing DevOps tasks when DevOps wasn't really a thing. Kelsey specifically drove DevOps processes and tooling while trying her hardest to help streamline and enhance legacy engineering practices including helping migrate from on-prem to the cloud.

Episode transcript

Amir Bormand: [00:00:00] On this episode of the podcast I have with me Kelsey Steinbeck. She is the director of Software engineering, DevOps At Indigo. We’re gonna be talking about processes and staying in nimble, staying agile, and we’re gonna be going through some of the areas that You know, Kelsey scene you know, the evaluation areas of opportunity where you should or should not, you know, make those decisions.

It’s more art and science, so I think the more perspectives we get, the better on the topic. Kelsey, thanks for being on the podcast. Thanks for having me. Awesome. Let’s start off at the top and no, two things. One, what, what Indigo does and then what are some of the responsibilities that you have?

Kelsey Steinbeck: So Indigo really is creating software and tools to help farmers sustainably feed the planet. We use technology to drive sustainability and profitability in agriculture, and we are [00:01:00] focused on kind of enhancing some. Soil health and avenues that maybe haven’t been explored as much in the agriculture space.

Amir Bormand: Awesome. And what, what, what are some of the responsibilities you have in your role? 

Kelsey Steinbeck: So DevOps at Indigo really does. Everything but actual application development. So, you know, we think of Indigo as having many little startups within kind of the overall startup. And DevOps is kind of at that central control of, of steering the ship and trying to keep you know, putting it.

Just enough process in place so we don’t have chaos, so we can kind of keep our, keep it managed chaos. So we support all of the application teams and all of kind of these little startup pods and support everybody to kind of, deploy and build and deploy software in, in the best ways that 

Amir Bormand: we.

So a couple interesting things. We [00:02:00] can kind dive in there and talk about the context of, you know, adding processes. Staying nimble is, are not always things that go hand in hand, but, but just for everyone to understand and, and the context. Y you know, you mentioned y you guys, you know, provide just enough process.

What stage of DevOps maturity is the org? I think 

Kelsey Steinbeck: we’re actually in a relatively mature phase for DevOps. When I started, I was the second engineering hire. And then really kind of helped build out our engineering ecosystem. And there were some things that were really, really important to me in that.

And couple of those were automated deployment builds and deployments. You don’t make manual changes into production. Infrastructure is code. And now we’re really kind of on the journey. Allowing developers to be really be self-sufficient. Creating enough documentation and patterns and things for them to unblock themselves while still following some of, you know, DevOps [00:03:00] key key principles.

And you know, I think we’re, obviously we have. Improvements we can make in the deployment times and cycle times and things like that. But for the most part, at least those key practices are in place and we I think of DevOps as just kind of a continuous improvement mechanism. And so, we’re always continuously improving, but you know, those core principles are in place.

Amir Bormand: Absolutely. And you mentioned obviously it goes up, it’s a bigger company. But you mentioned it, it kind of works like a bunch. Smaller startups, maybe if you could just, yeah. Maybe explain what that is. 

Kelsey Steinbeck: Yeah. So we have a, a marketplace that’s kind of a separate product offering. Then let’s just say our sustainability product offering both very separate entities, but both still have corresponding attributes that.

Bring it into one, one kind of holistic platform that Indigo offers, but two, two different product offerings. Okay. 

Amir Bormand: Interesting.[00:04:00] So, you know, you mentioned obviously putting just enough structure in place to, to kind of, you know, have some controlled chaos. I guess when you are looking at the addition of processes and you’re trying to evaluate.

To make adjustments. Are there any things that you, any signs you look for or any things that you’re keeping track of that kind of give you a feeling that it’s, you know, something to take a look at as, as a team or as an individual? 

Kelsey Steinbeck: Yep. I’m gonna separate out two different kinds of process, so I’m, I’m not talking about.

Process within your software development lifecycle that are best practices. So I’m not talking about testing before, before you go to production or you know, making sure you have a code reviewer. Those types of things are just engineering best practices, and we’re not arguing about the value of, of those.

We already understand the velocity cost with having. Some of those pre-deployment checks and you know, there’s a lot of benefit to that that I’m [00:05:00] not gonna go into. I’m really talking about other business process, other business requirements that re, that require potentially a process hit in your S D L C.

So I wanna make sure I separate those two things. I very much view your S D L C as this kind of living. Ecosystem. And I think it’s really our job as engineering leaders to protect that ecosystem and any process, regardless if it’s an engineering best practice or a process that the the business might want to introduce into the S D L C will require a velocity hit.

Outside of engineering best practices, any process that, that someone wants to implement into the SD L c, I’m really process adverse. So I, I kind of start with the mindset of, no, we don’t, IM, we don’t introduce any process and then really dig, dig into one. [00:06:00] What is the requirement of that process and why?

So that’s one big piece of it. A lot of times what you’ll find out, Somebody on the business might, might have a requirement to do something in your S D L C for reasons, but when you really dig into what that requirement is, it might not actually be a requirement or it might be too nebulous or you know, they might wanna save $10,000 for some compli for like an insurance provider for reasons they might get a savings.

That that few thousand dollars of savings is not gonna be savings over time by the time you add up all of the velocity hits that happened within your S D L C. So it’s really understanding the requirement. Will that requirement stand the test of time? Meaning let’s say some VP and some business unit wants to, to introduce some sort of attribute into the sdlc.[00:07:00] 

If that individual leaves, is that requirement still does it stand on? Its two feet still. So then at once you have a really defined requirement, the implementation of that requirement is also really important. And you should always be reviewing like your implementation of that requirement, cuz it’s gonna create some new process in your S D L C, with the customers of your S D L.

And in my mind, the customers of your SD l C are developers. So what are you gonna be asking developers to do? Is there a way that you can abstract that from a developer even knowing it’s a requirement in your SD l c? So those are, those are the two kinds of things I think about when somebody wants to do something in the engineering ecosystem is really understanding the clear require.

And then the implementation because how I would choose to implement a requirement [00:08:00] might be very different from say, somebody in IT who might implement that requirement. And we, you need to review those implementations with your customers. 

Amir Bormand: That’s awesome. I, I think, I think a lot of that is great insight.

And you mentioned something I was gonna go back to business might, and I definitely agree there’s two different types of processes and, and we’re probably, you know, not talking about engineering best practices, not, not the right topic for the podcast, but when we’re looking at the business driven, Potential changes and, and the example we provide, maybe it’s a, it’s a short-term saving.

Somebody sees that, somebody’s like, Hey, this is an opportunity as a business we wanna take advantage of, comes to you, you know, obviously you’re, you’re gonna do your due diligence. You’re, you, you, you mentioned evaluation of that. And when the process doesn’t fit the team, what happens then? Like, obviously you’re going back to the business, but typically what happens when that has to happen for you, when that 

Kelsey Steinbeck: process doesn’t make sense?

Doesn’t make sense. Yeah, and that’s hard cuz [00:09:00] when I started out earlier in my career, I didn’t feel empowered to like really push back on that. So in, so in a lot of cases I just did the thing, like I just kind of took this nebulous requirement even though I didn’t fully understand it, you know, might implement it.

And then even if you get rid of that implementation later, it’s so expensive that tech debt. Because you implemented something that wasn’t necessarily needed is now a huge cost to rip out of that S D L C. So now I really, if I don’t agree with a requirement, I really take it up the chain. You know, luckily I work at Indigo, and Indigo has really great leadership and if.

Somebody’s trying to do something into the S D L C that, that you don’t agree with. I can signal that up and they will ask the questions. We might have to implement it. I’m not saying I get my way all [00:10:00] the time and I’m not always right, and we might have to do something in the S D L C for reasons, but at least it’s escalated up to senior leadership because it’s their job.

They know they’ve been around the block. There’s gonna be a hit to their velocity, and so they’re just as protective as I am. 

Amir Bormand: Absolutely. I, I guess, you know, as you’re, as you’re going through this, I’m sure you know, there’s, there’s plenty of requests that come in, some can be done, some cannot be done. You have a team.

When you, when you are working with the team, maybe somebody on the team gets approached. How do you, how do you collaborate with the team? Obviously, you. You, you’re, you’re the manager, you’re the director, but how’s that relationship work when outside requirements come in? Maybe not through you initially.

How, how has that worked through the process? Is it pretty much the same? 

Kelsey Steinbeck: Yeah, they escalated up to me and we’ve had to get a lot better at that. Really, cuz what that does is [00:11:00] it puts you in really reactive mode all the time. Somebody comes in and needs you to do a thing or needs a thing done you know, we’re really shifting to being proactive and trying to anticipate business needs.

But I have a lot of trust in my developers. I think they’ve got really great instincts, especially in DevOps. They have such a breadth, they know most of the ecosystem so they can understand the implications of said process that’s coming in. Not all development teams have that breadth, but that’s what I think specialty of DevOps and why DevOps is really valuable is that we understand almost the whole S D L C ecosystem.

And so if a developer gets, gets approached by somebody in the business that, Hey, we need to do this thing. They’ll immediately escalate it up. And a lot of times I have the conversations with the DevOps engineers, like, Hey, we’re being asked to do this thing. What do you think about it? [00:12:00] And a lot of times they’ll push back hard, and that’s really a signal to me.

If DevOps engineers are pushing back hard on a thing, it’s my responsibility to push hard upstream. Again, we might not get our way, but they are the subject matter experts. In the S D L C and you have to listen to those signals from them. You can’t just implement a process because somebody says to do so.

It really has to be vetted because any process will add additional velocity cost and your SD L C is is kind of a culture like it’s you operate in it every single day. Developers. Can choose to go work somewhere else because they have better process. So there’s a lot of like nuanced things around your SD L c, and it’s why you need to be really protective of it.

So it’s, it’s our job to listen to those signals. I like [00:13:00] that. 

Amir Bormand: You mentioned velocity hit, I just, I just wanted to Yes. Make sure when you’re, when you’re mentioning velocity, what, what metric are you, are you speaking about? 

Kelsey Steinbeck: It could be any metric. Okay. So, At a, at a previous company for example, we had to submit a ticket to do absolutely everything as an engineer.

I remember adding that up cuz for, for the business, you know, oh, this is only, it’s less than a five minute process. That statement sounds so easy. Yeah. It’s less than five minutes. Like it’s not that big a deal. Like it’s fine. Well take that five minutes times it by 10 times a. By four weeks, a month by 12 months a year times 500 engineers, that’s thousands of hours of engineering time being spent on submitting tickets.

So it’s not just cycle times, it’s not just your cycle [00:14:00] time of deploying to production. It’s your context switching out of, it’s already hard enough to focus as an engineer. You’re having to context switch out of that into something. Contact switching back in, that’s not actually five minutes. That might be a 15 minute contact switch.

So there’s all sorts of metrics. When I talk about velocity hit, it’s not just, you know, measurable cycle times. There’s lots of velocity hits that are really, really hard to measure, but everybody knows they exist. Like, you know, you might get nerd sniped on this process. You don’t, you know, somebody might ask, Hey, why do we even have this process in place?

Then you have to spend 20 minutes to go dig into, I don’t even know why we have this in place. So it’s, there are all sorts of metrics in your S D L C. Some are measurable and some aren’t. And when I talk about process, if you introduce it into your S D L C, it will have a velocity hit somewhere and you need to understand where in your S E L C that will have a velocity hit.

[00:15:00] Hmm. Interest. 

Amir Bormand: Velocity hit. I think you’ve, you know, definitely, you know, you’ve very well articulated kind of the implications to that. And you know, obviously I like the stance of, you know, you mentioned start with a no mindset and then dig in. You know, prove value to the, the business process chain. Talk to the business about it.

In the cases of when you’re looking at that and you’re evaluating, you know what, the velocity hits worth it you’re gonna go ahead and implement something, you know, potentially it’s gonna slow people down. You are looking at that whole org and you’re starting to count those hours. You mentioned, you know, obviously yeah, an engineer can come back.

The culture. When people come back, you know, down the road and they don’t remember why you did this and you have to kind of carry some of that legacy, that cultural knowledge with you, how do you get over that to make sure that you reduce some of that, you know, friction of, well this just doesn’t make sense.

Cuz if everyone’s thinking that and everyone’s explaining it to you higher, that that does take a lot of time and people may not explain it as cleanly as when it was done. People might go, well it’s something we have to [00:16:00] do and it kind of sucks. And all of a sudden that person’s like, yeah, we kind of have to do it and it sucks.

And that kind of ricochets all the way through the. 

Kelsey Steinbeck: And this is something I’m still learning like this, it’s engineering is very much a journey. But one thing I really learned about this is document the reason why and have it visible somewhere. Have be able to show chats, be able to show meaty notes while you had it.

You can point folks to the requirements and then they can kind of review that context. Best case scenario, a developer will come and say, I read that requirement and here’s a much better implementation for this thing. I think in dev, I’m in DevOps. I love automating all of the things. So all of the requirements are processed that we can automate and abstract out the better we might spend more time having to develop.

The automation for that process and make it really lightweight for an engineer to [00:17:00] follow. But in the long run, it’s worth it. So if you do have to implement process, try to find ways to abstract it. You know, I use, I use an example of change management One. Implementation of change management is a cab board, very heavy handed.

Another implementation of change management is, you know, being able to audit your GitHub pull request. Like they’re the same things. You’re, you’re, you’re solving the same requirements. One is heavy handed and not automated. One is mostly automated. So there are ways to, in introduce your process in really thoughtful ways that will not have as big of a velocity hit as something like a cab.

Amir Bormand: Interesting. Very good point. And I think you know, I like how you mentioned, you know, that’s something that, you know, being intentional with these changes, you know, just because somebody’s asking you to do it, you know, being reactionary versus, you know, [00:18:00] planning and having that intent. And, and I like the documentation of the show chats, the meeting notes.

Cuz I think when you, when you mentioned the SD l c as a culture and you know, you can have this culture, people join and, and when you look back years later, And you’re like, well, it’s not quite what I signed. You know, it wasn’t the same job, but when, when I first joined. And you look at all the little changes and it becomes this fragmented process and all of a sudden there’s just, you know, the developer experience goes down a little bit and, and you see people going, well, you know, like you said, it’s the culture that keeps people.

And I think that’s a scary part that I guess these changes don’t account for not just the velocity hit, but the culture actually aspect of it. 

Kelsey Steinbeck: You do have to have process for reasons, and there are business requirements that you’re gonna have to put into your S D L C, but there are also different phases in your journey.

So you know, you ha, you’re a startup and then you transition to 20 engineers versus a hundred engineers versus 200 ENG engineers versus a thousand. [00:19:00] You’re gonna have different process requirements along that journey. But one thing I have noticed is, You know, a lot of business folks, because they’ve worked at many different companies, and companies just do this thing for reasons, they’ll want to introduce this process.

It may just not be the time to introduce that process. So, not that the process is bad, not that I’m saying no to this process, I’m actually just saying no, it’s not the right time for this process. You know, things like CH change, manage. You don’t need as restrictive for the auditability potentially of change management really early on.

You’re just trying to move fast. Change management comes down the cycle, so you don’t need to pre optimize for all of the controls that you know, you typically have in your, that the business requires for reasons. [00:20:00] There is a time and place for those controls. So sometimes it’s not even, I’m saying, no, we’re not gonna do it.

It’s, no, we’re just not there yet. 

Amir Bormand: I like that. That’s actually that’s a great way of looking at it cuz when people do join, I’ve noticed every org, every department that, that previous toolbox they bring with them, it instantly, everyone wants to open it up and go, I want to kind of, what I’m comfortable with and what I’m used to.

And it’s interesting that that happens so often. I, I like different processes, different stages and, and not saying no to something is, is very powerful. I was go, I was gonna ask you a question. That actually I’m gonna start asking more leaders about this cause I’m starting to realize that it’s something that not everyone is born with.

We all kind of learn at different phases. You mentioned something early on about, you know, pushing back escalating, feeling more empowered to say no. The question, I guess, and a little bit aside from the, the, the podcast is at what point did you get comfortable, like that [00:21:00] concept of being empowered to say no?

Like when did that occur in your career? Because I think a lot of people who listen, you know, if they wanna move into management roles, I think that’s a question that pops up a lot. And I think, you know, we don’t talk about it a lot, but I figured I’m gonna get some perspectives of people to see how they started to learn to do that.

Kelsey Steinbeck: That’s a really great question. I’m not saying. I’m saying what you’re ask, I can’t give you what you’re asking for, but here’s how you can solve that thing. Or here’s a different approach. It’s more like, you know, pushing back a little bit on, on the request, but here are other ways that you can solve this same thing.

So it’s not necessarily that I’m saying no, it’s like here’s other ways to solve this problem, but being able. I think this is a little bit of my kind of career maturity journey is that by saying yes all the time, you’re always [00:22:00] reactionary. You can’t get out of that, that space. And like I think DevOps engineers tend to be really empathetic.

And so we want to say yes to everything. We want to solve people’s pain points and. It’s just intuitive that when somebody asks for something, you’re like, yeah, I can help you out with that. Oh yeah, I can help you out with that. But you’re actually doing a disservice to your organization and your team by always saying yes, because you are not building resiliency outside of DevOps or you know, your business process when you’re always saying yes, you’re stopping resiliency from being born.

So you’re actually doing. Your company or your team more of a service by, by having more self-service processes or here’s other ways that you can solve this thing. But always saying yes actually causes a bunch of negative things [00:23:00] downstream in the long term. So it, that took me a long time to learn. I always thought saying yes, you know, resulted in the best outcomes, but that’s not true.

Saying no actually results sometimes in a lot better outcomes, but that, that just takes trial and error to actually figure that out cuz it’s not intuitive. 

Amir Bormand: That’s awesome. I, I, I, I like that. Thank you for sharing. I, I, I ha I haven’t asked this a lot, but I did a recording recently that we kind of covered this and I wrote down a note saying that I’d like to ask a almost every guess about this, cuz I think it’s very interesting.

Everyone has different maturity level process around their career and where they, when they get to this point, and we all do at some point hopefully, and kind of realizing how we’re all different is is pretty cool. Kelsey, thank you for being on. Thank you for sharing. I was gonna ask you If you could ask a future guest to cover a topic or answer any, any question technology related, what, what would you like that to be?

Ooh. It’s 

Kelsey Steinbeck: a, it is a [00:24:00] hard question. I, I’m gonna go with something like I, I feel like I spend a lot of time in, but struggle a bit with myself that I could use some insight into. You know, I’m a, I’m a millennial on the earlier end, and so I’ve kind of seen. Seen the journey of corporate world from, you know, the journey into the cloud and, you know, being on-prem and going to the cloud.

And, you know, years of, of that kind of journey. And what I’m, what I’m struggling with is like a lot of folks, new hires coming in like the Gen Zs, like they operate in a very different way. A lot of times they push back in ways I wish I could have pushed back in. You know, as part of my career a lot of respect to them holding boundaries and, and things that I never felt empowered, you know, till later on in my career.

So I’d love some guidance from someone on, you know, managing, you know, [00:25:00] managing the different generations of software engineers and, You might have to have a different management style for, for, for different generations. That’s been a hard thing for me and I would love some insight into that. 

Amir Bormand: That’s a great one.

I mean, especially you mentioned, you know, You’ve seen the journey, you have some of the legacy, you know, to the cloud. Whereas if you’re, if you’re coming into it and you only know the cloud, you’re gonna have a different perspective trying to solve different problems. So I I, I like that one. I, I’d love to do an episode around that.

What’s a good way of somebody reaching out to you to, to talk about anything you mentioned on the podcast? Sure. 

Kelsey Steinbeck: LinkedIn’s the best way to get in contact with me. Find me on LinkedIn. 

Amir Bormand: Okay. Well, we’ll put down the show notes for you and if anyone does wanna con get in contact, they’ll come your way.

Thanks for being on. I, I love to thank you for sharing. 

Kelsey Steinbeck: Yeah, thanks for having me. 

Amir Bormand: Awesome. That’s it for this episode. We’ll be back again. Different guests, different topic until then. Two things, one. Kelsey’s topic’s. Great. I’d love for somebody to come on and talk about managing different generations and the different styles that it [00:26:00] may require adjustments managers have to make.

That would be a great topic. So if you can talk about it or someone you know reach out, let me know. Secondly, if you like the podcast, share it. That’s how it grows. Throw a review on your favorite podcast listening app. That’s how this thing gets bigger and I appreciate everyone does. That’s it for now.

Thank you. And.

Latest Episodes

Sunil Mallya

VP of Engineering at OncoHealth

Eric Labourdette

Cloud Business Operation Consultant

Lee Eason

Director of Branch Experience at Edward Jones

A community built by you
for you

Subscribe to Elevano Insights

By clicking Sign Up you’re confirming that you agree with our Terms and Conditions.