Inside the Mind of the Chief Architect at Index Exchange

With over a decade of experience spanning various industries, Chief Architect Josh Prismon shares insights on his journey from guiding the architecture of FICO to his current role enabling media owners to grow revenue and marketers to reach consumers on any screen at Index Exchange. From the democratization of credit scores to the ethical considerations of AI use, Josh provides a comprehensive overview of the intersection between technology, privacy, and innovation.

Join as we discuss:

• The transformative impact of technology on credit scoring and financial services.

• The importance of balancing technological advancements with privacy-focused ad tech.

• The critical role of app architecture in navigating data privacy and regulatory compliance.

David Joy:

What is up everyone and thanks for tuning in. In today's episode of The Big Ideas in App Architecture podcast, we speak to Joshua Prismon, who is the Chief Architect at Index Exchange, the company that is enabling the evolution of ad tech. In this episode, Josh and I get into how his team is building and architecting to solve complex problems at Index Exchange and for their users. We also get into Josh's 17-year experience working as the chief architect at FICO, and we talk about some of the work that he has done supporting the decision management platform that you and I experience on a day-to-day basis. It's an episode that is filled with golden nuggets and great ideas from one of the best chief architects that I have spoken to in my experience. So pump up that volume and get ready for a great conversation with Joshua Prismon. Welcome to The Big Ideas in App Architecture podcast, Josh, how are you doing today?

Joshua Prismon:

I'm doing excellent and yourself?

David Joy:

I'm doing all right. It's like a scramble, as I was saying earlier. Monday you have to go through a bunch of things that you thought you will do on Monday morning, and then you realize that you left too much on a Friday, so that kind of thing. How about you?

Joshua Prismon:

Oh, I have a conference that I'm going to be speaking at later on this week, so I'm trying to get everything done before getting up incredibly early on Wednesday to start the travel and the prep for that. So it's going to be a busy week for me.

David Joy:

When I was talking to Josh before, I was super excited with his background. And just for everyone, Josh has been a chief architect for about a decade plus in my opinion. And when I went through your LinkedIn, I saw you've worked at FICO about 17 years as a chief architect working across multiple different projects. You worked on their demand or decision making platform, if I'm not wrong?

Joshua Prismon:

Yeah, decision management platform.

David Joy:

Management platform. There you go. You did work on the AI/ML side of things as things were innovating, and then you've also now the chief architect working at Index Exchange, which is an ad tech business. And I had no idea how that business worked until I had to start researching about it. So we want to get into all of that today. So as we just begin, tell us a little bit about your FICO experience and how did all of that start actually?

Joshua Prismon:

Yeah, so interestingly enough, FICO more or less started for me in high school and amazingly enough it was because of the internet. I came up through the Boulder Valley School District and the Boulder Valley School District was one of the very first school districts that was on the internet. And as part of that, they actually had a group of students who got together and were very early system admins for all of the other students on there because a lot of the teachers didn't yet understand the technology. And that connection was provided by the Colorado Internet Co-op, which is one of the very first internet exchanges in the US. And a company called XOR, way back when was actually responsible for maintaining the Colorado Internet Co-op, and I ended up eventually going and working for them. Then basically the dotcom stuff started spinning up and that company started doing more work inside of the marketing space.

Then the dotcom crash occurred and the company very quickly, like a lot of other dotcom companies, started to have to challenge and change their business model. Eventually we were acquired by a company called FICO, which I think a lot of people in the United States will be very familiar with them because of the FICO Score, which is a score that basically predicts your credit worthiness. But it also is a company that was involved in fraud detection for credit cards. It was involved in figuring out credit line increases. It was responsible for doing targeted advertising as well, which is how I ended up coming into the ad tech space a little bit. Although that was a little bit more personalized, one-to-one marketing. And then eventually inside of that marketing space, we built this idea of a platform. We built the ability to really make the best next offer for a consumer based off of what we knew about that consumer so that we were giving them more and more relevant offers.

And that was pretty successful. One day I was sitting down, I had a conversation with the CTO of the company and said, "Hey, you were really successful in building a platform for marketing, why don't you come build a platform for financial services, for everything else that we did?" And so the decision management platform was really an effort to build a platform that would allow people to build analytics and decisioning into their own products in a self-service way. And it's the foundation of what FICO eventually built out in terms of their decision science capabilities.

