Labs: Programmable Workflows & Policy-as-Code | Ben Lloyd Pearson

0:00After looking at, I think, more than 4 million PRs at this point that have been processed through our platform. The thing that consistently comes up as the biggest slowdown in the software delivery process is around the code review process. So developers write code really quickly. Once it's been reviewed, it tends to get merged quickly. The CIC systems tend to be pretty good at getting deployed to production relatively fast. All of the testing and everything we have, it tends to be pretty good for ensuring quality and efficiency. But there isn't really a lot of solutions out there on the market for people who are facing challenges with code reviews.

0:35In today's fast-paced business landscape, the success of your business relies on the success of your engineering team. And the impact on engineering leaders has been clear. We must deliver exceptional software while driving business outcomes. In short, we have a dual mandate. Enter LinearB, the software delivery management platform designed specifically for engineering leaders. With LinearB, you gain the visibility and automation you need to streamline your processes and unlock your team's full potential. Imagine a world where your engineering organization effortlessly manages business outcomes.

1:09With LinearB, you'll harness the power of advanced analytics and real-time insights, allowing you to make data-driven decisions that drive business success. From tracking progress to identifying bottlenecks to optimizing resource allocation, LinearB has you covered. It's time to take control of your software delivery pipeline and unlock new levels of efficiency. Experience the power of a platform designed by and for engineering leaders like you. Discover the future of software delivery management. Visit LinearBee.io today and start transforming your engineering organization. Hey, everyone. Welcome back to Dev Interrupted.

1:43I am delighted to be joining you live from DevOps Enterprise Summit. I am your host, Connor Bronsden, and I'm joined by one of my good friends, the head of developer relations for Linear Bee, Ben Lloyd Pearson. Ben, welcome back to the podcast. Yeah, it's great to be here. It's been great energy so far at the event. I'm really looking forward to just getting through the rest of it. Yeah, we had a really fantastic opportunity to kick it off at the Dora Community Summit. I know we want to get into a bit about what we learned there, some of the conversations we had. It was very informative. And one of the things that we've been hearing a lot about here is about programmable workflows, which is something that we're very passionate about.

2:16And you in particular have a lot of depth on that. You're building out the free tooling that Linear B is doing for initiating programmable workflows and applying policy as code for organizations. Can you start off by defining for the audience what programmable workflows are? And then let's dig into a bit about why they matter so much. Yeah, I think what it really comes down to is giving developers the tools that they need to configure, program, design, all the sorts of automations, tooling that they need to get software from an idea to deployment into production. So, you know, one area that's done very well in this area is CICD.

2:52There's a lot of tools out there. There's a lot of established practices and processes, a lot of automation. A lot of the toil that developers used to have to spend has now been sort of automated away from them, but using conventions that are very familiar to them. You know, it's configurations, it's coding, it's stuff like that. So, you know, we've spent a lot of time focusing sort of earlier in the process than CICD. We've been promoting this idea of continuous merge, which applies, you know, more of that mentality to like the code review process. You know, so a little bit earlier upstream from like the CI CD system.

3:27And that's sort of opposed to, you know, some of the other workflows that developers might have to deal with day to day. Like, for example, every team has a project management software. Most developers don't really like using it. They know they have to. I love Jira. What are you talking about? Yeah, man, it's a beast. It can be amazing, but it terrifies developers. And it's a big context switch, you know, so anything you can do to make it easier for them to interact with that in a way that's more natural. You know, that's sort of what we're proposing. And, you know, there's also a lot of interest that I've seen around like regulatory and compliance as well.

4:05You know, there's a lot of things that you sort of need to make sure your organization is following, especially if you're like in a highly regulated industry, like if you're in banking or something like that or insurance. So, you know, I've also seen, you know, just so far at this event, there's been a real big interest in having like policy as code, programmable workflows that make sure your organization is mitigating risks associated with. So let's take into that a little bit. What would be a great example of leveraging programmable workflows to create policy as code and maybe help with compliance or security concerns?

4:39Yeah, so if you have parts of your code base that need extra scrutiny or it impacts user data or it potentially could open up security vulnerabilities, you want to make sure that you have the right processes in place both to catch those. But then, you know, there's always situations where you might need exceptions. So having systems built in place that prevent people from getting blocked within those processes. So an example of that might be, let's say we're looking at a part of the code base that we've identified is highly compliance. And there's a high degree of importance to compliance there.

5:12Maybe to your point, it deals with user data. Maybe you want to add an additional reviewer who sits on a certain security team or compliance team to add additional reviews to those PRs. And you're saying we can automate that process or other approaches to it based on however you want to configure your workflows. Yeah, I mean, imagine if you asked a developer every time that they needed to get an exception to a policy to manually go through and figure out which policies are applicable and flag the appropriate people. Like, it's just, that's never going to scale. It's never going to be successful.

