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/

Episode Transcript

SPEAKER_01 (00: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 ofDelivery for Rise 8.
How are you doing today?

SPEAKER_00 (00:31):
Hey, Amanda.
Great to see you.
Thanks for having me on today.

SPEAKER_01 (00:35):
Happy to have you on the show.
Well, um, can you share a littlebit about Rise 8 and what
services you provide?

SPEAKER_00 (00:42):
Yeah, sure.
So at Rise 8, we're uh defensetech and GovTech focused.
So we have a lot of work withthe defense sector, and um we're
expanding a bunch of work thatwe have with the rest of the
public sector as well.
We've always been steeped in theVA and now looking at other
areas.
What we do is we build missionunique software for any mission,

(01:03):
whatever your mission is, butspecifically in high compliance
industries where the security ofthat software uh is at stake.
Um, and so we we've positionedourselves as compliance experts
in the public sector, and uh welike to be able to create
mission outcomes for all theusers that we're working with
and uh for all of our clients.

SPEAKER_01 (01:23):
Awesome.
Thanks for sharing.
Well, our topic for today isoutcome-driven software delivery
leadership in high complianceenvironments and what
accountability actually lookslike when large tech programs
succeed or don't.
So, with that, my first questionis from your perspective, what
does good software deliveryactually look like today?

SPEAKER_00 (01:46):
Yeah, that's an interesting question.
I've noticed several of yourother guests that you've had on
the show, on the podcast, thatit's all been uh AI focused.
And we have had an AI invitewithin our company for over a
year now.
Um, we really push ourselves tomake sure that we're being as
efficient as we can be at theengineering level.
And we actually push everybodyin the company to become

(02:08):
technical.
We've held um events in the pastlike Impact Labs, where we're
upskilling everybody in ourcompany to become AI native and
make sure that they're using itto be as efficient as possible
within their work sections.
That being said, uh, we've hadour own kind of Mission OS Live
where we've intervieweddifferent people across the tech
industry that understand thatwhile AI is allowing us to

(02:30):
deliver much higher quantity,um, there has to be a continued
focus on quality.
To answer the question moredirectly, what we think really
good software delivery lookslike in this kind of age where
AI is adopted into all thesoftware baselines is that we're
still driving that softwaretowards mission outcomes,
meaning we're working backwardsfrom a mission impact that we're

(02:50):
trying to affect for the userswe're delivering the software
for.
So whether it was all hands-onkeyboard developing the code or
whether it was assisted with uhagenc development, the outcome
still needs to be the outcome.
Did you achieve the impact thatyou meant to achieve?
And did you do so with respectto the full compliance and
security that's necessary toprotect the mission at the end?

SPEAKER_01 (03:11):
So, my next question is how do business leaders track
that process and make sure thatit doesn't derail and they do
get that return on investmentthat they're looking for?

SPEAKER_00 (03:24):
Yeah, that's a really great question.
We have kind of a full uhcookbook around it, to be quite
honest.
Um, we devote ourselves to it,uh, not necessarily in a
dogmatic way, but we're veryprincipled in the way that we
think that we should workbackwards from impacts, um, kind
of the Kellogg model where thenyou you you determine your
mission outcomes, the outputsthat are necessary to get to

(03:47):
those outcomes, and then theresources and activities that
are necessary for you to achieveuh those outcomes.
I'm sorry, the outputs that getyou to the outcomes and the
impacts.
So I know that that soundsfairly parochial, but in its
most basic sense, there's a wayat the team level that every
single iteration or sprint thatyou're working through at the
engineering level, you can trackthe work that you're planning

(04:08):
for today, tomorrow, this weektowards an outcomes-oriented
roadmap that you've agreed uponwith your users because it's
foundationally built on themission metrics that they need
to be improving on.
Um, and so when you havecommitment like that from the
users of the software, that theyknow you're working on the right
mission metrics, and then yourteam can check in to make sure
that everything along theirroadmap tracks to the outcomes

(04:31):
that are going to improve uponthose specific metrics, you've
now subordinated yourself to themission improvement that you
will really want to stay true toat the team level.
And that's what we focus on on adaily and iteration basis.

SPEAKER_01 (04:45):
Okay.
So, from your experience, wheredo things typically break down
in large tech initiatives,especially in more complex or
regulated environments?

SPEAKER_00 (04:54):
Yeah, there's a couple of different failure
modes that we've seen over andover again.
Um, I myself spent 20 years inthe government, so I was
operating uh large-scale systemswithin a pretty thick
bureaucracy.
Um, and these failure modespronounce themselves on several
occasions.
One is kind of this boil theocean big bang release theory,

(05:14):
where you think you can create amodernization effort that's
gonna replace an entire whatI'll call legacy system, but it
is the operating system ofrecord, right?
This is like in the in opstoday, going to you know, the
fight tonight type of thing.
And if you're building off onthe side and then planning to
just like do a hard cutover of alarge-scale legacy system,

(05:36):
regardless of how many users areon it, into a fully modernized
system, but you haven't beenintegrated all the along the way
and making sure that you'retaking the users along a journey
that's going to allow them tounderstand the usability of the
new system, that tends to failor have massive amounts of
friction right at the releasepoint of the new system.
And sometimes uh that's even ifyou get to release.

(05:58):
Because often when we're doingthese big bang type of
development efforts, you wind upgoing running over on your costs
and running over on yourschedule to the point where it
becomes untenable to the keystakeholders in Congress that
are, you know, representing ourtaxpayers.
And um, for our governmentsystems, when you start running
that far over, I think it isonly the sensible thing to do is

(06:20):
to take a hard look at that,cancel those programs, and then
figure out where you can biteoff smaller chunks to improve
the capabilities that you wereintending without these big bang
releases.

SPEAKER_01 (06:30):
Absolutely.
Well, let's go back to the factyou said, of course, AI is the
key topic amongst many businessleaders right now.
And so, how are you seeing AIimpact engineers and developers
and that reliability that youmentioned?
There is still a bit of a trustissue with the reliability.

SPEAKER_00 (06:54):
Yeah, this is a fantastic topic.
Um, one that we're researchingheavily, and uh I'm working with
a couple other leaders fromother companies too to dive into
this on a journal article rightnow.
In fact, what does productivityreally mean?
Um, and how are you going tomaintain the reliability when
you're using agents across yourthe entirety of your code base

(07:15):
or at least to some uh heavyextent?
And kind of what we found isthat everybody can become
builders with agentic assistancein your development effort, but
not everybody's really greatbuilders.
And it takes the seasonedsoftware engineers to understand
how to interact with the AIagents in the most um healthy
way, I'll say.
And what I mean by that isinteracting with the agents

(07:37):
where you are uh experiencedenough in software engineering
that you can understand when anagent has kind of taken you into
a place that seems likeparticularly hallucination is
top of mind, but it really couldbe anything else.
We've seen agents start tofalsify data to pass test cases.
And it takes a reallyexperienced engineer to start to

(07:57):
see those things that arehappening within the code base.
And so we have a way ofapproaching that that we are
kind of hypothesizing right nowand experimenting with.
But within RISE 8, we stillbelieve really firmly in extreme
programming.
And as a core tenant of that, webelieve in pairing.
So pairing more experiencedengineers with um, you know,
up-and-coming engineers or lessexperienced engineers uh gives

(08:20):
us the ability for them to stillpair, pair with the agents and
still have the seasoned set ofeyes that are helping the
younger engineers understand howdo I test the agent, how do I
continuously prompt it to makesure that what it's doing is
staying within the guardrailsthat we've established.
Um, and so I think there's areally strong use case here for

(08:42):
kind of metering tokens orhowever else you want to
incentivize it, where you keeppairing 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 haveexperienced engineers pairing
with maybe the less experiencedengineers that are now getting
to develop in much higherquantities.

SPEAKER_01 (09:04):
Absolutely.
That process makes a lot ofsense.
Do you think that there's stillan issue with silos and
communication?

SPEAKER_00 (09:13):
Yeah, I don't know that we're ever going to
necessarily break that down.
In fact, it might be gettingdeeper now that people can kind
of go heads down, develop theirown tooling, and then kind of
pop up when something's fullydeveloped.
And specifically, uh, we try andcombat that uh within the
defense sector and mostgovernment uh clients that we
have by making sure that we haveconsistent review cadence that

(09:35):
gets us to bi-weekly demos ofworking software with the key
stakeholders and with uh, youknow, important users uh that
are made to be early and firstadopters.
That forces you to show workingsoftware, not a hypothesized
roadmap or not, you know, kindof a PowerPoint presentation,
but working software of what arethe features that we've

(09:56):
released, what's thecapabilities that exist within
the software now.
And it forces the stakeholdersto stay in tune to where you are
on the roadmap.
Without that, I do see the thesilo effect could become deeper
and deeper as people kind ofwork on their feature set over
here, they're doing securityhygiene over here, they're
working on tech debt over there,because it only takes one or two
engineers to be working on anyone of those mission threads.

(10:18):
But when you're having to demoyour working software every
other week to your primarystakeholders, you do have to
pull all that together to makesure that your demo itself is
coherent and make sure that it'sgoing to stand up to peer review
and stakeholder review uh on abi-weekly cadence.

SPEAKER_01 (10:34):
Absolutely.
Well, AI is rapidly advancing.
What do you see as the nextfuture 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 peopleto develop and get things out
into production before they'refully enabled.
And I think that's always beenthe case.
That's something that we'vestruggled with, especially
within um GovTech, where youknow you have government
employees that don't get as muchtraining and experience in the

(11:08):
tech industry as people that arepurely in commercial industry.
Yet they're expected to live upto the same standards of like um
Dora metrics and achieving eliteDora for deployment frequencies
and things.
So those pressures force peopleto develop more and more.
Now, with the tools at hand, umthey're gonna continue to
develop more and more.

(11:29):
Um, and so I think though weneed to get to a place where we
can understand and give peoplethe latitude that if they want
to raise their hand and say,hey, I need more enablement on
how to use these tools safelyand how to make sure that our
code base stays reliable as I'mincorporating agents into what
are seemingly mundane functions.
Every business leader out thereshould recognize that's not a

(11:50):
fault, that's a strength of thatengineer who's kind of raising
their hand and asking for moreupskilling in these areas, and
then go out there and look forexpert practitioners to come in
and help enable your workforceto be really strong at reliably
using the tools that are at ourdisposal.
So once they start, you know,deploying with much higher
frequency and much morequantity, you can make sure that

(12:12):
they're doing so reliably aswell.

SPEAKER_01 (12:15):
Absolutely.
Well, if there was one keytakeaway you could leave our
audience with today, what wouldthat 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 axleof budget cycles and what comes
out for each governmentorganization that we're working
with.
And then uh it almost forces usinto this like inappropriate
subordination to the budget lineand to make sure that we're um

(12:42):
getting things done so thatwe're invoicing on contracts
fast enough to make thoseprogram managers successful at
spending all their money.
Let's throw that out the windowfor a second.
Like take a big deep breath,pause, make sure you're
consistently working towards themission outcomes that you've
agreed upon with your customer.
This is why we came intobusiness with you.
We wanted to improve thesespecific mission metrics.

(13:05):
Let's keep checking in on thoseand have like the business
review be kind of a secondaryeffect of what goes on.
I would say if there's one keybig takeaway, it's please just
stay focused on the missionyou're trying to improve and uh
let the business operationsfollow.

SPEAKER_01 (13:21):
Exactly.
Well, thank you so much forcoming on the show and sharing
your insights with us.

SPEAKER_00 (13:26):
Yeah, thanks, Amanda.
I really appreciate you havingme on.

SPEAKER_01 (13:29):
And thank you to our audience.
If you have any questions orcomments about this, leave them
in the comments below.
I'll try to reach out as soon aspossible.
And until the next podcast, havea wonderful week.