David Joy:

Right. So one of the most interesting things is, I've obviously since I moved to America, I've been very conscious about my FICO Score. And that's what I knew of. I knew about the company. When you started at FICO, was it this established? Was it still a small shop? Because credit cards, I think, were still there, but the whole process was different from where it is today.

Joshua Prismon:

So when you think about what the credit score actually is, the credit score was an attempt to democratize access to credit. So what that enabled people to do is basically show that by paying their bills on time, being good with their money, et cetera, they deserved credit and not necessarily just because of who they knew, what color their skin was, where they lived, all of those factors. And frankly, it's been out there since the '70s. And so this is not new. It's probably the most important model that affects your lives, and not a lot of people always know about it. And from that point of view, it's really important.

David Joy:

It's very difficult for us to understand. Society really did not have these algorithms. And when you started saying a point around this is the most significant algorithm that I get used to more than my Netflix algorithm, it's pretty true. Because pretty much everything that I do on a day-to-day basis, I am using some sort of a FICO Score or Equifax has scored it. All of these scores determine how I live and base my life upon. So going into this, when you started your career working at FICO, did you know about all of this or was this an education that you got once you got into the company?

Joshua Prismon:

Oh no, it was an absolute education. And the reality of it is that all of us interface with these systems in our day-to-day lives, and we don't always necessarily understand them. And so learning about them has been really fundamental in terms of us becoming better citizens in a real way, understanding how these different systems interact with our lives. In many ways, it's the exact same discussion that we're having today about AI and ML. When you're starting to talk about the what does it mean for us to live in a world with these large language models that are giving us answers back to our questions and all of the ethical considerations that come with the ability to do stable diffusion and deep fakes. So that education journey, I feel like maybe I was one of the first people along those education journey, but I'm certainly not the last. I think in general, technology literacy and how these models work is becoming more and more important.

David Joy:

Right. So let's expand that a little bit. I would love to, before we go to Index Exchange, learn a little bit about how did you guys use AI and ML? Obviously initially at FICO, obviously you have a lot of data you're using that, probably running regressions or classification models or it's a gradient boost and a bunch of things that you did at the time. Could you expand on that a little bit, and without giving us a secret sauce of what you did, but tell us a little bit more?

Joshua Prismon:

Yeah. And the reality of it is it never was just one thing. I mean, you start with the standard scorecard model, that's obviously at the basis of the FICO Score, originally at least. But you're always adding more capabilities, you're always adding more insights into the model. In some cases, you're adding more data to the models, that create stronger and stronger signals. And so a lot of what FICO did was to bring tools that allowed for greater and greater use of data in order to drive insights that were actually meaningful. So when you think about the credit score, that started with a scorecard, but then you start thinking about fraud detection, and then you start getting into outlier models and then you start thinking about all the different techniques. And the reality of it is it's not just the strength of the technique, it's also, for example, some of the underlying characteristics of it.

So a good example here is we started taking a look at deeper neural networks and things like that. And the question then becomes, okay, how do you balance some neural network technologies with the ability to be explainable? How do you balance some of these technologies with the need to protect in certain circumstances against abuse? How do you deal with adversarial networks? Things like that as well. And so it isn't just that, oh, there was some new technique and that new technique opened a door. It was, there's a whole variety of different techniques that data scientists can use. Our job was really putting more of those tools into the hands of not only our own data scientists, but data scientists and business users across the world.

David Joy:

And what kind of technologies were you guys using? I mean, obviously FICO had so much data obviously, but 2007, 2008, once you got in, there was also the birth of the cloud and a bunch of other things were going on over there. So how did that enable... Obviously data growth was a part of it. We started becoming more digitally informed. People started making more transactions online. How did that affect the kind of systems you were building?

Joshua Prismon:

So the real challenge there really wasn't data in many ways because frankly, a lot of what we were doing was putting tools into our customer's hands and they had the data sets inside of there. So for example, the FICO Score. FICO is responsible for developing the score, but the actual score is run not by us, but by other credit bureaus. It wasn't run by us, but by credit bureaus and whatnot. But in a lot of cases, what we really wanted to do is, again, putting the power of analytics into everybody's hands.