5:43You know, so you want to make sure that it's as automated as possible so that you don't miss anything and that you're not just putting toil on your developers that distracts them from the stuff you hire them to do. Do you see this implementation of programable workflows as something that developers are going to be pushed to do in order to implement policy as code in the coming years? Yeah. So, you know, I almost think that it potentially is going to be both ways. I think there's going to be a lot of scenarios where, you know, where an organization might, for example, want to get SOC 2 compliance.

6:13And in a situation like that, it's, you know, the decision is probably made at the executive level. They're going to push down all of those requirements. And, you know, myself, I don't know much about SOC 2, but I know when someone comes knocking on my door and says, we need to do this to get prepared for it, then I know I have to, you know, I have to prioritize that. There's no debate around that. But you can't really expect me or you can't really expect a developer to know when they're potentially at risk of stepping out of the bounds. So a great way to do that is just to have some sort of automation that flags anything that looks like a SOC 2 concern.

6:47So that when you have to go back and verify that you do follow those practices, you have some verifiable proof. But then you also have the reverse of that. I think there's a lot of developers who face a lot of challenges, particularly around the code review process. There's a lot of delays that happen in that area. And a lot of the fixes, their developers scratching their own itch. You know, they don't like waiting on PRs to get picked up for a long time. They don't like having to come back to review code days after they submitted it for review. So, you know, in those situations, I think there's also very much a bottoms up appeal.

7:22I'm glad you brought up the code review process because this is such an important friction point in the software development lifecycle. And we're seeing that come through in the research data. So we did our 2023 engineering benchmarks report, and we clearly saw that there were challenges in code review, particularly for some large organizations. And it's also very clear that when you can merge code faster and kind of speed up that cycle time, you're just able to deliver more value. And it's something that was also followed up by the 2023 Dora report, which we partnered with Google on. And they actually found that faster code reviews were indicative of 50 % higher software delivery performance, a major reason why LinearB has focused in on code reviews as this key friction point to improve.

8:04Can you dive into a bit about how GitStream is trying to approach this and why LinearB is so focused on this key area? Yeah, so we fortunately have a lot of data around this, which puts us in a really great position to have some fairly strong opinions about it. And one of the things we know is, you know, after looking at, I think, more than 4 million PRs at this point that have been processed through our platform, the thing that consistently comes up as the biggest slowdown in the software delivery process is around the code review process. So developers write code really quickly. Once it's been reviewed, it tends to get merged quickly.

8:40The CIC systems tend to be pretty good at getting deployed to production relatively fast. All of the testing and everything we have, it tends to be pretty good for ensuring quality and efficiency. But there isn't really a lot of solutions out there on the market for people who are facing challenges with code reviews. And what we found is that a lot of teams are waiting multiple days just to get someone to look at a code review. And if it's a small fix, like that's demoralizing for a developer. You know, every developer wants to do their part to fix whatever they can. And if they make a small improvement, but it doesn't get any attention for days, like that's demoralizing.

9:18But it's also just, you know, if it is a complicated fix that you have to come back to, there's a massive context switch that only gets worse the longer that that takes. So the difference between getting feedback the same day on code you wrote versus a week later is massive. massive in terms of productivity. And yeah, sure, developers will do other things while waiting on the reviews, but there's always going to be that context switch that you want to avoid. Spend that time to get your brain back in gear and go, okay, the notes that I wrote in this code, what the heck did they mean again? What was I doing here?

9:47Yeah. Yeah. And not to mention, you know, there's lots of things that, you know, lots of practices that maybe they're not clear within the organization. So developers might, they might run afoul of things that need to be flagged. And so the first review could be that it's just a developers saying hey you missed these couple of things that you maybe you weren't aware of or we just changed this and we haven't communicated it or whatever but that causes another cycle you know so yeah that's why we made git stream because it's uh you know we wanted to find a way to help developers find reviewers get them assigned get reviews through more quickly unblock things that that aren't as risky and then you know make sure that any sort of criteria that or requirements that you have for your code base are being considered before you have any sort of human, you know, spend their time to interact with it.

10:35This speaks to that policy as code use case we talked about earlier of like, maybe you're a financial institution and you want to make sure certain PRs in certain parts of the code base are treated in certain ways. And it's interesting you bring up what we're seeing in the data because it has been really clear in Linear B's quantitative data, but we're also seeing a ton of qualitative signal. So not only did the Dora report highlight PRs and has highlighted code reviews for a couple of years now. But we've also seen it with every major enterprise we talk to. If you're the Netflixes, the metas of the world, they have custom tooling they're building internally.

