Working in DevOps

Cyber Work listeners, I have important news before we dive into today’s episode. I want to make sure you all know that we have a lot more than weekly interviews about cybersecurity careers to offer you. You can actually learn cybersecurity for free on our InfoSec Skills platform. If you go to infosecinstitute.com/free and create an account, you can start learning right now. We have 10 free cybersecurity foundation courses from podcast guest, Keatron Evans. Six cybersecurity leadership courses from also podcast guest, Cicero Chimbanda. Eleven courses on digital forensics, 11 courses on incident response, seven courses on security architecture, plus courses on DevSecOps, Python for cybersecurity, JavaScript security, ICS and SCADA Security Fundamentals and more. Just go to infosecinstitute.com/free and start learning today. Got it? Then let’s begin today’s episode.

Today on Cyber Work, Steve Pereira of Visible Value Stream Consulting joins me to discuss DevOps, SecOps, DevSecOps and his own lifelong love of streamlining projects. You’ll hear how his dad’s job with Bell Telephone facilitated his early explorations, intersection of DevOps and Agile, the ever important security component of it all, and why follow your instincts and not the big money payouts might not work in the short run, but ultimately, it will get you where you want to go in the end. That’s all today on Cyber Work.

Welcome to this week’s episode of the Cyber Work with InfoSec Podcast. Each week, we talk with a different industry thought leader about cybersecurity trends, the way those trends affect the work of InfoSec professionals and offer tips for breaking in or moving up the ladder in the cybersecurity industry. Steve Pereira is obsessed with making tech human and leveraging it to deliver continuous value. He shows teams how to use simple tools and techniques to make big changes. For the past 20 years, his focus has been on sharing mapping techniques to guide ambitious and struggling teams towards their true north. He is a former startup CTO, agency consultant, systems and release engineer, finance IT manager, tech support phone jockey and pizza maker, my favorite. Always focused on the flow of value all the time.

Today, we’re going to be learning everything we can about DevOps, SecOps, DevSecOps and careers in this field for cybersecurity aspirants. Steve, thanks for joining me today. Welcome to Cyber Work.

[00:02:32] Steve Pereira: Thanks for having me. It’s great to be here. I really appreciate the time.

[00:02:35] Chris Sienko: My pleasure. We always like to get started by getting your sort of personal history in the tech sector. Where did you first get interested in computers and tech, and when especially did you get excited about the concept of like flow and delivery as a calling? What drew you to all this?

[00:02:50] SP: Yeah. That’s a great question, it really brings me back. I grew up in a household where we always had either older broken equipment lying around, because my dad worked for Bell as a technician. He would bring back things that like sitting around the office and taking up space. We’d sort of get first dibs before it hit a dumpster. A lot of stuff was like, either not working at all, or there was just no instruction manual or came in pieces. I just had this great environment to kind of tinker, and play with things and try and figure out what is this for, what can I do with it. This seems to have the same jack that I’ve seen on this other thing. A lot of just freeform problem solving with a sense of play.

[00:03:47] CS: Yeah, low stakes too, because you’re not like breaking something that you need to use later.

[00:03:52] SP: Yeah, exactly. It was a very safe to fail environment. I had a lot of appreciation for the hardware itself. I was allowed to kind of tinker with things, and I was probably, out of my siblings, the most enthusiastic about playing with that sort of like a band and material. I gained a lot of familiarity with random bits of technology, but then eventually computers. Luckily, working for Bell, we had access to the internet really early. But we also had a second telephone line so I could dial into BBSs when I was really young. Just a lot of exposure and such a huge advantage that I don’t think I’ve really leveraged particularly well. I’ve certainly enjoyed myself, but in terms of all the things that I could have been early at on, and seem coming, I have always struggled with the right thing at the right time. I’m not necessarily a product person or a trends person. I’ve seen –

[00:05:10] CS: Can you speak more about that?

[00:05:11] SP: Yeah. I mean, just things like – things like infrastructure, automation, or desktop automation. These things that I knew were really important and valuable. I was always in a situation where it’s like, “Yeah, great. But like, I care about this, nobody else cares about this.” Bridging the gap, I think, there’s a brilliance to understanding the right thing at the right time for the right customer fit. I’ve never been that person. I’ve always been like, “I think this thing’s cool and I’m going to do this, right.” I’ve never really paid attention to whether it was like marketable or something that that could be really big.