We really were focused on things that you wouldn't immediately think about in terms of decision science. It was things like containerization. It was things like leveraging cloud earlier on. It was things like serverless functions later. We were one of the very first big adopters of OpenShift back before it went to Kubernetes. We were one of the first big adopters of Kubernetes. We were one of the first big adopters of EKS, all of these different technologies. Because what they allowed us to do was actually build this cloud platform for supporting everybody in terms of what they were trying to do with their own decisioning processes.

David Joy:

Right. And so as a chief architect working and you're going through change obviously, how did you go about understanding what solution makes sense for what kind of use cases for you?

Joshua Prismon:

So it all begins with exactly that. It begins with the use cases. It begins with, from a product perspective, what are we trying to do? Anyone who starts with the technology first might be missing something. If you're starting with technology from the point of view of, hey, what new thing does this fundamentally enable me to do that I've never done before? Then I think it's a really interesting effort. But if it starts with, okay, I've got this database, this database and this server platform, I'm going to go do X, Y and Z. That's typically cart before the horse. So what we really want to find out is what is the core use cases? In our case, the core use case that we wanted to enable is we wanted to take power and put it directly in the hands of business users.

And to do that, what we really did is we said, "Okay, is there a world in which, for example, we could build a rules engine that you could provision and write your own rules without having to have a human in the loop? Is there a world where somebody could upload a model and have that model execute against their data set that they own, not us and our data set, and make it so that they could drive insights out of it? Is there a world where we could sort of capture the outputs of various decisions in a way that it was immediately available via reporting without having to go through all of the steps that we're typically involved in in an analytics and data process?" So that's really what we focused on in terms of technology enablement.

David Joy:

17 years working at a company, obviously you've done a bunch of things. Before we jump into Index Exchange, I'm really curious, what was your favorite project to work at at FICO? Something that you're like, "This project really gave me an insane amount of experience and love for technology."

Joshua Prismon:

There were a lot of just incredibly cool projects, a lot of incredibly cool people. Interestingly enough, I'm going to go back a little bit before the decisioning platform days to answer this specific question. We did a project for Chase Bank and the US Navy where we put clustered computer systems on board Navy ships to do online banking. Because ships go out to sea for long periods of time, you actually still need to be able to do banking on ships at sea. And so what does it mean to take that kind of aspect of something that's built into our cultural fabric that we're so used to and actually make a standalone server that you could shove onto a ship and support all of the people at sea so that they could continue to have a financial system to support the functions of the ship and whatnot. [inaudible 00:13:07]. That was a really incredible project. I think it's still one of my favorite projects that I did in my career.

David Joy:

You still have a server, but it's not on the cloud, but it's still working and it serves pretty much all the transactions and does all these things that you have to do. Wow.

Joshua Prismon:

Yep. And this was a long time ago. I mean, this was early 2000s. So I haven't kept up to date to see what the latest capabilities are. But when an aircraft carrier goes to sea, there's 1,000 people that you have to support. And so you have a whole ecosystem. You have a whole set of financial transactions you need to support when they come into port. You have a whole bunch of different things that you need to do in terms of being able to buy something at a store more or less on board ship while you're out at sea. How do you support those different types of use cases? All of these systems, we take them for granted in our daily lives. We're used to being able to go to Amazon and order something. We're used to being able to stop by the ATM or stop by any place and just swipe our credit card. And that's relatively new. That's relatively modern. So what are the systems that actually fundamentally enable that behind the scenes? That's an interesting question.

David Joy:

Very cool. I mean, that's awesome. Well, thanks for sharing that. Let's just switch into something that I was really curious to know about. Having worked 17 years at a company and done some incredible work and work that is influential to people like me and even you, who's using all of this. What inspired you to transition from working at FICO and then taking this new role as a Chief Architect at Index Exchange?

Joshua Prismon:

So there's a set of fundamentals to architecture that I think are pretty universal no matter where you go to, but your ability to use them differs. So when thinking about something in the financial services world, you're living inside of one environment where you have corporations that are used to moving at a particular speed. You have development practices that have grown up with an incredible amount of maturity over a long period of time. You have a certain volume of data that you want to deal with. As I was working at FICO, one of the things that I really wanted to exercise as a muscle that I didn't get a chance to exercise is really the scale muscle. I wanted to be able to build really complex systems that were capable of executing at a much larger scale than some of the things that we already were doing.

