Andrew Moore: Innovating Under Constraints - Driving AI and Efficiency in Mortgage Lending

This transcription of the podcast is AI-generated and may contain errors or inaccuracies.

Matt

My name is Matt and I will be talking with Andrew Moore about effective team management and productivity strategies amidst market and resource constraints. I wanted to talk to talk a bit about difficult things, but I think we can start with something simple to just, you know, warm up ourselves. But it's Monday so I think we, we need it a bit. So you work at the nation's lending, you are responsible for software development and software in general out there. It's a quite decent organization, I think like a bigger number of couple hundred people. So you have a huge impact and maybe you could start, start and to describe a bit your team structure, like with whom do you work?

Who is your partner in crime?

Andrew Moore

Sure. So I think it's important to set the context for what my role is in the organization and what technology's role is in the organization. So because this is an international podcast, we're a, we're a mortgage lender in the United States, which means that where we're manufacturing loans for individuals that want to purchase houses and Currently as of 2024, time of this recording, the market is not as great as we would like it to be. Which means that in technology we're not often seen as the, the forefront. So when, when budgets get cut, we're on the list, so to speak. But what that means for, for my organization structure as of the last couple of years, I've had to really flatten it out. Everybody that's here has a very specific role and everybody on the bus is, is able to provide value directly.

So right now what that looks like is I have a software engineering team, I have a call, an enterprise applications team that manages sort of the administration of some of our systems. And then I have a data team that's, that's performing business intelligence reporting. We're getting into more machine learning and AI, we're trying to move the needle and continue pushing forward. Even though we're staff constrained and we're budget constrained, we don't take lightly to just sitting on the sidelines. So we're still pressing forward. And largely every one of my team members is empowered to provide value directly that you can reach out to end users. They can take a request that came in through our support desk or through a, through a conversation and they can re engineer it.

They can basically take the agile approach to develop solutions that fit the organization the best. Not exactly how the ticket was written.

Matt

And you mentioned the thing like the R and D. Right. So one of the things is AI, which is super hot topic right now, especially in software engineering. So do you have any interesting projects running around it?

Andrew Moore

Yeah. So a lot of how we think about work and value in the mortgage industry is does it provide revenue or does it cut costs, approve efficiency? And I also realize that that's not unique to mortgage, but it's always a hot topic for us. So from an AI perspective, we're looking at things from two different sides. On one side we're looking to provide decision support for loan officers. So a lot of times in, in the US there are many different mortgage programs that you can, that you can underwrite and they all have different requirements. And as a loan officer, I may be faced with any of a hundred different scenarios in which a borrower has really good credit or they may have poor credit, they may be trying to purchase a not necessarily cookie cutter property.

There's, there's a lot of different scenarios and they have to be able to, to abide by guidelines. So we're looking at Chatbot large language model type guideline support so that a loan officer can say, hey, what's the minimum FICO for this particular product? Or can I, can I move forward with this product? It's a renovation loan for a manufactured house, etc. And that, that gives us higher data quality at initial submission, which means that ultimately that loan funds quicker. It's more likely to fund everything hinges on having that good data quality up front. So we want to, want to meet those loan officers where they are.

And on the other side, on the revenue generation side, we have a, we have a lot of work around identifying solid leads, identifying good markets for cold outreach, identifying leads that we get from, from other lead sources, and making sure that those are the high quality leads that justify dialing out on and calling on. It's kind of a sales lead qualification approach that we're doing on the other.

Matt

Side and always wondering about the objectives and the specifics of the industry in which you are. But from the software engineering perspective, and you work in a few different industries, you work for the healthcare, for the manufacturing, and now mortgages. And I'm just wondering, do you see any specific objectives that you have in mind for this particular industry? So you already said the optimizing the roi, getting more bucks from like lower budgets. And I think it's valid for everybody in general, but maybe like something specific here around the engineering.

Andrew Moore

Yeah, so we've kind of looked at this a couple of different ways and I'm fortunate to have an engineering staff that is very aware of information security and data security. So when generative AI came, I'll say came back into vogue what about a year and a half ago with the introduction of, example GitHub copilot. We, we, we I, I had it elevated or escalated to me, hey, we'd like to, we'd like to test out this product. And we did some, we did the research, we looked at the, the data protection agreements, we made sure that before we, we let this tool out loose in our, our code base that we knew what was happening and where that data was going and ensuring to a degree that our code base and our, our queries weren't being used for micro training things of that nature. But We've been using GitHub Copilot pretty successfully for about a year now and I've seen some meaningful uptick in productivity. A lot of it is anecdotal, but I think within the software engineering space, leveraging generative AI, whether it's Copilot or I'm sure there are other options, I'm just not familiar with them. Has been a very good addition.