[00:06:02] CS: Can you sort of give me an example of like, I was busy with this. But meanwhile, on the other side of town, this thing that was going to get huge was happening. Can you think of any sort of like parallel timeline?

[00:06:18] SP: I mean, my entire career has been that. I would say that, when I first got involved in build and release engineering, or just generally, assembling software and shipping it out the door, I was very early, like burning CDs and putting them in. Not as early as some, but like burning CDs, putting them in a printed binder, putting them in an envelope and shipping it, like literally shipping it. I think a more enterprising mindset would be like, well, everyone’s going to have to do this, so I should just start a company automating this thing and celebrate a ton of money. Meanwhile I was like, this is this is fun. I like automating things and this makes my job easier. So that’s great, gives me more time to do something else. I think that there’s a lot of things along the way that I’ve learned and been very comfortable at the edge, but I’ve just seen these things come and go. Like I’ve been doing something and then puppet pops up and gets millions of dollars in funding.

[00:07:24] CS: Yeah. You’ve seen your ideas come roaring up behind you and sort of pace you in the sort of race of stock car arrays of life or whatever.

[00:07:33] SP: Exactly. I’m sure that’s not uncommon in the tech space, right?

[00:07:37] CS: Yeah, sure.

[00:07:37] SP: There are lots of folks who see things coming way before they hit the market.

[00:07:42] CS: Well, then there’s also the opposite of people who say, like, “Oh! If I can only get this thing off the ground, I can tell this is going to make a mint,” but they don’t actually have the know how to do it. They just sort of are telling people at Thanksgiving all the time, like, “Oh! If I can just get this one thing off the ground, then easy street and it’s over for you losers or whatever. That’s interesting. Yeah. I think about that all the time too. I feel like whenever you tell a family member, you’re working on this thing? The first thought is always, “Oh! You should try and make money off of that.” You’re like, “No, I just like doing it. I’m just going to do it.” It’s definitely two different mindsets. I’ve talked to both on the show and I like them equally.

[00:08:22] SP: Yeah. I would say that it’s something that is pretty rare in tech, but is growing, is this understanding of customers and understanding of value, and demand, and what people really want versus what we like to play with and what we think is valuable. The exercise of just putting your mindset in someone else’s shoes, and position and environment is so valuable and so rare. That’s the sort of thing where I’ve been focused on this flow, and delivery and automation for my own purposes for a very long time. Just recently, the past five years, shifted that into – this is something everybody needs. I keep hearing people struggle with it. It’s just the only way to really reach the level of scale, and performance, and consistency, predictability that we need now that all this complexity is just constantly rising and nothing is getting easier necessarily.

[00:09:26] CS: This ultimately sounds like in this particular case, you did hit the right thing at the right time, though. This thing that you’ve been interested in for a very long time, the complexity of the process, and the market has finally caught up were these ideas that you’d been sort of work shopping for decades maybe at this point are necessary to everyone else now. It’s just a matter of getting the message out. Is that accurate?

[00:09:52] SP: I think that’s where a lot of the industry is right now. The tech industry is now seeing that there really is no gap between tech and business. There is no silo in an organization that actually improves performance. We’re starting to look across the entire organization. We’re starting to look at all the things that are involved in getting value to customers, and having really few avenues to make sense of that right now. There’s a clear gap in like how do I understand that? How do I visualize it? How do I understand where to focus and what’s really going to make a difference. All of these things are really mixed in with business schools, and customers, and unique capabilities and things that are been commoditized and you shouldn’t be outsourcing. It’s this network of so many different factors that are interdependent. We’ve got lots to learn about systems thinking and applying it to business and then applying it to work and collaboration. That’s really exciting to me right now.

[00:11:19] CS: Okay. My next question was about your – you’ve sort of answered this partially, but you’ve gotten very interested over the last however many years in the DevOps and build and release game for a long time. But can you talk about some of the projects or tasks that you did? You mentioned burning CDs, and sending them and things like that. What are some other things that you took on early that really got you excited about sort of going down this path?

[00:11:47] SP: Yeah. It’s been a pretty similar pattern over the course of my career. If I can point to one thing, it’s a desire to kind of automate myself out of a job.

[00:12:02] CS: Yes, I heard that phrase before once. One of our security analysts go to security manager, and he was saying, “Automate yourself out of your job. All the things you do manually, that can be sort of automated and processed, you can move one level up in there” Talk more about that concept of automating yourself out of your job.