11:05Maybe it's not as configurable, but they have stuff they're doing because they've realized it's a huge problem for them when they scale these massive org sizes. So it's clear there's a need for free tooling that can be brought out and leveraged throughout the community. And frankly, we're also seeing it in developer experience surveys where people are saying this is a huge headache. So I love we're diving in here, But for teams who are considering starting to use programmable workflows and hopefully trying to fix their code review process or other parts of their processes, what are the headaches or challenges with getting started?

11:34Well, there's been a few use cases that we've seen have been fairly consistent. One of them that I think is a great first bite out of this is identifying or it's building code expertise and then assigning those experts to be the reviewer on relevant PRs. You know, you always got to consider the bus factor. You don't want to have a single person that's always in charge of reviewing everything because it creates bottlenecks. You know, what happens when they're out of the office or you can't get them because they have other priorities. So a lot of organizations are looking for ways to implement policies that enable their team to share knowledge across the organization.

12:12And then once that has been distributed, empowering them to take reviews into their own hands rather than having to depend on a select few. So that's been a very obvious one. In terms of compliance, there's a lot of concern about one use case that comes up in SOC 2 is making sure that you're tracking every change that goes into your code base in some sort of centralized repository, whether it's your project management or some other BI solution. And once again, developers, they hate going into Jira, but they need to say, this PR is part of this project over here. And if you can do that without forcing them to constantly have to have multiple tabs open, switch back and forth.

12:57Get some automation. Get URLs. Yeah, just automate all of that away. It's a toil that developers just, you know, they don't want to do. They have to do it. They can sort of take off their hands. And so those are the sort of like two major use cases. But I mean, we really see just very broad adoption, but there's a lot of like small, low hanging fruit, like small things that you can just implement just to make your developers' lives a little bit easier. Is this thing like integrating into the testing suite or CICD and trying to apply that? What are you thinking? Yeah, I mean, if you have a CI pipeline that, you know, maybe you have too many jobs or maybe you have so many jobs that you don't need them for every PR, like, but maybe your developers are waiting on them for every PR, like that, you know, you're just wasting their time, like waiting for something that may not be relevant.

13:42So why not skip a few of them and or only trigger them if they're necessary for the code that's being changed? What I'm hearing you say is that GitStream is facilitating programmable workflows that not only cut down on manual effort, but also facilitate faster feedback loops. Would that be an accurate way to describe it? Yeah. So, you know, we can do things like estimate how much time it's going to take to review a PR. So you're a developer, you got a meeting in 15 minutes, you think, well, maybe I can go look at a PR real quick and help one of my teammates. And then you open it up and find out it's 500 lines of code that have changed across a dozen files and multiple subsystems.

14:23And all you wish is like, I just wish I could unsee this so that I can go back to the rest of my day and get on with my life. But if you could tell them, you know, there's that one, that's a big one. So save that for when you have time. There's this other one over here that, you know, maybe it's smaller. It will only take a couple of minutes to review. It's a really great way to just help your teammate out super fast. So there's stuff like that. There's, you know, finding when someone is, you know, maybe accidentally using some deprecated APIs or something. Maybe you have somebody in the review process that's going to catch that.

14:54But why bother them? Why not just catch it automatically ahead of time and let the developer know immediately so they have that immediate feedback about what needs to change? Reduces the context switching piece. Let's make immediate changes. Makes total sense. How are you going about adoption for programmable workflows? I know it can be a big change for some teams. What do you do to really get folks to buy in and actually get their leadership to get on board with these big changes? Yeah, find your pain point, your biggest one, and just solve for it and start there. and then just go down the list, find the next biggest one and so on and so forth.

15:29A great place to look first is Dora. Get some Dora metrics in place so that you know sort of how you benchmark against other organizations, where you might have the biggest slowdowns. I wouldn't be surprised if you find that, like we've predicted, it's often in the pickup and review time. But if it's not, there's other practices that you can take. But, you know, Dora, that's one of the great things about Dora is it's a really great like value oriented framework that leads to these sort of natural technological solutions that solve the problems. Yeah. And I'll say we were listening to Nicole Forsgren talk earlier, too, about extending that and applying the space framework and saying, OK, like you've started with Dora.

16:11What's the next step for you? Is it maybe you should be paying attention to your PR review sizes? Maybe that's a really crucial early indicator for you. Or maybe it's developer happiness through your devx surveys. It's like a key North Star metric for you. And I think that's a great way to think about it and say, okay, like, let's identify the things in our cycle that we want to move faster. And then we can apply tooling to reduce those friction points, try to speed it up and make our developers' lives easier. And I think an underrated aspect of this is that if you apply these programmable workflows well, you're actually going to make your dev team feel better about what they're doing too.