The way that my engineers describe it is like a smart Google. So I can ask questions and as developers we get really good at googling things but when I can ask questions in context and get answers in context, that short circuits a lot of that searching process that we go through. And so we've seen that work really well. And the code generation, it's hit and miss, it's not great but when it does work it really short circuits a lot of the, call it the menial labor of setting up classes or building out these big structures. I think that adds some efficiency, but not nearly as much as the searching and question and answer type functionality.

Matt

I'm just wondering in which comp are you, I mean you mentioned the GitHub copilot and I think there are two camps in tech in general. One camp is saying in the future we will build more software and faster and the second camp is saying like we will need less developers because AI could like do it for us. I'm just wondering what is your view here?

Andrew Moore

So I'll try very hard not to give you an it depends answer but I read an article years ago, maybe six, seven, eight years ago that claimed that software engineering was becoming more blue collar. And at the time I was hands on keyboard engineer. Yeah, I don't like that, that doesn't sound great. But what I'm seeing as we develop more generative AI, as we develop more of these AI capabilities is that that blue collar component, the parts changing, the, the keeping up with security patches, the Add this new field here, very well defined specs that you would typically assign to like a junior engineer or somebody that's very new. A lot of that I believe is being migrated into call it AI as that support which leaves the engineers to do engineering versus upkeep and maintenance. Does that mean that we will require fewer, fewer developers? Maybe, maybe not.

It's, and it's the same for, for any other application for AI. There will be those that adopt it and use it as a tool and then there, there will be those that either stick it over in a corner and refuse to use it because it's evil or it's, it's going to take my job or whatever and ignore it. Those people will likely be overtaken. You know, I don't know that they'll be made redundant, but if you're not using all of the tools available to you, then you're doing yourself a disservice because as you've seen, the force of technology is inevitable. The change will happen. The question is whether or not you're able to make the change effectively and adopt it in a way that works for you and your business.

Matt

Well said. It makes sense. And what caught my attention when I was preparing for our talk today is the thing that he put on the LinkedIn that you reconstructed. The software engineering team. You increase the capacity by 300%, improve the whole system, the processes around it, implement the new engineering practices. So I'm always trying to get something actionable, something like for other leaders, for our tech leaders. In this case, we're software engineering leaders that might take like a bit of your secret sauce for their software teams and implement.

So maybe you could share some examples here around it.

Andrew Moore

I think the, the two most critical things that I can relate back to my success being able to build effective engineering teams. One, the, I believe it's a Pascal quote. That which, that which can be measured can be improved. So when I joined this company and other companies as well, tracking productivity and tracking work and priority and velocity wasn't a priority.

And as a result everything was had the same amount of importance. So you have engineering staff that are working on the thing for the person that yells the loudest or the most recently. And as a result you wind up with a ton of context switching where a developer will be working on something and then somebody comes and yells off the right stage, right?

Then they have to pivot, they work on that thing. Maybe they finish the other thing, maybe they don't. But you have a ton of work in progress and that, that Slows down the machine. Because I have all of this loaded in my brain, maybe I am really good at context switching and I can fully set it down and switch to this new task. But in reality there's some cognitive load that remains for all of the work that you have in progress. So the first thing that I did was after instituting an agile process flow, getting into the backlog refinements and Sprint planning and being more rigid about what we work on and when we work on it was stand up some KPIs and metrics for, for tracking productivity and throughput. So I started looking at Velocity by Sprint, I started looking at Velocity by Scrum Team so that I could understand, you know, functionality and practical velocity.

I started looking at throughput time, so lead time and cycle time. And I started looking at more backlog composition, how how many of my tickets are actually sitting in active, how many of them are sitting in and done. How many of them are sitting and testing to understand where our constraints are.

That honestly took about a year to stand up and get solidified. And now I've been at the company three years where we're in the groove and it's moving. So what we saw very quickly was kind of a J curve or a hockey stick on the. The velocity because not only were we tracking everything, we were starting to see the performance benefits of sticking to the system and allowing the system to work for us. Nice.