And so I'm not talking about hundreds of transactions a second, I'm talking, what do you have to do to handle trillions of transactions? What do you have to do to get up to that next level of scale? So that was one piece. The second piece is I really wanted to focus on looking at engineering cultures that were really dedicated to excellence. That was something that I had at FICO that I really appreciated. And as I was looking for the next thing, I really wanted to find a place that was really focused around just having a real sense of craftsmanship in what they were doing. And combining those two things, just an incredible craftsmanship in what they're building and scale, gives you the opportunity to take a business and really ramp it up to the next level. And that was the exact combination that I was looking for and that's, I think, what I found very much at Index Exchange.

David Joy:

That's amazing. So for people who are less familiar with Index Exchange, how would you describe what Index Exchange does and how it distinguishes itself in this competitive landscape? Obviously, one of the things that I know about ads is I know about Google has their ad solutions. There are certain competitors in that space. Are those competitors like Google Ad Manager, your competitors as well? So how would you describe it for everyone else?

Joshua Prismon:

Index Exchange is a global advertising exchange or a marketplace. Index Exchange represents the sell side and we're connected to the buy side. And we work for basically publishers who might have web pages, applications, podcasts, videos, feed, and we make it possible for them to connect to people who are looking to buy specific advertisements and place those on it. We do this on demand. We do this connection when a page is being rendered or when a podcast is being played or when a video feed is going on. And we take care of everything from detecting and fighting ad fraud to making sure that ads might be appropriate to making sure that you can deal with the scale of it.

All of those behind the scenes challenges and many more, we do that as a service as we're connecting the front end to the back end. And this model is really critical to the open internet. It allows for publishers to monetize themselves without having to necessarily operate at the same scale as some of the biggest players. Whether that's the same scale in terms of being able to handle all that traffic or whether that's the same scale as having all of the commercial relationships. It basically opens up the marketplace and allows more people to get involved in that transaction.

David Joy:

Tell me, what is a challenge? Obviously it seems like if you have to run real-time auctions on this real-time experience that you're creating for your ad tech business for these companies, what are the different challenges that you feel that you're encountering and trying to solve?

Joshua Prismon:

First and foremost, volume. There's an incredible amount of just monetization that happens on the internet via these ads and it is just a profound amount of transactions coming in. And in those circumstances, you have to process those transactions at a very low amount of time. There's emerging technologies and platforms. We're seeing more of a transition towards video, for example. There's ad quality and user experience. Nobody wants to go to a page that's nothing but a whole bunch of advertisements. There's fragmentation and complexity. So not only is there the things that the industry's currently doing, there's all of the new capabilities coming in.

And oh, by the way, there's also things like privacy sandbox where we're talking about changing a fundamental underpinning of how this has worked in the past. Then there's sustainability pieces. There's an incredible amount of compute. Compute takes power. Power has an impact both in terms of monetary costs, but also things like global warming. All of these things are things that we have to take into account as we're architecting solutions inside of this space. And oh, by the way, you also need to do all of this in a way that is consistent with the environment that you're running in, which includes regulation, it includes just doing the right things by consumers as well. So those are the challenges that keep me up at night and factor into this particular problem space.

David Joy:

Tell me a little bit about the first one that you said, the idea of the transaction and the volume of data that you have to handle to build this experience. How did you go about architecting that? Obviously there were certain things already probably placed as a foundation before you came. And how is the infrastructure, and I would say the solution itself for you to handle this volume?

Joshua Prismon:

One of the things that really attracted me to Index Exchange was they have an incredible set of architects already there. And one of the things that they'd recently done was a full re-architecture of the platform. And when they were re-architecting the platform, they were taking many decades of experience and writing a new system to support all of the different pieces that we wanted to do in the future as a company itself. And so that re-architecture laid the foundation for all of the things that we're doing now. But how do we support and build on that? Well, from my perspective, it really starts with establishing of technical roadmaps for each of these individual areas. And so we have a technical roadmap for what we want to do on the exchange. We have a technical roadmap for what we want to do in performance. We have a technical roadmap for what we want to do in managing our operational databases.

Establishing those roadmaps as North Stars or where we're going to go next allows us to have the conversation earlier on about what do we need to do from an architecture point of view in order to support where we as a corporation and as an industry eventually want to go to? That makes it so that when we start to think about here down the line, when we're thinking about what's the next set of challenges, hopefully we've started to anticipate that or put in the general direction we're going in so that when we get into these use cases, we've got the foundation in place and we can build them aggressively. The second piece is really we want to build a sense of craftsmanship across the board. Because by doing that, what we're enabling is the ability to move faster in the future.