[00:12:19] SP: Yeah. Well, I’ve always wanted to move that level up, wherever possible. Because I don’t come from a credential background, I never went to a university or college program for computer science or anything rigorous. I don’t have a degree, I have a couple of certificates that I picked up along the way. But I always lacked the credentials to really walk into a high profile engineering position and start calling the shots. Part of my motivation to automate myself out of a job is sort of like, I have to prove myself from the bottom up. Until I can basically say that I’ve learned this to the point where it is dialed in, and you can hand it to someone else, so I can do something else. That was always something that I had in the back of my mind, was like, I can’t move up until I can prove that I’ve got this dialed in. That was a big motivation for me. I’ve always been drawn to bigger ideas, bigger problems, more impact. I had a very strong desire to be moving up and up and up in terms of influence and scope.

[00:13:43] CS: Got you. Thank you. Since we’re talking about DevOps today, for the sake of listeners coming to this concept for the first time, we have a lot of novice security people, and novice programmers and so forth listening to the show, can you give us the the 20,000 foot definition of DevOps and how it relates to the cybersecurity field?

[00:14:00] SP: Yeah. They’ve become very intermingled over the past couple of years. It’s been very interesting. I’ll talk about my perspective on that and how I see that sort of cross pollination or convergence. DevOps is essentially about bridging gaps between different groups and different incentives. That I think is the simplest and most clear way to understand it, is that development and operations are very separate concerns in most organizations. One side is very concerned with going as fast as possible, getting value out to customers, and hopefully getting feedback as quickly as possible and moving on to the next thing.

The other side is very disincentivized from that. They are incentivized to keep the lights on, to keep everything, the status quo to not change at all, because it makes their job much more complicated. That’s a natural conflict in organizations. It’s built in. I mean, it’s kind of unnatural for those folks to work in each other’s favor or accommodate each other’s incentives. It doesn’t make sense.

[00:15:26] CS: Finding the middle ground. Yeah.

[00:15:28] SP: Right. DevOps is really about how do both sides achieve a higher level of performance by combining forces, and leveraging common tooling, and practices and visibility so that they’re not so opposed. Because in reality, they’re not, right? If you talk to anybody in Ops, of course, they care about going fast. Of course, they care about making customers happy and vice versa. Developers don’t want to break things. They’re very happy to be maintaining a extremely high level of quality. DevOps is really a practice of bridging that gap in a way that those two sides are not opposed and they can be leveraging each other’s strengths rather than at odds with each other. I think that all the tooling and everything is just a means to creating common tooling and visibility that they’re both benefiting from, both sides are benefiting from. And where we’re going is now encompassing things like security, and even finance, and planning, and shaping and customer success. That’s why you hear that, Dev, Biz, Sec, Ops.

[00:16:58] CS: Yeah, various alphabet soup versions of all these things.

[00:17:00]SP: Right. It essentially is just pointing to the fact that we’re now working across the entire organization, in value streams that flow from – we have something that a customer wants, or something that we want to provide to – we’ve actually delivered that and we validated that it’s valuable. We understand that that is something that people want, and so we can move on to something else. Keep it going, but do more, do better. Security is one of these things that needs to be present through that entire thread, right? Traditionally, with legacy ways of working, security was a phase, just like testing was a phase, just like operations was a phase. There was the handoff instead of this partnership, right?

[00:17:56] CS: You’re on your own now. You have to take the thing. Yeah.

[00:17:57] SP: Collaboration. Right. We used to be in a situation, and I think in a lot of organizations, we still are – the product teams have come a long way, but we still have these kind of shared services, and dependencies, and bodies inside the organization that I have very specific responsibilities, and their incentives are not aligned. Where you get alignment is in streamlining all of these teams and capabilities, which means early on in the flow, you have security as a consideration in some form. It could be as simple as a checklist. It could be as simple as a quick assessment. Does this raise alarm bells or not? It really just does have to be that simple. Then as you flow through and get closer to the customer delivery, the deliverables change, the concerns change, the scope changes and you get closer to, “Yes, this is safe, this is valuable. This is high quality. This is performance. This is what they asked for and maybe beyond. That flow from start to finish, it really does involve participation and representation from all these different groups. The way that we’re starting to do that is really interesting.

We’re starting to move into scenarios where we have these streamlined teams that have just the folks who are really most key to delivering the product, but leveraging capabilities that get provided by all kinds of different specialist platforms and platform teams. In software delivery, what that looks like is, I have a team that builds and provides developer environments as a service to the rest of the organization. Across all my product teams, anybody can get an environment with a couple of clicks or a Slack message, or a command line call or an API call or something like that. That’s our product. We deliver that to the organization.

