Delivering High Quality Software with AI

In this episode of "Full Tech Ahead," host Amanda Razani interviews Max Reele, VP of Delivery at Rise8. They discuss outcome-driven software delivery in high-compliance sectors, specifically focusing on defense tech and gov tech. 

Reele outlines that while AI and agentic assistance allow engineering teams to deliver a much higher quantity of code, the ultimate focus must remain heavily on quality and mission outcomes. 

Drawing from his 20 years of government experience, he warns against common tech project failure modes, such as the "Big Bang" release theory—attempting a hard cutover to completely replace a massive legacy system all at once. 

To combat this and prevent deepening organizational silos, Rise8 advocates for rigorous corporate upskilling, working backward from strict mission metrics, and conducting biweekly demos of working software. 

Furthermore, Reele champions "Extreme Programming" and engineering pairing to safely ground AI agents and prevent codebase hallucinations.

Key Quotes

"At Rise8, we're defense tech and gov tech focused... we build mission unique software for any mission... specifically in high compliance industries."

"Whether it was all hands on keyboard developing the code, or whether it was assisted with Agentic development, the outcome still needs to be the outcome."

"Everybody can become builders with agentic assistance in your development effort, but not everybody's really great builders. And it takes the seasoned software engineers to understand how to interact with the AI agents."

"Please just stay focused on the mission you're trying to improve and let the business operations follow."

Takeaways

Implement "Extreme Programming" with AI: AI agents are flooding codebases with volume, but they can hallucinate or even falsify data to artificially pass test cases. Organizations must pair seasoned, senior engineers with junior developers to continuously audit, test, and safely prompt AI agents, keeping code reliable.

Reject the "Big Bang" Release Trap: Attempting a sudden, full-scale replacement of a massive legacy operating system of record causes immense friction, timeline overruns, and project cancellations. Instead, break modernization efforts down into small, digestible bites and integrate users gradually throughout the journey.

Enforce Biweekly Software Demos: The ease of localized AI tooling risks driving engineers into deeper silos. To force collaboration and structural alignment, teams must pull their features, security hygiene, and technical debt together into a coherent, working software demo presented to primary stakeholders every two weeks.

Encourage Engineering Enablement: Business leaders must shift their mindsets regarding workforce upskilling. When an engineer raises their hand to ask for deeper training on how to handle AI agents safely in mundane functions, it should be viewed as a professional strength, not an operational flaw.

Find Amanda Razani on LinkedIn.  https://www.linkedin.com/in/amanda-razani-990a7233/

Follow the FTA LinkedIn Page: https://www.linkedin.com/company/full-tech-ahead/

Visit the FTA website: https://fulltechahead.com/

Check out the Substack Channel: https://fulltechahead.substack.com/

Transcript

SPEAKER_01 0:19

Hello and welcome to Full Tech Ahead. I am your host, Amanda Rosani, and with me today, I'm so excited to have Max Real. He is the Vice President of Delivery for Rise 8. How are you doing today?

SPEAKER_00 0:31

Hey, Amanda. Great to see you. Thanks for having me on today.

SPEAKER_01 0:35

Happy to have you on the show. Well, um, can you share a little bit about Rise 8 and what services you provide?

SPEAKER_00 0:42

Yeah, sure. So at Rise 8, we're uh defense tech and GovTech focused. So we have a lot of work with the defense sector, and um we're expanding a bunch of work that we have with the rest of the public sector as well. We've always been steeped in the VA and now looking at other areas. What we do is we build mission unique software for any mission, whatever your mission is, but specifically in high compliance industries where the security of that software uh is at stake. Um, and so we we've positioned ourselves as compliance experts in the public sector, and uh we like to be able to create mission outcomes for all the users that we're working with and uh for all of our clients.

SPEAKER_01 1:23

Awesome. Thanks for sharing. Well, our topic for today is outcome-driven software delivery leadership in high compliance environments and what accountability actually looks like when large tech programs succeed or don't. So, with that, my first question is from your perspective, what does good software delivery actually look like today?

SPEAKER_00 1:46