Matt

I think it's a great example. It reminds me implementing the OKRs in our organization that with it so like the first year it was like collecting the data and kind of understanding like how to work with that and based on that you started to put the goals and it starts started to work right. So we need some time.

Andrew Moore

And I'll say on the other side of that, OKRs are a great system when done well. The. The other thing that I had to institute to really be successful is starting to have more of a product steering committee. So no longer was technology sitting in the dark and saying, sure, I'll do everything that you kick over the wall and then I will feel bad or I'll complain because I don't have capacity to do it immediately or quickly. I started having more direct conversations with our leaders across the board and our ownership to say we can't do everything. We have to pick the truly meaningful items to work on and then those will be triaged first. And beyond that, we'll have to triage maintenance and change requests as they come in and we'll make sure that we're doing the things that we have to do to keep the lights on and then after that if we have spare capacity, we'll pick up some other things.

But we really need to make sure that we are doing the right things and we're doing them at the right time or else all of that work that we've done to build the efficiency and the workflow in the process isn't for anything because we're going to be working on on the wrong things.

Matt

I really like to look for contrarian opinions or maybe controversial opinions or in the ways how the leaders work. So I mean do you have some approaches, routines regarding the leading the software engineering teams that are not so obvious? I mean, but words for you, right? Like some processes maybe approaches?

Andrew Moore

Yeah, I think where I go for controversial opinions and I think my perspective is pragmatic but you know, everybody's is right. What I think about is how we manage product, how we develop acceptance criteria, how we develop roadmaps, and the overall plan for developing work. In a lot of, I'll call them traditional agile environments, you have very specific roles. You have your product owner, you have your scrum master, you have your development team or your scrum team. And each of those roles are walled gardens that do a very specific component. In my past I've been in opportunities to have feast where there's plenty of budget to hire all of these roles and bring them all together and everything works great. But in a lot of scenarios I've been in a famine situation as well where okay, we have to make decisions about what roles we bring on and who's sitting on the bus.

And that's put me in a position where I have to learn how to manage a product without necessarily having the product roles. And the most controversial I can make that is I think that engineers are able to fill product ownership, product management roles if given the right coaching, if given the right leeway. The end result is that you get more accountability for your team than you would if you had those individual roles. If you have a product owner and you have an engineering team, because that engineer has to go first, understand the problem. They can't rely on the game of telephone to say, well, the product owner says this is how it's used. So I'm taking their word for it, they have to go understand it. And engineers by nature don't really want to start on things until they fully understand it.

Which means that they have to learn how to interact with end users, with stakeholders, and learn how to bridge the gap between technical criteria and acceptance criteria and User interface. So at the end of the day, I think it is fully possible for your engineering staff to fill a product management role if you as their, their engineering leader, understand what's required and what comes out of that. You need to know that there's going to be delays in developing acceptance criteria as they come up to speed on how does my business actually use the product and if we haven't picked it up yet, I'm not doing a ton of B2C work. I'm supporting an internal business. So a lot of my users are employees of the company. So that does put me in a say, slightly advantaged situation. But I think it applies anywhere.

If you're looking for developing specification, your engineering staff is more capable, I think than, than a lot of people would give give them credit for.

Matt

Andrea, to continue the topic of tough questions like I'm just wondering if you could describe, describe me a time when you were a part of a controversial decision impact the team on the leadership side, on the engineering side, what you did and what you learned from it.

Andrew Moore

Sure. So I'll describe a past scenario. So this, this isn't related to my, my current employment, but we had a, we had a situation in which our executive leadership wanted to, to externalize a lot of our data into a new system, a system with Salesforce. We wanted to expose a new way for our sales team to interact with our underlying data. And at the time I was an engineering team lead and so I was responsible for executing against the design and the architecture. We went a very long way down the wrong path and we only learned that once we rolled it out to production and everything went terribly wrong. So tactically I was able to get everything, the ship righted and everything's good to go, but then we have to, we have to post mortem, we have to come back and figure out what's going on, what happened, how did we get here?