Security, I believe should function in exactly that way. We provide secure capabilities, and guidance, in a self-service manner to all the participants across the value stream who need security as part of their value delivery process, right? Early on, that means that as a product owner, I can go into Jira, and when I create a new task, it has security represented as the requirements, right? There’s clarity on this task, or the story needs to be secure. It needs the following things. If it has those things, you can move on. We can progress through the flow. Then all the way down, it starts to look like automated validation inside of a pipeline where the code goes through, and we check the software bill of materials and check the provenance of everything that’s being included as a dependency and all the way. It might actually end up as parts of the release note, the security fixes.

There’s no point in that flow, in that end to end value stream where security isn’t represented in some way. But what you don’t want to do is have a security role inside of each of your product teams, because you might have hundreds of them, right?

[00:21:55] CS: Right. Yes.

[00:21:56] SP: Like having hundreds of them is not a solution, because where are you going to get a level of standardization? Where are you going to get coordination? Where are you going to get common tooling or learning across?

[00:22:08] CS: That’s more rather than less complexity. Yeah.

[00:22:11] SP: Right. I’m a very strong believer in this sort of products and platforms approach with a very loose definition of platform. Platform meaning, as someone who doesn’t do this full time, and it’s not my focus, I can leverage the capability without bothering somebody. That’s usually in most cases today, is I go bug someone from security, or probably, more likely, someone from security bugs me when they notice something that I didn’t do. Eliminating that friction, eliminating the delay, eliminating the handoffs, and those separate incentives is really where we’re going and that’s really what I’m excited about. Because if we talk about security in a platform context, in a self-service context, that security team is 100% incentivized to create a very capable self-service platform. They understand the customer, they understand an ultimate customer to the business, but they also understand internal customers. They can be tasked with providing that service, whatever it looks like. I think that’s really the key to unblocking this high performance flow. That is just ultimately focused on delivering value as quickly and continuously as possible.

[00:23:45] CS: Okay. Can you talk about your four key maps of DevOps and the four by four method for DevOps success? How does your approach differ from other traditional thinking about DevOps or how does it build on it?

[00:23:58] SP: Yeah. Well, I think essentially what I see from a lot of folks in the Agile space, in the DevOps space is, like a checklist-first approach, or based on assessment, or based on maturity, and basically saying, “Here’s a laundry list of things that good look like. If you have these things, you’re probably doing the right things. Where you have gaps, we’re going to help you out. We have a tool for it or we could coach you.” But what’s missing from that is that it doesn’t actually connect to what the organization needs or what they care about. That was something that I’ve noticed over the years and didn’t see good guidance, good practices to address it.

The four key maps, which have now been reassembled into something that I call flow engineering start with really understanding the target outcome. I think that’s missing from a lot of DevOps efforts these days. It’s like, what are you actually trying to do? Because you’re not actually trying to stand up a pipeline, right? Because you’re not in the business of standing up pipelines, right? You don’t get paid for standing up pipelines. Your customers don’t care about your pipeline. It’s starting from that customer connection, the OKRs, the objectives, the mission, the vision, whatever it is, that Northstar that’s guiding your efforts is where we start the mapping process.

The reason that we map is because there’s a lot of different people with a lot of different understandings of what the organization ecosystem, or the team ecosystem looks like, right? They have their own incentives. They have their own understanding of, “This is my job. I work with this person, that person hands me work, and I hand work to that person. I get in trouble when this happens.” But there’s very few people who have a holistic understanding of how all the dots are connected, and how those dots connect to the target, the goal, what everyone is heading towards. By mapping outcomes, what we really do is we get people together. It’s either on a whiteboard, or on a collaborative whiteboard online. We throw around a bunch of Post-It notes. By now, this is a very dialed in process. It’s very systematic, but in the early days, it was really about understanding of all the things that we could focus on, what is going to drive the most positive impact, and then trying to understand what are the obstacles, what are the investigations that we can do to understand more about the current state, and what we’re dealing with.

Then you could tack on all kinds of things where you saw value. You might dig into like, why is this the most important outcome, compared to all the other things that we can focus on, right? What does it really look like? How does this address the biggest challenges that we have? We just sort of build out this picture of what the target look like, and what would have to be true for the target to be reached. That was really powerful for grounding everything else in the sense of context, and understanding, and including people from the very start, because it’s not a technical thing at all. Whatever your focus is, whatever your level of visibility, you can participate and be a part of this. The mapping really kind of brings people together, and everybody starts to get the same understanding of what they’re dealing with. And then we take that, and the next map is a value stream map. That’s essentially just asking the question, what are we doing right now to deliver value to customers? What happens? How long does everything take and where do things tend to fall apart? Where are we having challenges?