If we take care of building it right now, not skipping the things that aren't necessarily the things that you'll always think about first, thinking about how do we build quality in upfront? How do we build in operations upfront? How do we build in all of these cross-cutting concerns before we get into the individual systems? When we get to the point where we have to operate at scale, and scale can mean two different things here. It can mean the scale of the transaction volumes and the latency that you've got, but it can also mean scale in terms of the number of features that we're turning out and whatnot. Having those foundations in place make that faster and faster. And so that's another key thing that we're trying to do from an architecture perspective.

David Joy:

Wow, that's brilliant to know. You talked about the re-architecture, so I'm guessing you guys running on the cloud and did you have to make decisions? Because obviously you've run this solution globally, so you have to run it across multiple regions and you have to consider latency experiences for your users. Tell me a little bit about how that went about.

Joshua Prismon:

Yeah. So whenever it comes down to any, how to deploy something, you get really driven by what your business requirements are. So a lot of people bring up the Netflix example and say, "Oh, well, Netflix went onto the cloud and look at how good it is." Well, that's not exactly true. Netflix built a system that allowed them to go out and put data feeds as close to the consumer as humanly possible. That's not necessarily running in the cloud. Sometimes it may be, sometimes it may not be. But what they really focused on is how do we do whatever we need to do in a way that makes the most sense for the problem that they're currently looking at? I think we very much take a similar thing. We are running in some cases on our own metal. What we're really focused on is how do we meet our customer's needs the most effective way? And then how do we do it in the most efficient possible manner?

At the end of the day, we are an efficiency company. We are in the middle of these transactions connecting supply and demand. We have to do that, providing the most value at the least cost possible, because we have to take those savings and pass them on to our customers. And so it's really not about having a dogmatic point of view about where you're running, it's really much more about how can we best meet the needs for our customers? And in some cases, that's also cloud. It's like if I'm sitting down and I'm doing some sort of task that's better suited for the cloud, we have no problems going to the cloud for those types of problems. But it is not a one-size-fits-all solution.

David Joy:

You talked about database operations and you're talking about these scales and transactions and volume, and this can be sometimes people scrolling and things like that. A lot of data moving around. On the database side of things, what kind of databases do you use? You don't have to give us exacts, but what are your favorite databases to use?

Joshua Prismon:

It's a very loaded question. And there's so much religious wars around all of it. So do you want to standardize on a single set of databases? That makes a lot of sense from an operations point of view because supporting fragmented databases gets really expensive. Sometimes there's database technologies that can do something that other technologies simply can't do. So certainly the columnar versus row thing is a key technical differentiator. And over my career, I have been an early adopter of many databases trying to chase specific advantages. Again, it falls back into the, what does your use case ultimately require? Because if your use case ultimately requires you to do something that's not easily accessible, sometimes you have to look for different database options. More and more, I'm convinced that it's not really the database that matters as much as what is the architecture around the database and the database is just part of it.

So if you're dealing with a heavy microservices environment, then it really doesn't matter necessarily as much which databases you're using as long as you keep your data models segregated. Because it allows you to choose the best database for the technology without having some of the operational overheads or some of the complexity overheads or the accidental complexity overheads more specifically because of the fact that you've got the database scope to something narrow. On the other hand, if you're using maybe a more traditional data warehousing based approach, you've got to be really careful about your database because you're shoving everything into the same database and you're building in a single point of failure for your entire company. And so a lot of it really depends on what it is that you're trying to do at the end of the day.

David Joy:

Curiously, I've been thinking a lot about GDPR and this whole idea of data security, data privacy. And okay, let's say in the context of gen AI, a lot of people are saying, "Hey, I don't want my data to be trained for all of this. I don't want the model to learn how I'm getting used." Obviously, that's the thread from which this draw, but it also applies to what you guys do at Index Exchange because you have to... When you design your solution to consider data privacy and data regulation. So how has this impacted how you make decisions around architecture when you're building this product out Index Exchange?

Joshua Prismon:

One of the things that I like telling everyone is that architecture is not just about lines of code. Just like software development, software engineering is not just about lines of code. It's about everything else. When you architect, you don't just architect for how do I make system A talk to system B? You have to architect it for the environment in which you're operating in. And when I say environment in which you are operating in, that doesn't just mean the servers you're running in. It also means what's the regulatory environment that you're dealing with? What is the cultural environment that you're running in? What do you consider ethical? Are you making sure that you stay within those bounds of what it is that you're actually trying to do?

So GDPR is a good example. There's a couple of different ways that you can approach GDPR. One of which is you can just throw a slapdash process on top of it and say, "Okay, that's enough for what I'm actually trying to do." Or you can really think about what are we trying to do with GDPR? What are the core principles of GDPR? And then what are the core principles of things like secure by design, private by design, all of those things, and how do we really internalize that into the fundamental architecture that we're trying to do? And I firmly believe that as architects, you have to take that second point of view. You have to take the point of view of this is my operating environment, and architecting for that is just as important as architecting a decision about which database you use or what language you're using or what your web services ultimately are.

David Joy:

What are the pitfalls then? I know I have had experiences where we design for everything and then we start thinking, oh, we had to think about GDPR. So what are some of the pitfalls around not looking at the right things when you're designing that?

Joshua Prismon:

Specifically, what I would say is there's an idea of intentional design and an idea of emergent design. Those trade-offs more often than not have to do with what I would say a misbalance between intentionality and emergent is. Most of the time when you're making architecture decisions, you actually want to be making the architecture decision at the point in time in which you actually need it. And it should be made by the people who are actually implementing it or the business users that are actually closest to that decision. But the reality of it is sometimes you need long-term direction and you need to align that short-term decision into a long-term direction. And that's really where intentionality comes in. And so typically what I would say is when you see that problem it's because somebody said, "Okay, we need to support this, and therefore we're going to re-architect every single decision because of this one thing."

In reality, I think what you do is you say, we're going to make an architecture decision that we're going to support privacy by design, whatever. And then you basically set that long-term direction and then you allow the decisions as they're coming out to be made, but you make sure that those decisions are consistent with what your long-term vision is. And that way you're not necessarily wasting effort or designing castles in the sky is the other way I like to put it or ivory tower architecture is another way to put it. But on the other hand, you've laid enough of a foundation on there so that when you are building the towers and the buildings and everything else that you need that you have a structure that allows you to move forward with that.

David Joy:

I've wanted to go back to a thread that you were mentioning about the volume. Your systems have to be available all the time because real-time auctions are happening, you have to make decisions and your customers have to make decisions. So how do you design for scalability and resilience in your architecture? What kind of decisions go to manage the high volumes as well as the velocity of your programmable ad transactions?

Joshua Prismon:

I was one of the very first big believers, loud believers in containers and microservices. And the reason I was a big believer in those was because they gave us the ability to have independent failure domains and independent deployment domains. So for what we were trying to do, which was really focused around self-service, empowering the business user, all of those things, that made perfect sense because it gave us a way in which we could isolate resources, protect those resources, have a full life cycle for those resources, et cetera. So the microservices model made sense. Does that model necessarily make sense in every use case? No, it may not make sense to have something with 50 different microservices if you're out having to handle a real-time card swap or a real-time auction scenario, you want to look for different architecture patterns.

And so the way that you tackle these problems is really by understanding what it is that you're trying to accomplish and then letting the data, in this case, what the requirements are, drive your decision. I.e. which architectural patterns that you use. And then it starts to become a little bit more sane. You say, okay, if I need to hit this and I need to have these kind of failure characteristics, it becomes easier to say, okay, where's my load balancers? Am I using a microservices architecture? Am I doing X, Y or Z? Am I using Python for my backend? All of those type of decisions can get scaled out based off of your core principles, but you better know what your core principles and your core use cases are.

David Joy:

Every time I get someone on the podcast, I'm selfishly so excited to just learn how they look at problems. And it's so amazing, as to with your experience in the space, how easy it is for you to break down something so easily. So it's just natural for you now, and it's amazing. Yeah.

Joshua Prismon:

It is not always easy, but scar tissue helps with this particular area. I'll put it that way for each. That's another thing though. With every decision you get right, you're going to get X many decisions wrong. And so the other thing that I would say is with all of this is collect data, learn what's working, learn what's not working, and pivot quickly when you need to. Failing cheaply is an asset at the end of the day. And I've failed plenty, it's figuring out how to-