Yeah, that's an interesting question. I've noticed several of your other guests that you've had on the show, on the podcast, that it's all been uh AI focused. And we have had an AI invite within our company for over a year now. Um, we really push ourselves to make sure that we're being as efficient as we can be at the engineering level. And we actually push everybody in the company to become technical. We've held um events in the past like Impact Labs, where we're upskilling everybody in our company to become AI native and make sure that they're using it to be as efficient as possible within their work sections. That being said, uh, we've had our own kind of Mission OS Live where we've interviewed different people across the tech industry that understand that while AI is allowing us to deliver much higher quantity, um, there has to be a continued focus on quality. To answer the question more directly, what we think really good software delivery looks like in this kind of age where AI is adopted into all the software baselines is that we're still driving that software towards mission outcomes, meaning we're working backwards from a mission impact that we're trying to affect for the users we're delivering the software for. So whether it was all hands-on keyboard developing the code or whether it was assisted with uh agenc development, the outcome still needs to be the outcome. Did you achieve the impact that you meant to achieve? And did you do so with respect to the full compliance and security that's necessary to protect the mission at the end?

SPEAKER_01 3:11

So, my next question is how do business leaders track that process and make sure that it doesn't derail and they do get that return on investment that they're looking for?

SPEAKER_00 3:24

Yeah, that's a really great question. We have kind of a full uh cookbook around it, to be quite honest. Um, we devote ourselves to it, uh, not necessarily in a dogmatic way, but we're very principled in the way that we think that we should work backwards from impacts, um, kind of the Kellogg model where then you you you determine your mission outcomes, the outputs that are necessary to get to those outcomes, and then the resources and activities that are necessary for you to achieve uh those outcomes. I'm sorry, the outputs that get you to the outcomes and the impacts. So I know that that sounds fairly parochial, but in its most basic sense, there's a way at the team level that every single iteration or sprint that you're working through at the engineering level, you can track the work that you're planning for today, tomorrow, this week towards an outcomes-oriented roadmap that you've agreed upon with your users because it's foundationally built on the mission metrics that they need to be improving on. Um, and so when you have commitment like that from the users of the software, that they know you're working on the right mission metrics, and then your team can check in to make sure that everything along their roadmap tracks to the outcomes that are going to improve upon those specific metrics, you've now subordinated yourself to the mission improvement that you will really want to stay true to at the team level. And that's what we focus on on a daily and iteration basis.

SPEAKER_01 4:45

Okay. So, from your experience, where do things typically break down in large tech initiatives, especially in more complex or regulated environments?

SPEAKER_00 4:54

Yeah, there's a couple of different failure modes that we've seen over and over again. Um, I myself spent 20 years in the government, so I was operating uh large-scale systems within a pretty thick bureaucracy. Um, and these failure modes pronounce themselves on several occasions. One is kind of this boil the ocean big bang release theory, where you think you can create a modernization effort that's gonna replace an entire what I'll call legacy system, but it is the operating system of record, right? This is like in the in ops today, going to you know, the fight tonight type of thing. And if you're building off on the side and then planning to just like do a hard cutover of a large-scale legacy system, regardless of how many users are on it, into a fully modernized system, but you haven't been integrated all the along the way and making sure that you're taking the users along a journey that's going to allow them to understand the usability of the new system, that tends to fail or have massive amounts of friction right at the release point of the new system. And sometimes uh that's even if you get to release. Because often when we're doing these big bang type of development efforts, you wind up going running over on your costs and running over on your schedule to the point where it becomes untenable to the key stakeholders in Congress that are, you know, representing our taxpayers. And um, for our government systems, when you start running that far over, I think it is only the sensible thing to do is to take a hard look at that, cancel those programs, and then figure out where you can bite off smaller chunks to improve the capabilities that you were intending without these big bang releases.

SPEAKER_01 6:30

Absolutely. Well, let's go back to the fact you said, of course, AI is the key topic amongst many business leaders right now. And so, how are you seeing AI impact engineers and developers and that reliability that you mentioned? There is still a bit of a trust issue with the reliability.

SPEAKER_00 6:54

Yeah, this is a fantastic topic. Um, one that we're researching heavily, and uh I'm working with a couple other leaders from other companies too to dive into this on a journal article right now. In fact, what does productivity really mean? Um, and how are you going to maintain the reliability when you're using agents across your the entirety of your code base or at least to some uh heavy extent? And kind of what we found is that everybody can become builders with agentic assistance in your development effort, but not everybody's really great builders. And it takes the seasoned software engineers to understand how to interact with the AI agents in the most um healthy way, I'll say. And what I mean by that is interacting with the agents where you are uh experienced enough in software engineering that you can understand when an agent has kind of taken you into a place that seems like particularly hallucination is top of mind, but it really could be anything else. We've seen agents start to falsify data to pass test cases. And it takes a really experienced engineer to start to see those things that are happening within the code base. And so we have a way of approaching that that we are kind of hypothesizing right now and experimenting with. But within RISE 8, we still believe really firmly in extreme programming. And as a core tenant of that, we believe in pairing. So pairing more experienced engineers with um, you know, up-and-coming engineers or less experienced engineers uh gives us the ability for them to still pair, pair with the agents and still have the seasoned set of eyes that are helping the younger engineers understand how do I test the agent, how do I continuously prompt it to make sure that what it's doing is staying within the guardrails that we've established. Um, and so I think there's a really strong use case here for kind of metering tokens or however else you want to incentivize it, where you keep pairing a really core tenant to the development you're doing, even when you do have agents that are ripping away at it, uh, whether it's during code review or during pure development. I think you should always have experienced engineers pairing with maybe the less experienced engineers that are now getting to develop in much higher quantities.