What you surface out of that is a few hot spots, and because you’re measuring performance, like you – you at least have timing on how long things take, and so you can sort of prioritize, and you can say these are the top three things. This is the number one, the number two, the number three. If you were to tackle these things, you would see a measurable impact and you could forecast. You could say, things will speed up by 40% or you’ll have 30% less defects, which is pretty powerful. Then you take that, and we look at those hotspots. Not everything, we just looked at the hotspots, and try to understand what are the dependencies that those are connected to? What are the teams? Because often what happens is, people struggle in something like automated testing or security approval. It’s very clear that it’s painful that they have to go to the security team, and file a ticket and then wait. There’s a seven day SLA and it always takes seven days because they have seven days.

That doesn’t get visualized in a way that they can bring something to leadership and say like, “Here’s where we’re trying to go. Here’s where we’re being slowed down. Here’s what’s slowing us down. We’ve been able to bring that to folks and have a really productive conversation about it. The maps really give you this like visual artifact that you can share up, down, across. The last piece, the last map there, this is now probably eight maps at this point.

[00:30:13] CS: Oh wow! Okay.

[00:30:15] SP: I’ve added a lot just for different scenarios, where there’s information that we want to dig into more. It can be any number of maps, but the four that I started with were these four. The last of the four is capability mapping. It really looks at, again, only focused on those key bottleneck areas, the key hotspots that are having the most impact on performance. What are the capabilities that would allow them to level up or address those constraints? Sometimes it’s, we don’t have skills and automation, or we don’t have internal security expertise, so we have to go to the security team and we would map that out. We take those few things, probably five to eight capabilities, and understand, “Okay. Who owns that thing? Does that person have a backup? Do they have documentation? Do they have APIs that they can use? Do they have playbooks? How long have they been doing the job? How long does it take to train someone to do this? You start to form this understanding of, okay, no wonder you’re struggling in these areas, because you’ve got all these gaps. We only care about the gaps that are connected to the outcome, and the specific things that are most connected to what’s holding you back.

[00:31:47] CS: All right. That’s great. You mentioned, for instance the slowdown of like – you have to bring in the security team, and then you make a claim ticket, and then seven days later, they take seven days, because they can and stuff like. Can you give some other examples? What are some of the big points of friction between the development team and the security team that you see kind of regularly? As you work from company to company, are there certain repeating patterns that you see?

[00:32:20] SP: Yeah. Well, I think that it always comes back to incentives. Whenever you have different incentives, you’re going to have a bad time. If you have nothing to align those incentives, then you’re basically set up to fail, because you can’t count on people to do things that are against their best interest. That would be a miracle, and it’s not an actionable strategy. But you can actually leverage a strategy if you’re able to connect to a higher level goal, something that both sides share. In development, and security, for instance, they have clearly opposite incentives. Security probably has something similar to operations where they’d rather things don’t change, they’d rather be able to focus on a small number of variables, less complexity and really lock things down.

Obviously, that works against development in a traditional environment. And really bringing those groups together is an exercise in what are you most worried about? What’s really going to get you promoted on either side, and how do you connect those dots together so everybody gets what they want? That usually means that you pick something that matters to both sides. There’s a high level, some executive, like a CIO or a CTO says, “We need to deliver twice as fast” or “We need to onboard 500 new customers in the next six months.” That is a challenge that is shared by everybody who’s involved, right?

From the security side, it’s, how do you do what you do as quickly as possible and ideally, without manual intervention? How do we do it early, so it has to be baked into development to some degree? How does it not grind development to a halt with too much manual intervention, too much ambiguity? Because you could be doing the wrong thing and then just get corrected, and corrected and corrected, but you’re not empowered to actually do the right thing. I think the sweet spot and where I’m spending a lot of time now with security folks is, how do you make the right way the easy way. I think even beyond that, we have a lot of possibilities now to make the right way, the automated way. If we have to go outside of that golden path, or the easy way, have some practices to understand why we had to do that and some commitment to bringing that into the easy way as soon as possible. I think those guiding principles are pretty simple to grasp. They’re not easy, but they are simple. They really tackle I think the biggest problem, which is just getting those groups to speak the same language, and work together, rather than have to compromise, right? Because I think if we can count on people to have to compromise, nobody’s going to be happy.