David Joy:

I mean, I would surprised to meet a chief architect who doesn't say, "Well, I built something and was part of something that did not fail at all." You won't have that. But I think what you made the point around executing with speed as well as failing cheaply is such an undervalued thought. Because you spend hours and days and weeks and months into something and then you realize, uh-oh, this is not the direction we want to go. So it's so critical. So I want to jump into that. How do you help make that decision at Index Exchange or in your real life? Do you have a principle? We'll look at this for two weeks or one month and then we'll scrape this or we'll go in this direction. How do you make that happen?

Joshua Prismon:

The principle of it is build your safety net. Build the things that are absolutely key to you being able to run your business. Do you have observability in place? Do you have quality in place? Build a checklist, come up with the things that are absolutely critical. But then put in place a lifecycle that allows people to experiment quickly. Start out by encouraging them to go do quick experiments of not only technical things, but maybe also business things. Hey, what happens if we provide this feature to a customer? Do they pick it up? Those type of things. Then have a solid plan on how to take your learnings from those discovery phase things and throw everything else away because you don't want that stuff and start to build your software. This is also part of the scaling thing.

David Joy:

Right.

Joshua Prismon:

Take the learnings, you've hired as much risk as you possibly can, build out your first set of services. Don't try and solve every single problem at the very first moment. Don't try and build a Taj Mahal up front. But figure out what the shack in the corner you need to build is and start building that piece. Be intentional about the decisions that you're making. Do a review process, however you want to go after it. We use Architecture Decision Records, ADR processes, things like that. But do it in a very iterative fashion.

And then as you start to get to the point where you've got critical mass, start thinking about what do I need to do to mature this? What do I need to do to make it so that it is a system that I'm not worried about in production? What do I need to do to make it so that it will scale further and further as I get the base pieces in line? And I think that that core business philosophy, try something, see if you've got market fit, pivot if you don't. That entire mentality is not just a business concept, it can very much be an architecture concept as well and should be an architecture concept in what you're working on.

David Joy:

So you spoke about some of the things around mentoring and what your guidance is for architects and engineers. What are some other things that you can share right now that foster leadership and innovation for people who are listening?

Joshua Prismon:

I think a big thing is finding the champions, the people who are really going to drive excellence at your company, at your nonprofit, in your community, and really doing everything you can to empower those people. One personal thing that I have is just trying to make sure that we are getting as much diversity, both in terms of people of different ethnicities, but also diversity of thought, as possible into those decision-making processes as possible. Because that type of engagement really encourages an environment where people can challenge ideas, where people can come in and say, "Hey, I saw you want to do it this way, but if you also did it this, this and this, you could achieve something much greater."

Software engineering is the ultimate example of one plus one equals 10. The parts that you put into it aren't lines of code. The parts that you put into software engineering are processes and decisions and people and passion. And whatever you can do to encourage that, the better off the product that you're going to get at the end ultimately is. And you can always go and work on your quality. You can always go and work on building a more inclusive environment. You can always go and build all of these better systems. But it's really pulling all those things together in structured decision-making and then having a passionate set of, again, I'll fall back on that term I keep using, craftsman, to go execute it. That's really what is going to drive your success over the long run.

David Joy:

100%. Yeah. And so as a chief architect at Index Exchange, technology doesn't stop. You are working on something every damn day, every damn hour there's a new thing coming out. I've been following some of the really cool open source products that you're supporting, like the OpenC3 project and things like that. What I'm curious about is that how do you keep up with tech trends and how do you continue to learn about what's happening? What's your formula?

Joshua Prismon:

So OpenC3 is a great example of a project that I love. So OpenC3 is this amazing open source project that's out there for literally doing management of satellites.

David Joy:

Yeah, I saw that.

Joshua Prismon:

What I absolutely love is I love seeing people who are passionate about their projects. I love seeing people who get passionate about a specific bit of technology that they're interested in. Because when I see somebody who's passionate about something, there's a reason that they're passionate for it. And I don't always know the reason for it, but simply following their passion and what they're engaged on will so often tell me about something that I knew nothing about and open my eyes to some new technology that's coming or some new technology trend that's coming or some new application of technology and culture and the government that I wasn't aware of. And so looking for people who are passionate and then seeing what they're passionate and trying to get a sense for why they're passionate about it, more often than not, leads me into technology that I wasn't aware of.

