What if we've been looking at technical debt all wrong? There is a page in the Thinking Machine that talks about how the engineers from a company Jensen acquired got under the hood with the Nvidia code base. They were horrified. It was an obvious compromise, filled with workarounds, quick fixes, hackey solutions. It was a code base latent with technical debt. Why? Because technical debt is a spoil earned by winners.

While this acquired company had been perfecting its code base, focusing on engineering perfection, Nvidia had been, well, winning. And their code base suffered. I think we see this today as well with some of the really successful companies - look at the Anthropic Claude Code code leak. All the criticism. For what? We should all be so lucky as to have a team that pushes as many valuable products and features as Anthropic does.

So what if our goal should be to incur as much technical debt as possible? Consider the following continuous innovation flow:

1. Take the people with the actual problems - mortgage operators - and provide them with a deep experiential understanding of generative artificial intelligence. This includes all the foundations, how it all works, the risks, the rewards, and everything in between. They will come out of this process forever changed.
2. Give them the tools they need to fix their own problems. This includes big-ass developer boxes, the Claude suite of products, and hands-on education on these solutions necessary to build great solutions. They know the problems they need to solve - this is the huge time save. You don't have to teach them the mortgage domain, they already know it! You do, however, have to teach them to generate (or give them access to) a high quality synthetic test data set for their use cases. Great news here as well, they know the data, and the tools you gave them are excellent at generating synthetic test data, another win.
3. Provision role-based, controlled access to the data they need for those solutions as MCP servers. The organization partners with the operators to understand what data they need, and to provision that data as MCP servers, removing the technical implementation specifics from the operators. Obviously, this is the long pole in getting the innovation pipeline up and running. The mortgage operators with the problems will have a "need to know" the data in question, and you will control the access, so there should not be a problem giving them controlled access to production data. Also keep in mind there will be a ton of use cases for which borrower data is simple not required. Yes we have to be cautious here, and also we don't have to be ridiculous about it.
4. Provide an automated commit process controlled by the operators that moves the locally developed solutions to the organizational github repository. This step kicks of the automated safety review.
5. Perform a thorough, automated safety review. Yes, you can have a human in the loop here if you want. You can insert a chief software engineer here, but wouldn't it be better to just run an automated review? All the security scans and safety protocols you need can likely be automated. So automate them. Keep in mind - you have given them authorized tools and authorized datasets, and they are going to deploy to an internal innovation site. You have already systematically controlled for safety.
6. For solutions that need access to highly sensitive data, the successful completion of this will move the solution to an integrated pre-production environment for testing of these solutions by their inventors with production data. Again, this will not be every solution, but some of these solutions will have to go through pre-prod review as well.
7. Once the safety review and pre-production review are complete, we automatically (or with a human in the loop) move these solutions to a role-based, access controlled internal innovation site. The inventors know who needs access, and those individuals can submit a simple request for access. That access review can be automated, or you can keep a human in the loop. You already provisioned the data here, and you tested the applications for safety. You know who can have access to what data, this can be automated.
8. Now we can harness the value and the learnings, showcase the solutions. The owness is on the inventors to capture the value and document the learnings. We create an easy way for this to be captured, a simple wiki perhaps, and a leaderboard. Who found the most value? What is the best learning? These inventors also make up your innovation working group so they are already meeting and sharing learnings. They will operationalize learning, they will find new problems to solve based on these learnings. They will create the exuberance from their teams and leaders about the solutions through the (weekly? monthly?) innovation showcase.
9. And finally, we will have solutions that we also want to move selected solutions to our enterprise solution base. Identify those solutions and put them into the regular (but accelerated with AI-assisted software engineering) process for enterprise release. Move as quickly as responsibly possible to enhance the core systems, but with less pressure. The inventors have already solved the problem, you've bought yourself a little time.

And the cycle continues. More data is safely provisioned, more learning are learned, more value is created, more wins are showcased. Yes, more technical debt will have been created and will have to be supported and maintained. To the victors, go the spoils.

Yes, I know this is an uncomfortable idea. Yes, we are heavily regulated and we do have to consider access to production data. Yes, this process will have to be battle-tested and tailored for your organization. But, again, these are mortgage operators, they already have access to this information, they know the problems because they are living with them every day. They are already working around these problems every day. Give them the power to solve those problems.

This continuous mortgage innovation pipeline puts the whole process on its head, it skips numerous steps in the product development lifecycle, not the least of which is teaching software engineers about mortgage. Let's face it, this is one of the most delay-laden steps in our current ways of working. So eliminate that step.

By Tela Gallagher Mathias, CTO and Chief Nerd and Mad Scientest at PhoenixTeam