[00:36:00] CS: Everyone’s dragging their heels, yeah. I decided to look internally for questions as well. I’m a little out of my depth in terms of this topic here. I was speaking with Erik Nielsen, who is our Senior DevOps engineer here at InfoSec to get his advice, and insight for this interview. I got this question that he wanted me to ask. He said, “I tend to think that DevOps is the logical extension of Agile that the goal is to deliver value as quick as you can, securely and faster than your competitors. Can you speak to the history of DevOps and how it relates to Agile?

[00:36:32] SP: Yeah, that’s a great question.

[00:36:33] CS: Okay, good.

[00:36:35] SP: It’s actually interesting, and I think folks listening will be a little bit surprised by my answer.

[00:36:42] CS: Okay, great.

[00:36:45] SP: Agile actually comes from projects, right? It comes from – we have something that we want to deliver to customers. With the way that used to be done is that you would burn a CD and put it in the mail, or you would install something on someone’s computer. But it wasn’t continuously updated, or you basically never updated until you released a new version of the software. Usually, that was a point release.

[00:37:17] CS: A lot of people didn’t know that they needed to start ask for it or whatever.

[00:37:21] SP: Right, exactly. You’d constantly be battling people to install the new version, because they’re happy with the old version. What does that get me in? Is it worth the trouble? Agile was basically, how do we speed that up? It was essentially focused on speeding it up, and getting better feedback earlier. From that loop of, we’re going to do a bunch of stuff, we’re going to do a lot of planning, the whole waterfall original strategy was just a gigantic effort. Because they were really only focused on these point releases, right? 1.0, 2.0 is the next one. Nobody is – these days, we’re doing point, point, point, point, point.

[00:38:05] CS: Yeah, 2.1.3.

[00:38:07] SP: Every three hours, right? The sense of scale was incredibly different, and the pace of change, because nobody wanted change more often, like once a year. I mean, it was, people were used to infrequent change, and the cost of change was very high. But what happened with Agile and this desire to deliver more quickly, and get better feedback and feedback more often that resulted in better products. At a time when we were developing software internally for companies, we didn’t actually have to mail things across the country, or install things on people’s hardware. We started getting into situations where you could just pull the latest version from a centralized machine, and install it yourself. You could tolerate more change, and more rapid change. It got a little bit more seamless. What happened was, that was very successful. So all of a sudden, you had tons of work, and tons of change flowing through the system. It would just crash up against operations, right?

We just got a handle on the last thing that you guys wanted us to install. Now, you got another thing and this breaks all the old stuff. So, that wall, and that lack of unified incentives and flow, really put a giant strain on operations. You would see these big release days, and you’d have to get all the ops people in the room. Then you’d have to have like, “I don’t know if you were ever in a situation where you were in a NOC, in Network Operations Center.” Watching a release night, and watch all the traffic go to zero and things won’t come back. You see errors spike, and all kinds of things. We were in terrible situations because we couldn’t get these people in the same room, couldn’t get them to talk to each other. DevOps was really about, let’s bring ops into the process earlier, and let’s treat them as if they’re part of the same team. Let’s collaborate together instead of throwing work over a wall to each other.

It was both ways, it was – you throw it to ops and ops is like, “Nope, this is like missing release notes, or it’s, “I asked for this, and I never get this, so they throw it back.” That’s where the incentives were. Ops is like super incentivized to throw it back. Because if they throw it back, they got three more days, before –

[00:40:55] CS: After playing for a while.

[00:40:55] SP: Exactly. But the main piece that’s important to remember here is that, it all comes from projects, it’s all comes from – we’re going to decide to do a bunch of stuff. Even if it’s two things, we’re going to start those things, we’re going to finish those things, and then we’re going to start some more things. There’s only so small that increment can get and that loop can get. All along, what we had from the physical world, actually comes from making cars was lean methodology in the Toyota production method, which is basically work flowing through a system, and the system being very important to work, right? You would have designs, and adjustments, and feedback flowing constantly in both directions. You have work flowing out to customers, you’d have feedback flowing back, and you’d be changing the process and improving the process so that the work and the product was better.