16:42It's less of the work they don't want to deal with. It's less context switching. You're going to have more good days for them. And that opportunity is great for recruitment. It's great for retention. It's great for productivity. I love to hear it. Do you have an idea of where you see Getsroom going next, though? Our goal has always been sort of maximal extensibility. You know, we want to be sort of a glue in between just about every other tool in your developer stack. So that's definitely a direction that we're going. And we also, you know, we really, I want to touch on a couple of points you mentioned there, because, you know, there's one common theme I've heard so far at this event is developer well-being.

17:18Like, it's a very big concern. And a lot of those conversations have been centered around, for example, the McKinsey metrics that focus more on effort and output rather than any sort of value stream changes. And I think there's a lot of concern that those sorts of approaches don't really take the developer quality of life into account. And I feel like that's where Dora plus space is really trying to account for. It's like the metrics that quantify the challenges that you're facing, like that feels kind of in the Dora realm. And then the I don't really know if they're metrics or if it's just a more of a mindset framework to apply to decide on what you want to measure next.

17:58Yeah. Yeah. And that focuses much more on just your organizational well-being, you know, because we know happy developers do better. They're more productive. They ship software faster. So I feel like it is almost like a response to, you know, we don't want to we don't want to analyze developers in a way that makes them feel pressured. We're not telling you this is the tool that's going to, you know, increase the number of lines of code you change. We're telling you this is a tool that's going to unblock things that you might be struggling with. Ideally, it should reduce gamification of metrics because I know that's a big concern for a lot of engineering leaders.

18:31And it's a valid concern. Goodhart's law says that when you start setting goals against measurements, you're going to see them improve. but you know it's a lot easier to create one 10 pound nail than you know a million small nails so you're like great i need to create 10 pounds of nails let's do one big one you didn't specify and that gamification is not what we want to see we want to see a process that moves faster and works better for everyone and so getstream is a great way to say let's put tools in the hands of developers where they can set the process up in the way that they need to have it done and also fulfill the needs the c-suite and say okay great now policy is code for compliance awesome and now we have higher efficiency throughout our pipeline.

19:07Fantastic. We deliver more software faster, more predictably. But ideally, it needs to be one where we're putting in the hands of devs and making their lives easier. And so I love that approach is being taken. And I would love for us to get to a place where we can surface those insights to the managers. So we can say, you know, they can log into, like, say, their Linear B dashboard, get their Dora metrics. And within that, see some sort of like breadcrumb that says, you know, we've detected that there's an issue over here, there are automations that you could implement to solve that. Or maybe we have some knowledge or base resources that are beneficial.

19:40So obviously, I think we're both just big fans of programmable workflow tooling. And I know we're talking about linear bees, GetStream in particular, it's free, it's available. What are some of the integrations that are set up already in GetStream that people can start to leverage? So we've been hard at work building out a pretty robust integrations marketplace. You know, like I mentioned, we really want to be the glue between a lot of popular developer technologies. So we're looking at your project management stacks, whether you use Jira or Asana or Shortcut. We're finding ways to integrate with those.

20:10We recently built some integrations with, well, one of my favorites, our new integrations with GitHub Actions, which lets you orchestrate your CI pipelines effectively. So you can decide that if, let's say, this code changes my mobile app only, well, I only need the mobile build process for that. so I can choose to ignore the rest and just run the processes that I need. So that's a huge time saver that I'm really happy we were able to ship. We also have now enabled outgoing webhooks so you're able to connect GitStream to practically any service that has an API. So if you want to send Slack notifications, if you want to auto-update JIRA tickets, if you want to send a pager duty alert, whatever tool you want to send some sort of alert from your Git repo or from a PR, we can now enable that.

20:58This list is only going to grow. I encourage people if they want to check out what we're doing just to check out docs.gitstream.cm where we're building out all of our integrations. Fantastic. Ben, this has been a wonderful conversation. Thanks for giving us an update on what's happening in programmable workflow land. Very excited to see where this goes in the next couple years. To your point earlier, I think it's a crucial thing that we're seeing being called for in a lot of enterprises. This has been a lot of fun and especially doing in front of this live audience, people walking around us here in the dome at DevOps Enterprise Summit in Las Vegas.

21:28Thanks for listening, anyone. And if you are interested in GitStream, as Ben mentioned, docs got to gitstream.cm. Learn all about it. You can add it to your GitHub right now. And yeah, thanks so much for writing out those great docs, Ben. Thanks for coming on the pod and we'll have you back in soon. Yeah, absolutely. Thank you. And if you're listening to this and you want to see Ben and I flail around, accidentally hit mic stands, maybe have some bloopers in here. We'll hopefully edit some of those out. Check us out on YouTube. We'll put the clips on LinkedIn as well, but you'll definitely find the full video on YouTube.

21:56It's a lot more fun to kind of see the experience of what we're doing here. So thanks so much for listening, y 'all.