So that's one thing. I think another thing is Steve Jobs used to talk about the intersection of technology and humanities. Interestingly enough, I find that that's a really good way to keep track of the technologies that are really going to matter in the future. So a lot of what we're seeing now with large language models and whatnot are actually driven by some very fundamental questions about how we think, what it means for the internet to be searchable, what it means to have this distributed web and things like that. So looking for new areas where you see that intersection of humanities with technology has always been important. And then the other thing is, whenever I see a technology trend, trying to figure out what the vectors and time are, i.e., if I can do this now and this tomorrow and I've got good visibility on it, what does it ultimately look like?

I think that that is another key piece or key enabler, if you will, for staying ahead of the technology curve. But I'll be honest, it never stops. There's always something new. Every time I've thought, okay, this space is getting into a mature space. And to some degree, we work in a very mature space. We use Linux. Linux is a derivative from Unix, Unix has been around more than 50 years. The microprocessor's been around for a very long time. They are all iterative improvements on each other. What's really changing is new ways to apply those fundamental technology blocks to new problems. So every now and then I'm like, okay, do I really have enough to get into this next curve of technology? But it always comes back to that same pattern.

David Joy:

I agree.

Joshua Prismon:

New technology applied to longstanding human problems.

David Joy:

One of the most fascinating thoughts that I've had recently is that if you take a large language model and use a quantized model and put it into your pen drive and put it on your laptop and go start living on an island today, you will still have the history of humanity, without the internet, on that large language model, which is fascinating. It's like a time capsule.

Joshua Prismon:

It is. But then what do you do when it starts telling you that Benjamin Franklin was a fan of absolute despots and things like that too? So you have to start dealing with the fact that technology can lie to you.

David Joy:

Exactly.

Joshua Prismon:

What does that ultimately mean? What is the ultimate outcome of those type of curves as well? And the reality of it is I firmly believe technology is neither good nor bad, but what we do with it certainly can give it a moral character. What does it ultimately mean that we've got technology and these trends and what does that mean for the next five years? And that, it's a challenging set of questions.

David Joy:

I agree. I think the innovation curve that I have seen in the last decade, it's showing me exponential growth. So I'm really fascinated like you. And I loved your perspective around bringing the idea of humanity around what we are building and looking at it from that prism because it shows you so many different views. All right, so I know we are close to the end, I wanted to ask this last question to you. What is the one lesson that you have learned in your career that you would like someone else to know today so he doesn't make the same mistake?

Joshua Prismon:

Don't be afraid of failure. The reality of it is, you're not going to get every question right. You're not going to get every answer right. Learn from it, take the next steps, be aggressive, be passionate. But also when you've made a bad decision, realize you've made a bad decision and go fix it. Take ownership. Be a craftsman of whatever it is that you want to build. That will get you an awful long way.

David Joy:

Well, Josh, it's been such a pleasure having you on the podcast. It's been such, I would say, a fascinating conversation looking into the mind of a chief architect. I'm pretty sure I'm going to suggest that as the title for this podcast.

Joshua Prismon:

Oh, dear.

David Joy:

No, they'll probably come up with something better. But the question I wanted to ask you is where can people find you? Is it LinkedIn? Do you have a Twitter? Where do you post stuff? Where can people follow Josh's activity?

Joshua Prismon:

Yeah. So I'm on Twitter. I'm Josh Prismon on Twitter. I'm also on LinkedIn. I am talking more and more about Privacy Sandbox and some of those technologies at industry events.

David Joy:

We'll follow you. Everybody listening in, go and check-out Josh on Twitter, as well as his projects that he is working on. Fascinating thing that they're working as a company on, as Index Exchange, some really brilliant things. And really curious about, do you also have an engineering blog or something for Index Exchange that people can read?

Joshua Prismon:

Yeah, so there's a couple of great resources. There's an engineering blog for Index Exchange. There's also for people trying to understand the ad tech ecosystem a little bit better, we do a series of videos called Index Explains. That's absolutely phenomenal. You'll see members of my architecture team have been doing some of those as well. Yeah.

David Joy:

That's where you go and learn. All right. So once again, thank you Josh for hopping on. It's been an absolute pleasure. And thank you everyone for listening in. I'll catch you in the next one.