SPEAKER_01 9:04

Absolutely. That process makes a lot of sense. Do you think that there's still an issue with silos and communication?

SPEAKER_00 9:13

Yeah, I don't know that we're ever going to necessarily break that down. In fact, it might be getting deeper now that people can kind of go heads down, develop their own tooling, and then kind of pop up when something's fully developed. And specifically, uh, we try and combat that uh within the defense sector and most government uh clients that we have by making sure that we have consistent review cadence that gets us to bi-weekly demos of working software with the key stakeholders and with uh, you know, important users uh that are made to be early and first adopters. That forces you to show working software, not a hypothesized roadmap or not, you know, kind of a PowerPoint presentation, but working software of what are the features that we've released, what's the capabilities that exist within the software now. And it forces the stakeholders to stay in tune to where you are on the roadmap. Without that, I do see the the silo effect could become deeper and deeper as people kind of work on their feature set over here, they're doing security hygiene over here, they're working on tech debt over there, because it only takes one or two engineers to be working on any one of those mission threads. But when you're having to demo your working software every other week to your primary stakeholders, you do have to pull all that together to make sure that your demo itself is coherent and make sure that it's going to stand up to peer review and stakeholder review uh on a bi-weekly cadence.

SPEAKER_01 10:34

Absolutely. Well, AI is rapidly advancing. What do you see as the next future issue business leaders need to be ready for?

SPEAKER_00 10:46

Yeah, I think um we're probably in a place where we're kind of empowering people to develop and get things out into production before they're fully enabled. And I think that's always been the case. That's something that we've struggled with, especially within um GovTech, where you know you have government employees that don't get as much training and experience in the tech industry as people that are purely in commercial industry. Yet they're expected to live up to the same standards of like um Dora metrics and achieving elite Dora for deployment frequencies and things. So those pressures force people to develop more and more. Now, with the tools at hand, um they're gonna continue to develop more and more. Um, and so I think though we need to get to a place where we can understand and give people the latitude that if they want to raise their hand and say, hey, I need more enablement on how to use these tools safely and how to make sure that our code base stays reliable as I'm incorporating agents into what are seemingly mundane functions. Every business leader out there should recognize that's not a fault, that's a strength of that engineer who's kind of raising their hand and asking for more upskilling in these areas, and then go out there and look for expert practitioners to come in and help enable your workforce to be really strong at reliably using the tools that are at our disposal. So once they start, you know, deploying with much higher frequency and much more quantity, you can make sure that they're doing so reliably as well.

SPEAKER_01 12:15

Absolutely. Well, if there was one key takeaway you could leave our audience with today, what would that be?

SPEAKER_00 12:21

Yeah, I would say um kind of back to our early talking points about Rise 8, stay focused on the mission, especially here within GovTech. We get wrapped around the axle of budget cycles and what comes out for each government organization that we're working with. And then uh it almost forces us into this like inappropriate subordination to the budget line and to make sure that we're um getting things done so that we're invoicing on contracts fast enough to make those program managers successful at spending all their money. Let's throw that out the window for a second. Like take a big deep breath, pause, make sure you're consistently working towards the mission outcomes that you've agreed upon with your customer. This is why we came into business with you. We wanted to improve these specific mission metrics. Let's keep checking in on those and have like the business review be kind of a secondary effect of what goes on. I would say if there's one key big takeaway, it's please just stay focused on the mission you're trying to improve and uh let the business operations follow.

SPEAKER_01 13:21

Exactly. Well, thank you so much for coming on the show and sharing your insights with us.

SPEAKER_00 13:26

Yeah, thanks, Amanda. I really appreciate you having me on.

SPEAKER_01 13:29

And thank you to our audience. If you have any questions or comments about this, leave them in the comments below. I'll try to reach out as soon as possible. And until the next podcast, have a wonderful week.