And fundamentally what I learned was you have a, you have an architectural design that's built, that's documented. However, and as you execute, you diverge from that architecture. So just by nature it's a calling it. Applying the laws of thermodynamics, you're tending towards entropy. You have to put in effort, conscious effort to ensure that everything you build is always iterating back towards the design, back towards the requirements because you can very easily get blinders on, you can very easily get distracted by completing your user story or finishing the feature that you're working on and you're always divergent. So whatever that cycle is, if you're in sprints every two weeks or however frequently someone needs to be asking the question, how does this align to the design? How does this align to the strategy?

How does this align to the requirements so that you're always, you always have that in the front of your mind versus completing the tickets.

Matt

Let's talk how it is nowadays for you regarding the challenges and pain points. So I believe like each year there's a theme for a new challenge or pain point that we go through as a leader and we learn something new. And one of my recent guests mentioned rewriting some legacy application and legacy software. It's like his theme for 2024, how to do it. Like how to approach it and not to fail. And I'm just wondering in your case, do you have such a challenges or pain points or yourself?

Andrew Moore

Yeah, I think the, the biggest challenge that we have today is said nicely. It's technical debt said more frankly, is paying for the sins of our past. We're, we're in a scenario where we've been in an application stack for 15, 20 years and there have been multiple iterations of engineering staff that have had their hands in this platform. And everyone has their own opinion on best practice. And thus far those opinions haven't really aligned with each other. So you have it's, I call it archeology. As you dig down, you see different layers in the, in the structure and you see how this thing developed.

But as a result, performance has not been great. The, the performance has gradually degraded over time. And so really the main focus for us as we're doing work is to externalize process wherever we can align with, I'll say industry best practice, not necessarily company best practice, looking more towards asynchronous development, webhook based, event based work as opposed to transactional. And all of that has to be done while we keep the lights on, just based on resource constraints and capacity. I'm not in a situation or in an ecosystem where I can sell a ton of sustainability work. They don't see that value yet. So the biggest challenge is moving the ball down the field, continuing to make improvements and enhancements while doing the actual business value work.

Matt

And the last question that I always ask all my guests, I wanted to ask you for any recommendation regarding the books, maybe podcasts or conferences that have been particularly helpful. Helpful to you as a, as a leader?

Andrew Moore

Yes. So for conferences, I'll definitely recommend the Gartner Symposium. It's not cheap, it is very pricey and I apologize for that. But I was able to Attend this last year and it is a fantastic experience if you are a strategic leader in your organization around technology. Because you get the opportunity, like most conferences, to take yourself out of the context of your business and put yourself into the mindset of technology at large. See what's going on, see what's developing. But while you do that, you get an opportunity to talk with other experts and other people that are in your shoes.

And how did you solve this problem? While I know that that happens at other technology or at other conferences at Gartner, I think the level of quality of attendees and speakers and hosts are second to none from what I've seen thus far. The book I will offer, and I'm talking slowly, intentionally so I can Google the authority, but I actually heard him speak on a friend of mine's podcast last year or so. It's called the Manager's Handbook, written by David Dodson. I think I would recommend that for anybody that is looking to either get into a leadership role, whether you're an engineer, you're a senior engineer, and you're deciding do I want to be a team leader, do I want to be an architect, or do I want to continue down the, the individual contributor path? It's a short read, maybe in a, an afternoon or two, depending on, you know, how much you dig in. But it really summarizes a lot of concepts that frankly, I had to learn the hard way in how to, how to lead people and how to manage effectively when you have a wealth of unknowns.

So I definitely highly recommend that book. And if, if you're, if you're sitting in a seat where you're a CIO or you're a VP and you've been doing this for 20, 30 years, I still recommend it because it gives you an opportunity to reframe some assumptions that you've made or maybe it puts something that you learned and have internalized into better words and allows you to understand, oh yeah, this is why I do that.

That's, that's interesting. I always recommend introspection. No matter how long you've been doing something, especially if you've been doing it a long time, make sure that you understand why you're doing the things that you do and always question maybe, maybe the thing that you've done for 20 years that's worked well so far isn't the best way to approach things. So I think that's why I fundamentally like those high level leadership management books.

Specifically, again, Manager's Handbook. David Dotson.

Matt

Awesome. Thank you very much, Andrew. We cover a lot of interesting topic topics. Thank you for the conversation and your thoughts. Questioning everything. It's definitely something that I will remember after today's talk and makes totally sense to me.

Andrew Moore

Thank you. Yeah Matt, I appreciate it. Follow Matt on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