That was a continuous practice that did not fit the way that we used to make software. Because it does not fit when you have to burn a CD, or throw something in the mail or install something on a server. But now, we have all the ingredients to start continuously delivering software. All that old project, framing is starting to become a bottleneck, an issue. Because it’s the wrong model, and this is a personal opinion, since it’s shared by quite a few people, but I will put an asterisk on it. I’m happy to really discuss it with anybody, but I very strongly believe that we were going down this project path for a long time. We got to DevOps, and that brought us to a point where we basically realized we could go no further with that model. You can do things like work in Kanban in DevOps, so you have some flow. But essentially, you always have to kind of reconcile with different parts of the organization that are still doing things project like or Agile like.

But if you were to really back up the car, instead of taking the fork into project world, you followed the continuous flow rode. Then you would get into where we are now, which is value streams and value stream management. Value stream management comes from Toyota, and comes from lean practices and really understanding the continuous flow of work. That model is what a lot of folks are focused on now, because it means security is included from the start. It means that you’re building basically a number of internal value streams, and you have core streams which connect directly to customers. You have supporting streams which connect to the core streams and support the core streams. Security would be a supporting stream that is enabling good practices and positive outcomes in all of your core streams. What happens when you build a really strong core stream, is that you can leverage that capability across all your other streams, right? Sorry, I probably said that wrong. If you build a strong supporting stream, you can leverage that capability across all your core strengths.

[00:44:48] CS: Got it? Yes. I want to move over to the career work side of the question here. For people who are listening to this and want to Get into DevOps or especially DevSecOps, or some combination of prefixes and suffixes, with a security background. I mean, you’re a great person to ask because you learned all of this because you were simply interested in it. But like, what would you say to someone who wants to sort of get into this space now, and what are some things they can be doing in a similar way where they get to sort of like play without consequence, and break things, and figure out how things work and things like that? Do you have any recommendations in that area?

[00:45:33] SP: Yeah. I would definitely – I kind of hit a lot of things with the same hammer. One of the things that I – one of the hammers that I use is this working backwards. Starting from a target outcome, a vision, something that you can sort of put together almost like a press release. This has happened, it was a great success, and here’s why it was successful. Thinking of your career in that context, if I did that, I would have saved myself a ton of time. It’s something that I’ve come to very recently, but it’s just this idea of, if you understand what you want, and you’re able to describe it very clearly to yourself, then you can start to break it apart and break down what it would take to get there. There’s a lot of flow engineering work that I kind of apply in many different contexts. One of those things is this idea of, if I have a target, and you could set it wherever you like, a really good horizon, though is like 12 months out, right? Looking too far in the future is really challenging, because it’s – things change all the time.

They’re always changing faster. But if you say, here’s where I want to be in 12 months, it’s really powerful to tell people about that. Because people like to help, and they like to understand just like what we do with the mapping exercises, they like to be a part of creating something successful. If you tell people, here’s where I want to be in 12 months. Essentially, here are my obstacles, here are the things that I’m going to – I anticipate struggling with, here are the gaps in my capabilities, here’s what I’m doing right now, here are the investigations that I think will move me in the right direction. Then you’re going to paint this picture that really increases your odds of making progress. It’s not a guarantee of success, but you will have connected the dots to your target outcome in a way that you can feel confident that you’re headed in the right direction. But also, I think, and very importantly, you can share that with other people and say, “What am I missing? This is what I’ve sort of put together.” You can show that you’ve done your homework, and that I think is really valuable to people, because nobody wants to feel like you’re wasting their time. But it’s really interesting to see a plan, and try to poke holes and try to understand, “Well, how is this going to happen?”

[00:48:29] CS: Yeah.

[00:48:30] SP: I’m not clear on this.

[00:48:31] CS: That’s so much different ask than help me. It’s like, “Here’s what I got, here’s what I’m thinking. What do you see is the issue?” Rather than, “Can you get me a job?” or something like that.

[00:48:41] SP: Yeah, exactly. People love to poke holes, but they also love to give advice. If you’re asking for advice, it’s much easier than asking for a handout or asking for to pick someone’s brain. Being specific, and bringing your homework I think is really valuable. That starts a dialogue. The clearer it is, the more you’ve connected the dots, more people can say, “Well, I don’t really know about this part, but this piece, I know someone who’s done something like that.” I can connect you to that person. But also, I think the other piece here is that when you work backwards, you start looking at methods and outputs. Eventually, you’re looking at – these are the things that I’m going to do on a regular basis, right? That are going to make a measurable impact so I can track progress, I can actually see. You can base that on a hypothesis, right? If I reach out to 10 people a week, who are in my dream job, and I ask them a question about what are they worried about, what they do in my situation. I share my plan or something like that. Or I’m involving them in an investigation that I’m conducting. They’re going to see the results, so they’re kind of, “They get something out of it.”

Then all of a sudden, you’ve got sort of a recipe for action. It might not be a recipe for success, but as you’re gathering feedback, you will close the gap between possibility and reality. I think that’s very powerful. It’s hard to get a feeling of confidence without that, because it’s hard to say like, “I checked my math and this should work. If it’s not working, I’m going to know because I’ve got signals. That it’s either headed in the right direction or not headed in the right direction.” It can be anything. Daily progress is so important. If you commit to commenting on three posts a day or providing feedback to someone. Being a part of different organizations is so important. That’s one of the things that I think I didn’t mention, but it’s been so valuable to me.

I inherited the DevOps meet up in Toronto, after being a part of the community for about a year, but I was really passionate about it. I got involved, and I volunteered my time and my effort. I contributed, and I always raised my hand and I asked questions. I share my ideas with people and try and get feedback. When the owner of the meet up, his company got bought, he got sent to San Francisco, he said like, “Steve, you got to take over the meet up. There’s no other person to run the community.” I’ve been doing that ever since. It’s been incredible way to connect to people and hear about what’s going on. If I was ever looking for a job, it’d be the first place that I go to.

[00:52:09] CS: Right. The whole idea of DevOps is about collaboration anyway. It’s such a natural extension to sort of collaborate with the collaborators and see. Like you said, poke holes and see what’s missing and so forth. That’s very exciting. As we wrap up, do you want to tell our listeners about visible value stream consulting, and what the services you provide, and things you’re excited to do and reveal in 2022?

[00:52:36] SP: Yeah. Well, I’m spending my time across a couple different initiatives lately. I’m writing a book for IT Revolution that’s coming out next year. Folks can sort of stay tuned with that. There’s a link. We can maybe put a link in the show notes for that if there’s a [inaudible 00:52:57] that goes out.

[00:52:57] CS: Absolutely. Yeah.

[00:52:58] SP: I’m a part of the Value Stream Management Consortium, which is kind of a new organization that’s dedicated to this idea of value stream management, and what it means to software in the digital world and knowledge work. We’re coming up with a lot of groundbreaking stuff that hasn’t really been figured out in the software world. Really excited about that. There’s actually a course that we published on Value Stream Management that I think is a credible resource for anyone who’s curious about anything from Agile, to DevOps, to value streams and flow. It’s all in there, and all the history and how it all fits together. There’s an eBook, so for anyone who’s interested in the collaborative mapping and flow, there’s flow.visible.is has a free eBook that walks through the whole start to finish with examples, and hopefully makes it really clear. Then I’ve got a couple things coming out really soon, that I think folks would really like. Anyone who wants to connect to me through LinkedIn, I spend a lot of time on there. I throw a lot of opinions around too, so hopefully it’s entertaining to folks. I’d love to have conversations with anybody via email, or LinkedIn or Twitter.

[00:54:18] CS: Yeah. I was just going to ask you. Do you have any social media handles you want to promote?

[00:54:23] SP: Yeah. Well, on LinkedIn I’m DevOps TO, so you could find me that way. On Twitter, I’m Steve Elsewhere. My email address is steve@visible.is.

[00:54:40] CS: Perfect. Steve, thank you so much for joining me today. This was a big eye opener. I really appreciate your insights.

[00:54:46] SP: Thanks. Thanks for putting up with my rambling.

[00:54:50] CS: No, that was great. Yeah, I learned a lot and I know our listeners did as well. Thank you again. As always, thank you to everyone who is at home or at work, listening and supporting the show. New episodes of the cyber podcast are available every Monday at 1:00 PM Central both on video at our YouTube page and on audio where you find podcasts are downloaded.

I want to make sure that you all know that we have a lot more than weekly interviews about cybersecurity careers to offer you. You can actually learn cybersecurity for free on our InfoSec Skills platform. If you go to infosecinstitute.com/free and create an own account, you can start learning right now. We have 10 free cybersecurity foundation courses, we have cybersecurity leadership, digital forensics, incident response, security architecture, plus courses on DevSecOps, Python for cybersecurity, JavaScript security, ICS and SCADA and more. Just go to infosecinstitute.com/free and start learning today.

Thank you very much once again to Steve and Visible. Thank you all so much for watching and listening. We will speak to you next week.