The oft given advice in product circles is that the best performing teams emerge from a healthy tension – great outcomes are forged under pressure. The idea is that in order to maximize the results from my engineering colleagues, I should ask for something slightly unreasonable, which through conflict we'll walk back to an optimal outcome.

This is the right advice, but it's often focused in the wrong direction. Product teams are encouraged to push for more velocity from their engineering teams. If I complete more stories, then more code is written, then I get to where I'm going faster. The reason this doesn't work is it puts the focus on the wrong variable -> output instead of outcomes. Metrics can be gamed. I can push up delivery metrics 20-50% just by having the team resize all of our stories up a notch. Is that really an effective outcome?

Instead, the right way to create a healthy tension is to push the team on what is being created, not how they're doing it. Provide the team with forward-looking context to help shape the code being written. Agree on a set of north-star metrics to help make development decisions. Review designs with the team to determine whether non-functional requirements are being considered, or whether we're making the proper tradeoff decisions. Your challenge shouldn't be if they're writing code fast enough, but whether the code they're writing is going to give the desired outcome.

The north star for my current product is speed to market. Our primary role is to feed Kafka events to our business domain services. How quickly I can get an event produced is what I care the most about. Simply pushing my team to deliver more points doesn't get me the outcome I want – more often than not it gets me the opposite outcome. The tension I want to create is whether we're putting the right tooling in place to produce events. In six months, I want to be able to deliver 20 events in the same amount of time it takes me to deliver one today.

As product professionals, we preach outcomes over outputs constantly to stakeholders. That shouldn't fly out the window when we're working with our engineering colleagues. Creating a healthy tension is a good thing, but it needs to be focused on what actually matters.

If you liked this article, leave a comment and let me know! You can also follow me on Twitter or connect with me on LinkedIn.

This post is inspired by this amazing article by Jack Vanlightly. I've taken a lot of his ideas and shaped them around some of the enterprise workflows I've been a part of recently, and tweaked them in a way that I think works for a couple of real-world use cases.

Anyone who's worked with me over the last year or so knows I'm generally not a fan of the microservices pattern. Don't get me wrong, sometimes it's a necessary pattern, still doesn't mean I have to like it 🤗. However, I think I've stumbled across something that might make them tolerable.

While most of the tech news you see is around AI and who's the latest tech giant to spend a couple billion to train a marginally better LLM, there's been a quiet revolution in the data space that is undoubtedly more impactful to how people actually build software. Especially systems at an enterprise scale. This "new" development is in the form of Open Table Formats (OTF).

OTF's aren't new, but are emerging as a more popular standard in recent years for data stores as the need for managing larger datasets begins to exceed traditional database paradigms. I want to spend a little time exploring how these new formats can be used to make a microservices architecture tolerable.

Databases & Microservices

First, let's very quickly define microservices for the people in the back (not you, of course). Microservice architectures are an approach for working on large scale systems that breaks different areas of functionality into independent services that can be developed and deployed without affecting other services. Proponents will also tout some (IMHO made up) benefits of improved reliability – in practice I think this is rarely the case.

Each service is effectively its own independent software application, complete with its own data store (read: data silo). These services typically perform a specific business function. You don't have to be really creative to guess what these might look like. A payment processing service, a communications service, a user management service, etc. The payments service holds the data it needs to process payments, communications holds the data it needs to send emails/texts/whatever, etc.

The databases you would use to make all of this work are the usual suspects: Postgres, SQL Server, Oracle, MongoDB, DynamoDB, etc. What all of these have in common is that they can only access data within their respective stores. In other words, the compute is coupled to the data storage. While the payments service only contains data it needs to process payments, it helps to know the user who made the payment. To do this, it needs user information. If we want to send an email on a successful payment, then the communications service needs both customer information and payment information. In order to do this, data must be duplicated and synchronized across services.

Think about this like writing in a secret cipher that only you can read. If someone else needs that information to be able to use it later, then you have to read it to them first so they can write it down in their own secret cipher.

Sometimes, that's a helpful pattern. In order to get the data for this blog post, you needed to ask the database engine powering this blog to go fetch it for you – you couldn't just go read the database directly. However, in a microservices architecture, we want all of the internal services to be able to manage and read the data like it's all one system. This is a technical barrier that we usually overcome by utilizing some sort of messaging service. This might be API requests, web hooks, or more often than not, messaging queues. Whenever an action is taken, that message is published to a queue and consumed by all the services who are subscribed to the event.

So now I have three copies of my user data and multiple copies of payment information. What if the user service or payment service needs to know if an email was sent? In practice, a lot of data ends up being duplicated over and over again. And keeping all of this data in sync is a fool's errand. You need to periodically resync all of your data stores just in case something fails and events aren't pick up. This is the tradeoff against having to maintain and deploy changes against a monolithic application.

What would make this better, is if each service could just read the data it needs from everyone's data stores when its needed – too bad traditional databases just don't allow for that. What if I could just have a single copy of the data and read from it wherever I need to?

Open Table Formats

Enter the Open Table Format (OTF). The major benefit that we care about for our use case is that an OTF allows us to separate the physical data that we want to read from the compute needed to read it. This separation of concerns is called virtualization. This virtualization allows different resources to be shared more efficiently.

The OTF does two key things:

1. It separates data from its metadata, and
2. separates storage from compute.

Table metadata is information about the table itself – where the data is, how it's organized by table and column names, column indexes, and the like. It's the table of contents for a database engine. By separating this away from the raw data beneath it, I'm able to send this metadata to distributed systems without creating multiple copies of the data itself.

This creates a number of benefits:

• Single source of truth. One common challenge in copying data is synchronization. Errors happen all the time – drives get corrupted, connections are interrupted, edge cases cause data to not copy as expected, etc. Ask anyone who's worked with Kafka events how flawless it can be. A single source of data means it's easier to prevent replication errors from happening and I'm able to operate from the same source of truth.
• Utilizing Object Storage. Believe it or not, the physical data in your database is just a file (often multiple files, but a file nonetheless). If we separate this from the compute and metadata, I can just stick the files in cheap object storage and not have to worry about complex storage management.
• Federated access. Data catalogs are pure metadata. They can easily be distributed across a federated system to grant access. The owner of the data can easily present the data to another system without copying data over.
• Standardization. Having a common format means that data can be collaborated on by multiple parties. Since the physical data is in a common format, multiple engines can process on the same data for different purposes.

Thinking about these virtualization benefits yields some powerful implications. Being able to surface the same table in different platforms as if they were both native to the same platform is insane. With this capability, there's no need to move data between platforms, you just need to expose the tables needed to feed other platforms. Data access to peer services is truly real time.

Data Governance & Access

Okay, so two systems having access to the same table sounds cool in concept, but what are the practical implications? I can already see someone raising their hand to tell me two systems shouldn't be able to access the same table. The chaos! It's anarchy!

Remember, these are just tools. How you use them is the key.

Tables come in two flavors. The first is a native table. This is exactly how you think about tables now. It's both the table metadata as well as the physical data itself. The second flavor is an external table. This is just the table metadata. It gives us the information needed to read the table without a copy of the data itself.

We expose this data to multiple systems by granting access to native and external tables. One system will have access to the native table, while one or more other systems can have access to the external table.

Data Sharing

As a service or application, data sharing is two-way. You can share out, meaning you own the native table and expose table metadata to other applications. You can also share in, where you add external tables from other applications. In other words, the native table owner publishes metadata changes that the external table owner must subscribe to.

Once you have the metadata, then it becomes a matter of permissions for your typical CRUD operations. At this moment in time, I haven't been able to come up with a use case where I would allow an external table owner being able to do anything to the physical data except read it. Allowing external platforms to write to your table creates a host of support, data quality, and data reliability issues.

The use cases I've experienced so far revolve around a common pattern. There is a System of Record owner that publishes data changes that other systems need to react to. Right now, that's done via a batch file import or some event queue. In our composable data pattern, the SoR would write to a native table that other systems can read using an external table.

Data that needs to be written back to the SoR should be handled in one of two ways. The first is to utilize typical messaging interfaces like API calls or message queues to let the SoR know it needs to write the data back to a native table. The second is that if we think the outside service should be writing that data, then we should evaluate whether that data truly belongs to the SoR.

Do you see where this is going? Take an example where our customer platform from earlier needs to send a text message to a user, for which they use a communications microservice. If the text message is unable to reach the customer, then the bounce back data needs to be written and recorded back to the user. In our composable model, since the customer application isn't the creator of the bounce back data, the communications service can own the native table with the bounce back data, giving the SoR direct access via an external table.

Operational Data and Analytics

So far, we've really only looked at this from a SoR/transactional lens. What about as we get into data-specific uses like Operational and Analytical platforms?

Operational Data

A common data sharing primitive in the operational space is one of data streaming – directing messages to different microservices to take different actions, as well as consuming response messages from the microservices. This pattern can be conceptualized for our composable data platform in a producer/consumer pattern like so:

This approach differs slightly from the traditional approach to event-based microservices architectures in that the microservice isn't necessarily producing events, instead centralizing that responsibility to the operational data platform. This approach allows services within a given domain to simply read/write to database tables without needing to implement messaging protocols. Any events that need to be broadcast back to the enterprise is delegated to an operational platform.

Analytical Data

I won't pretend to be an expert in the analytics space, I haven't spent nearly as much time in that area as operational data. However, given I know just enough to be confident in my ignorance, I'll let you tell me where this falls short.

The role of the analytical data function is in aggregations of long-term business datasets, pre-calculating expensive queries into something that can be easily consumable by end users. Usually this begins in the form of copying large quantities of raw data away from SoR systems into a place where we can clean and process data.

Like before, one of the most expensive parts of this operation is copying large amounts of data to a separate store before we start to clean and conform the data into something useful. This results in a mountain of data that is really nothing more than a 1:1 copy of the original data. We haven't added any value yet and cost a ton in additional storage costs. Virtual tables allow the analytical space to incrementally read the raw data directly where it sits and store refined/conformed data in native tables.

Reverse ETL

There's a fuzzy line between analytical and operational data. In theory we like to consider these things like separate ideas, but in practice they often overlap. Like a report created from SoR data that contains a new derived dataset, that's consumed by the original SoR to perform new workflows.

What's the common theme we find ourselves with once again? The physical copying of data. Two copies of the same data that are needed by different applications in the same system. More replication, more points of failure.

Data Fabric

What we want to start shifting towards is a data "fabric", where we begin to think about tables in a logical ownership model rather than a physical one. With a data fabric as the model for our composable data platform, a native table can be exposed to any other system that requires access, so that the same set of data can be read and used by any system that needs it.

In our old model, our data access is restricted by physical and technological barriers. All operations have to be performed by the same application. In our new model, the physical location of the table is no longer important (save for latency issues with edge compute, but that's a different discussion). In theory, you could have the physical data for dozens of services all in the same object storage layer, with ownership distributed in a logical model.

To prevent this from becoming too chaotic and maintaining good data governance, we still want to interface with other domain areas of the enterprise through some sort of central data platform. An example for a financial services company might be separating domains around loan origination and servicing. The origination domain largely focuses on marketing, sales, and underwriting functions. Servicing shifts into daily operations. Each one of those business domains likely operates independently from the other, with a customer handoff between functions. In this case, I wouldn't want to mix domain data. I'd still consider an enterprise data interface to shift relevant data attributes between domain spaces. Once inside the domain, we can move back into our composable data structures. Your mileage may vary here, it will be up to you to determine how wide you want your data fabric to stretch.

A New Ownership Model

With this way of looking at ownership and governance, our new focus is on how to present the data. It becomes less and less about how data should move from A to B, scheduling batch updates, what events should be published, etc. We no longer have to concern ourselves with different platforms with different capabilities and needs. There's no more siloed application data within a business domain – instead we define data ownership using a logical model. Our applications start behaving like a hive instead of as separate entities, and we can focus more on the logical constructs of our applications instead of how we're going to communicate between them.

Those of you that are starting to grasp the vision should see why this is such an appealing idea. I don't see any real barriers to being able to run complex systems this way. The most difficult thing to map out is who is the owner of a specific native table (i.e. who is the producer and sole authorized modifier of the data) and ensuring the external table is exposed to the proper users.

Fitting Into Your Data Strategy

To be clear, this isn't a simple way to manage data for singular platforms. For startups and those with monolithic applications, my take is still to "just use Postgres" and be done with it. However, if you're in a large organization and need to federate data access across dozens of services, then a composable data platform approach using OTF's can radically simplify your tech stack and the way you operate.

To me, this type of data strategy fits into the "just use Postgres" mantra, but designed for the enterprise. We want to skip out on setting up and using messaging queues for most services and just query data. We want to allow our operational and analytical data platforms to read the data they need without having to invest in massive ETL compute and storage costs to create 1:1 copies of the same data. Services should read the data where it sits and move on with what they need to do.

If you liked this article, leave a comment and let me know! You can also follow me on Twitter or connect with me on LinkedIn.

We've all been there. Stuck in the doldrums of going through the motions and just not in it anymore. Where you used to have fun building cool things, now you're just stuck in a rut and just don't care anymore. That spark you had that got you into learning how to code, design, connect with people, and hone your craft is gone – the flame has finally sputtered out.

How do you get it back?

Work Sucks Sometimes

First, recognize that work just sucks sometimes. "By the sweat of your face you shall eat bread" is as true in 2024 as it was when those words were first written down. That job you got writing code, building products, doing real estate deals – whatever it is – you probably got it because at some point you thought you might enjoy doing that kind of work for decades of your life. But like with most things, there comes a point when it's not fun and you're stuck doing dull activities. Who doesn't love documenting bugs, sifting through legal docs, or fulfilling SDLC requirements?

You gotta pay bills, so sometimes you gotta do the stuff that sucks. And that's okay.

Bring back the Spark

Why did you get into this in the first place? Was it the stimulation of learning new things? Seeing things in a way no one else saw them?

I love building things. I've mostly worked product roles, but over the last few years I've gotten the itch to not only design a solution to a user problem, but to build it too. That's helped me get the spark back in a big way. Bored at work? Just build something useful. It could be a tool that helps me with my day job. It could be a side project that you hope may see the light of day one day. Sometimes, the thing that helps me the most is to build something no one but me may ever see. Something that let's me try a new language, a new library, or a new set of tools. Something that I don't have to answer to anyone if it doesn't work out, that I can just leave in a big pile of buggy mess once I scratch the itch.

Who knows? Maybe you'll stumble across something that makes your day job less – well, sucky.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

An interactive version of this article can be found here: https://ratehike.caleblewallen.com/

Here's a question for you – as of late June 2024, how many rate cuts, if any, do you expect the FOMC to make by the end of this year? Outside of the talking heads on CNBC and the Fed dots in the quarterly SEP, do you have any data points to back up your point of view?

Thankfully, financial markets give us a view into the consensus view from billions of dollars of bets being made at any given time. We can use Fed Funds Futures contracts to calculate our own probability of a policy change.

Fed Funds Futures Contracts

Before we get into how to calculate the probability of a policy move, first we need to understand how Fed Funds and their corresponding futures contracts function.

Fed Funds Futures (FFF) are quoted as a price, not a rate. The rate is derived from the price by subtracting 100 from the price. For example, if the contract you're viewing is priced at 94.88, then the implied rate in that contract is:

\[100−94.88=5.12\]

Contract Data

Contracts for Fed Funds Futures are quote monthly, and have an expiry on the last day of every single month. When you get quoted a series of these contracts, they'll look something like this:

I know what you're thinking, "But isn't fed funds an overnight rate? How is the contract monthly?" I'm glad you asked.

Contract Pricing

Fed Funds futures are quoted as the average fed funds settlement over a given month. So if FF is 5.125% for the first half of the month, and 5.375% for the last half, then the contract will settle at 5.25%.

FOMC Meetings

How does this help us calculate the odds of a policy move? The FOMC has an iron grip over the front end of the yield curve. They decide what the overnight rate is going to be and uses a trading desk in downtown Manhattan to keep settlement prices within a given range. With this in mind, knowing that only a Fed action can influence those contract rates up or down by more than a bp or two, we can start piecing together the expected path of hike.

Step 1: Collect Futures Data

Below is a table of futures data. You can get this data from the CME Group. This data is publicly available on a delayed basis. That's totally fine, we're not trading on this information, we're just trying to get a pulse on how likely the market thinks a rate hike is.

CME Group - Fed Funds Futures Data

Step 2: Get FOMC Meeting Dates

Policy Decisions are typically going to happen on predetermined meeting dates (outside of black swan events that require immediate action), so we'll need to cross-reference our futures data with our FOMC meeting dates to figure out when we can expect a policy change to occur.

For the remainder of 2024, these are the meetings remaining. The 2025 meetings won't get announced until closer to the end of the year.

You can get this data from the FOMC's website. Note that decisions are announced on the second day of the meeting, therefore you only need to collect the second date of each meeting.

Step 3: Build Projected Rate Movements

This step involves taking our futures pricing and calculating the implied rates and rate movements that occur in a given month. Our goal is to calculate Fed Funds at the start of the month vs the end, and then seeing the difference between the two. We're going to make a few assumptions when we work with this data:

• The Beginning Rate for a month is simply the Ending Rate for the prior month. The exception to this is when there are no Fed Meetings.
• Rate movements only occur in months with Fed Meetings. Since we know the rate at the beginning of the month and the implied rate per the futures data, we can calculate the end rate with:

\[r_{ending} = ((r_{implied} / days_{total}) - (r_{begin} * days_{priortochange})) / days_{afterchange}\]

• We can only calculate probabilities as far out as we have planned FOMC Meetings. This means that as we approach the latter half of the year, we can only project out a couple of meetings until the FOMC publishes next year's meeting schedule.

Step 4: Probability Tree

Calculating the probability tree occurs in two stages. The first is in the 'Front Meeting', which is just the very next meeting after today. This done by dividing the expected rate change by the expected policy move. Historically, this is typically 25 bps, although in recent memory it has been by as much as 75bps at a time.

\[Policy Change Probability = Expected Rate Change / Expected Policy Move\]

As an example, if the front meeting has an expected rate change of 12.5 bps, and we expect that the FOMC's policy change is 25 bps change, then we would say there's a 50% likelihood of a hike.

As we move further down the probability tree, things get a little little more complex, but not all that much more. In concept, what we're trying to figure out is the probability that we land on one of the nodes in the chart below. For example, in the n2 nodes below (representing 2 meetings ahead of today), what's the likelihood that we will have experienced 2 hikes (n2(++))? What about no hike and then a hike (n2(+))?

The way we accomplish this is by first calculating the isolated probabilities of each meeting. In other words, what's the likelihood of a rate movement for a given meeting, based solely on the expected rate movement?

Next, we'll use those isolated probabilities to figure out if the anticipated policy change is a hike or a cut, based on whether the isolated probabilities are positive or negative.

The formula we'll use to calculate the probability of one of our nodes is: \[(p_{hikeNow}*p_{noHikePreviousMonth}) + ([1 - p_{hikeNow}] * p_{hikePreviousMonth})\] where 'p' is probability. If futures data indicates a cut, then you would simply reverse the direction of the formula.

For example, here's how we would lay out calculating the probability of a cut as of late June 2024.

Policy Decision Prediction

This is probably the most straightforward of the concepts. Now that we have our probability tree built, we can start with deducing the project policy decisions.

We'll begin by marking the FF range we're currently in. We'll add up all of the probabilities above and below that range, excluding the value from the current range. Once the summed probabilities exceeds a pre-defined threshold (in my case, 50%), then we'll mark a policy decision and move our mark up or down into a new FF range. From that, we'll repeat the process. You can tweak this process according to your risk thresholds by adjusting the move threshold up or down.

In our example above, the July meeting shows 90% probability of no policy change. However, in September there's a 58% chance that rates will be 25bps lower and a 6% chance that rates will be 50bps lower, for a overall probability of 64% that there will be a policy move down by the September meeting.

That's it?

That's it! With some statistics and a little patience, we can calculate our own probabilities. While the Fed is projecting only one rate cut by the end of this year, our calculations show that the market is betting on two cuts.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

I know it's been a while since I've actually published anything. There's been a lot going on in my personal life, which meant that consistent writing has just fallen by the wayside a bit.

Over the summer of 2023, I decided to leave my role at LoanBoss, a company I helped to build since it's initial ideation in 2017. It was bittersweet for me – LoanBoss had started its life as a spreadsheet on my laptop, and it was hard to walk away from. I worked with a lot of amazing people at LoanBoss, and it will always be a special place to me. For anyone reading this that's currently a user of LoanBoss, the platform is in great hands and they have some amazing plans in store for the future.

With my summer off, I got to spend a lot of time with my wife and kids, and spent my time tinkering and building something new. I wanted to build an API service to deliver hard-to-find holiday information to subscribers. However, I pretty quickly discovered that the API service itself was by far the easiest part of building and launching this product.

Building Something New

I love building things. It was my favorite part of working at LoanBoss. I loved the challenge of finding a problem and then having to work my way towards creating a solution for it. This new API service I was trying to build in my time off, was really a continuation of solving a particularly difficult problem I had face sourcing holiday information for financial markets. I had a great time figuring out how to source this data, calculate the holiday information, and serve it up in such a way that it was easily digestible by an end user. Then the real problems began.

First, I want to sell access to this API. It costs money to run a service like this, and I certainly didn't want to foot the bill on my own. So I needed a way to get customers onboarded and paying for this service. No problem, I thought, I'll just make a user portal.

Turns out it's easier said than done. First, I need a way for users to create an account. They also need a way to recover their password if it's forgotten, so that means integrating an email service. Once that's done and they're logged in, I need a way to collect payment information so they can subscribe to my service. No one wants to punch in their credit card information just anywhere, so I need a reputable processor, like Stripe, in order to create some legitimacy (side note: I don't know if you've ever integrated with a payments vendor, but it ain't easy).

After that, I need a way to secure my API services so I know only subscribed user are accessing them. That means issuing, encrypting, and securely storing API keys. Then I need to provide documentation so users can figure out how to get the data they want. What about when they want to cancel their subscription and delete their account? What if they lose their API key and need to generate a new one?

AGH!

via GIPHY

A Solution

After asking around online and with some developer friends, it seems like I'm not the only one facing this problem. I had lunch with an old friend of mine, who happens to be a software engineer by trade. I pitched him the idea of creating a service that handled all the boring, awful parts of offering an API-as-a-Service – builders should focus on building, not reinventing the wheel every time they make a new API service. He loved the idea too, and we have decided to make the idea a reality.

Introducing: RestEasy

RestEasy is the front-end and middleware for you API service. The idea is simple:

• Deploy your API Service to your favorite cloud provider and set up your marketing site.
• Use RestEasy to set up your custom, white-labelled user portal and admin portal on your own custom URL (or ours, if you prefer).
• We will handle all of your user onboarding & management, payments & billing, API key management, logging, and auto-generating documentation.
• You will need to define your route -- simply add your endpoint and query parameters, along with any basic validation you want us to check for you. The user will make their API request through your RestEasy instance, and we will handle the auth, basic query validation, and logging.

When I was building my API product, I found that building the API itself was only 20% of the actual work that needed to be done. The other 80% is everything I've described above. In fact, I still haven't finished it (the user-servicing piece, the API itself has been done for a while), and my new plan is to run this product on RestEasy when we launch.

Beta Program

If you'd like to join our beta program, we'd love to have you! We haven't opened up the platform yet, but you can join our waitlist here: https://www.resteasyapi.com#waitlist/.

We'll be selecting a few waitlisted members to join our beta platform, and in exchange for helping us get our product ready for prime-time, you will receive lifetime discounted access for the products you launch during the beta period.

I'm excited for this next chapter, thank you for coming along!

I think the growing consensus among the tech world right now is that AI is going to eventually take over most white collar jobs. I've written before about how AI is going to take over (half) your job, but I'm starting to think I was wrong, at least when it comes to software developers. To be clear, I don't think I'm wrong about it taking over half your job, but I think I was wrong about the impact it's going to have on developers.

Since ChatGPT came out, and we've gotten a taste of what a well-trained, commercial LLM product can do, I've kind of viewed this as a net-neutral impact on the developer community. After all, I haven't heard from a single company yet that they're short of things to go on their roadmap – they're just going to accelerate their plans.

Sure, we've seen massive tech layoffs, but those were all economic layoffs from Big Tech, not productivity problems. Those were problems of focus at the top, not a problem with output from the bottom. The layoffs from Big Tech have created massive hiring opportunities for startups, and led to a surge in new startups. This is the impact of economic forces, not AI, but it's indicative of what's to come.

The AI Revolution

Ok, punch line first. The AI revolution is going to increase the number of developers, not decrease them.

When we evaluate this hypothesis, I want to be clear that this is in reference to the total number of people employed as developers, or have a hand in development work, NOT that individual companies will hire more developers. In fact, I would argue that the number of developers per company will stay the same or drop, but due to economic reasons, not technical ones.

This is going to come about because of several reasons:

1. Decreased Barriers to Entry
2. The Rise of Low-Code and No-Code
3. Product Niches

Decreased Barriers to Entry

The prevailing argument towards AI decreasing the number of developer roles is that AI will prove itself an example of Disruptive Innovation, sometimes referred to as destructive innovation. This scary naming comes from the fact that certain jobs are destroyed whenever a new type of technology is developed.

For example, the tractor destroyed farming as a way of life for millions. It transformed our way of life positively, moving us from an agrarian society into an industrial one, with better incomes and a better quality of life. However, it temporarily displaced a lot of workers who suddenly found themselves not needed to tend to crops.

There's countless other examples, but I want to stick to the tractor for this evaluation. The tractor has made farming so efficient that you can't make a living farming without one. However, the tractor presents a massive barrier to entry. Planting most crops involves the use of a class of equipment called row tractors. These are the machines that can plant, well, rows of different crops.

The upfront cost of one of these machines is in excess of $100K, even for used machines. When financed, the cost of the machine has to be amortized over 5 years. This represents a huge barrier to entry for anyone who wants to try and farm at scale.

AI Lowers That Barrier

These GPT models are creating (at least initially) a much lower barrier to entry to create new software products. PHP/MySQL apps are going to always make money, and AI is going to make it easier than ever for non-developers to make these products!

Here's a simple example. I'm not developer by trade. I've worked a lot with data over my career, so I'm familiar with SQL, and can sometimes scrape enough Python together to do a quick task, but I'm not someone who could make any form of functional software. At least until this afternoon...

Today I decided to create a simple HTML app, ChartGPT. It's a pretty simple app – it takes input from a user to create an org chart. Here's the thing, I didn't write a single line of code.

I asked ChatGPT (GPT4) the following question:

Create for me a javascript script that will create an org chart. The user should be able to enter in the name, title, and person they report to into a form to add a node. Each node should have a connector that connects the nodes together. Generate the HTML, CSS, and Javascript code in separate scripts.

It then created for me some code that I was able to test using CodePen. It took some tweaking (again, not from me – ChatGPT made all the code changes when I requested them). Eventually, it created a workable demo that I was able to use. This isn't perfect, but it's getting better. Tools like AutoGPT make it possible to connect different models together and follow multi-step process independently. Work is being done on these code generation models to allow models to recursively test and update their own code so that the desired outcome is produced.

Here's a demo of the code ChatGPT produced to give you an idea of what's possible, just a few months into the AI revolution. I didn't write a single character of this code (not that I could if I wanted to), it's just a copy/paste of the code the GPT4 model produced. I had to ask it to fix a couple of things, and if I spent a little more time on it I'm sure I could fix a few other issues with it. But it's still pretty impressive that in 5 min, someone like me could take a generic LLM and produce functioning code.

Given a few months (or weeks, given the pace of AI innovation these days), more specialized tools are going to come out that put the power of good code generation into the hands of idiots like me who can just tell it step by step what I want and what tweaks to make and create a functioning app.

This doesn't just lower the barrier to entry, it almost eliminates any technical barriers to entry.

There's countless examples of this sort of practice occurring. One recent example that comes to mind is the easy access to financial markets, made possible by free trading from user-friendly apps like Robinhood and Webull. Only a few years prior, if you wanted to get involved in financial markets you would need to use a cumbersome brokerage platform that would take a long time to learn, and THEN pay $8 for the privilege of entering or exiting a position. Lockdown and stimulus in 2020 definitely contributed to the mayhem, but the easy access to markets was the catalyst that made it all possible.

The AI revolution will be no different. It's all building up to become the perfect storm. Big tech laying off thousands of skilled developers, who are either being scooped up by startups, or making companies of their own. Rising interest rates seem to be pushing us towards a recession, which will put others in the non-tech world out of work. Do you think unemployment and free access to ChatGPT or Bard is going to create more people trying to create software products, or less?

The Rise of Low-Code and No-Code

I know, it takes more than just a chat bot pushing out code snippets to build a product. Have no fear, there's plenty of low code and no code products out there to bridge the gap between where you are and where you need to be.

It's no longer necessary to have any ability to code to create useful SaaS apps (although some conceptual knowledge is really useful). These platforms, like Bubble, WeWeb, WebFlow, Xano, and Backendless remove almost all of the technical barriers, like user authentication, security, and infrastructure maintenance from the hands of the app creators and allows them to focus on making cool products.

Economies of Scale

Once you have the code written, most SaaS apps are expensive to run. All of the EC2 compute time, database and S3 storage, serverless infrastructure, etc. cost a lot of money to run. If you've ever built a SaaS app you also know that most of the time those resources sit around underutilized. You're still paying for that dedicated EC2 instance, even when it's not running. This makes an expensive barrier to entry even if you already know how to code.

Most no-code platforms are built on shared resources, meaning you're sharing a pool of compute and storage resources with a bunch of other applications. This is completely and totally fine for 99% of applications. From a cost efficiency perspective, this is even preferred.

This makes the cost of building these tools on low or no code platforms dirt cheap. All of these services do offer dedicated resource packages, but you only need to migrate to these more expensive tiers once you have the user load to demand it (and the revenue to pay for it). You can get an app up and running for FREE in most cases, only paying when you think you have something ready to be published and to show to the world.

We've very quickly knocked down both the technical barriers and economic barriers to creating new products. I can build a fairly sophisticated application in my pajamas, orders of magnitude faster than would have been possible just a couple of years ago. That's insane.

Product Niches

This is one of my absolute favorite charts ever.

It's called the product adoption curve. It's been around forever and is used to describe the types of customers you're going to encounter as you reach market saturation.

Moving a product up the curve is pretty formulaic in strategy, albeit not in execution. The strategic approach to unseating an incumbent is to find a customer niche that your competitor can't serve very well (the customer niche is too small to matter for your competitor, their product is too generic to pivot towards that customer, etc). This niche is your foothold to storm the proverbial beach and take market share.

The AI revolution and the rise of no/low code tools is going to create waves of niche products. Wish your trading app was focused on only trading tech stocks? You can make a niche product for that. Wish your fitness app was focused on making you a better powerlifter? Strongman? Bodybuilder? Long distance runner? Sprinter? You can make a niche product for that.

The economic forces and incentives towards getting lots of niche products out the door that serve smaller groups of users are here. I can't help but wonder if the loud pundits crying out for regulating AI to prevent "the loss of jobs" are doing so out of compassion or self-interest?

More Devs, Not Less

All signs seem to point towards more people being employed to create software products, not less. I don't mean that there will be more people learning how to use an IDE to code the old fashioned way – those folks will still be needed, but gap between what you have to code the old fashioned way and what you can do with a new generation of tools is closing fast, being chipped away almost daily.

Who knows, maybe one day your full time job, or side hustle, might just be building and maintaining a specialized piece of software.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

By now, even my grandmother has heard of ChatGPT. It's become more than just a gimmicky chatbot – people have made it a permanent fixture of their workflows. I use it in my own day to day, to help write this blog post, craft SQL statements or generate Python scripts, write user stories, get a jumpstart on research, and countless other things.

Of course, ChatGPT is just the tip of the iceberg. The GPT API allows external platforms to prompt for more specific use cases. I've seen it used in an ETL platform to describe a transformation in natural language and watch it translate that into a programmatic set of instructions for the tool. All of these tools, especially in the hands of skilled users, makes our work faster and more efficient.

This has led a lot of people, tech workers especially, to panic that their jobs are basically dead. It's only a matter of time before this replaces them and leaves them jobless. I'll be honest, if your contribution to the team is setting the corner-radius or changing font sizes, you're probably right (but you were probably at risk anyways). But there's a host of reasons NOT to panic, and a lot of barriers that I don't think AI will ever be able to knock down.

Just like the tractor gave us superhuman abilities to grow food, and power tools gave us superhuman abilities to build, so will AI give us superhuman abilities to create.

The real AI revolution won't be replacing humans, it will be creating superhumans.

Practical Factors

If you work for any sort of tech company, you know that the most argued and fought over individual thing in the company is the roadmap. For anyone not in tech, the roadmap is just a document that explains what features are going to be built, and in what order.

Having done this for about 5 years now, and having met dozens of people who have done this waaaay longer than me, I can promise you that there's not a single company who is struggling with finding work to put on the roadmap. Every single department of the org wants something built and they absolutely must have it now.

Acceleration, not layoffs

Because of the roadmap issue above, software companies have to fight a budget/capacity battle constantly. Engineers can only push out so much good code in a fixed time frame, and it's never enough to satisfy the demand for it. Any organization who is able to figure out how to utilize AI effectively to write good code is going to use that to increase their development capacity, not to reduce their engineering spend.

Some corporations can be ruthless in managing costs, but if you know your competitor has just used AI to double their engineering capacity, are you really going to use it to reduce headcount to maintain the same capacity?

Distribution Factors

All new technology needs a distribution mechanism in order to compete effectively. It's easy for us to make sense of this for physical goods – if you make a new widget, you need some sort of supply chain infrastructure to make and sell the goods. A network of suppliers, maybe a few warehouse locations for efficient last-mile distribution, and some actual shipping contractors. How else are you going to get your product to market?

It's harder to think about the sort of distribution hurdles AI has to overcome – it's all on the internet, right? Just plug in and go!

Not so fast. There's a lot between the AI tools existing and being able to use them effectively. Are your systems capable of interacting with AI? Do you have the expertise on hand to create the handshake? Are the principals at your firms willing to take the plunge and take a risk on it?

This distribution can be represented in one of my favorite charts ever, the Product Adoption Curve.

It's not my invention, you can Google it for more information. It's a tool used by product managers to help understand the types of people that will be using their product. As of the time of this writing, we're still in the "Innovators" stage of adoption, which are people like me who like to use new technology just because it's new and shiny. However, what I really want to point to are the "late majority" and "laggards" group. These two groups represent about half of all people that will ever use a product or technology and are characterized by their resistance to change. The people on those groups are also decision makers at companies that will have the opportunity to use new technologies, but won't use them to their fullest. They'll always be skeptical of change.

No matter how useful a new technology is, you can't ignore the human factors towards the distribution, or adoption of a technology. Just like how my grandparents didn't own a computer until the late 2010's, it will take a while for this tech to move it's way through our lives.

Human Factors

Speaking of human factors, we're probably the biggest obstacle to widespread use of these technologies. Humans and computers speak and think differently. LLM's are meant to be a translation layer that helps us to interact with a computer and get it to do what we want to do. But there's still a pretty big gap.

We're not very descriptive

LLM's require the person making the request to be verbose, which means we need to fight every instinct we've every learned about communicating and overcommunicate what we want from the AI. We're not good at that. We tend to communicate with other people with an assumption of a shared experience.

I'm sure you've had that experience before, "Have you ever seen XYZ movie?" as you prepare to tell a hilarious joke, only to have the joke killed because the other person hasn't seen the movie. Because of that lack of shared experience, the other person won't get the joke.

Close your eyes for a minute. I want you to create in image in your mind of "a train moving down a track". What did you see? Was it a cartoon or a realistic image? Was it from inside or outside the train? Was it day or night? What was the weather? What geographical region? What color was the train? Was it steam, diesel, or electric? Freight, passenger, or subway? Here's a couple of random examples from Google when searching for trains moving down a track.

Your personal experiences shape that expectation, and unfortunately, for anyone seeking a specific output, the level of effort that goes into crafting the appropriate prompt is going to be frustrating. We're not very good at being verbose. While this can be learned, the average person isn't going to take the time to do it.

Value Creation

AI can be pretty good at generating things, but where it falls short is being able to decide WHAT to put out. That still requires a human. It's the discernment and decision making capabilities of a human that create the real value. So while AI might remove some of the mundane, well defined, repetitive tasks of making a vision a reality, it can't create the vision.

It still needs YOU.

Human Distrust

Most of us are a little skeptical of anything that feels "unnatural" to us. No matter how cool it is to see a self driving car, most of us are nervous to get in one. Something feels just a little off about it, a driver we can't see or have a real conversation with. In 2022, self-driving cars surpassed the human safety record for accident rate per million miles driven, meaning it's now safer to let your Model 3 drive you to work instead of doing it yourself. However, the vast majority of Americans still wouldn't ride in a self driving car.

Do you really think AI is going to be any different? Are you going to trust AI to just do your work for you, or are you going to check behind it constantly? Will you allow employees to delegate critical tasks to AI anytime soon? Doubtful.

Human Resilience

We're a hardy bunch. We don't let things keep us down. When the tractor made agrarian societies obsolete, we moved into cities and started manufacturing things. When the industrial revolution made it cheaper and easier to make more stuff with less people, we moved on to services, and then to the information age.

Do we really think that "this time it's different"? Or will we find new ways to make a living that we can't even conceive of today?

Technological Factors

Just like the distribution and human factors that are going to keep AI from making us all jobless, there's plenty of limitations of the technology itself that are going to keep it's capabilities finite. I don't even mean today's versions of AI, I mean AI in general. Here's hoping I'm not being too contrarian...

Innovation S-Curves

New innovations follow an S-Curve. There's a slow initial adoption while people figure out how to use it, before the space explodes and everyone starts to panic about how fast things are changing, before the performance ceiling is reached on the new innovation.

AI is going to be no different. While there's no way to know where that ceiling is, there is one and we're going to hit it at some point. There's only so much time and hardware to train models, and only so much publicly available data to train the models on.

AI Is Derivative

One of the key limiting factors of AI is they're not really creative. They're absolutely creative relative to an individual contributor, since the scope of what they can reference is much broader than what the human mind can retrieve at once.

However, they can only work within the confines of their training data. It's integral to how an AI is made --> Give a model some training data, and let it start making predictions against that data and seeing how close it got. Once you leave that bubble, it's taking wild guesses with no way to validate whether its guess is correct.

This means that while it can fill in gaps in human creativity (what would Old Town Road sound like if it was performed by Johnny Cash?), it can't really escape the the bounds of it's training data – it's always a derivative of something else.

This means that in order to expand the bubble of new, novel ideas, you need humans!

A Map Is Not The Territory

As humans, we often confuse the representation of something for the real thing. A map of NYC is not NYC. It's a shadow of the thing it's trying to represent, and requires interpretation in order to understand it. AI will always struggle with this problem. AI cannot experience reality the way you and I do, it only has the representation to go off of. This is one of the reasons why image generators are so bad at drawing hands, it doesn't actually know what a hand is, just what a picture of a hand looks like.

At it's core, AI is just a probability model (if you listen closely, you can hear a herd of angry AI engineers, "it's more than that!!!!"). So when you ask it to generate a picture of shaking hands, the above does fit the bill. It's statistically close to a picture of two shaking hands, but it's oddly off putting to us because it's not close at all to reality. Because we've seen hands and held or shook one before, we know what that interaction should look and feel like – it's trivial for we humans to see that something is off about that. But AI will never quite be able to solve it.

Of course, we can make attempts to make the problem better. Just give the model a 3D model of a human and let it compare a 3D rendering of the action to the output image and airbrush the image a little bit. That's a valid approach to solving that problem, but even that 3D model is just a map of the territory. Even if we got it to get good enough for what we need, it's still just one problem solved with a lot of human effort. Hardly the massive human displacement we're so concerned about.

Thinking about every nuanced problem millions of people are employed to solve every day, and you start to see why I'm skeptical that people are replaced in their jobs.

Superhuman

Before I finish, I want to stress that I don't think AI is useless, or that it's low quality garbage. It's not. This is one of the most exciting times to be in technology in the last 30 years or so.

If history teaches us anything, it's that technological innovation tends to just make us more productive as a species. Knowledge workers are long overdue for a productivity boost. For readers that have been in your industry for a long time, how has your productivity changed in the last 20 or 30 years? If you're in CRE, how many more deals are you able to execute on now than a couple decades ago? If you're in tech, are you able to ship features any faster? I have no doubt marginal gains have been made, but beyond improvements in your own skills and experience, has your ability to get knowledge work done improved exponentially? Probably not.

That's the real AI revolution. It's not replacing humans, it's making superhumans.

Will some people lose their jobs? I'm sure they will, that tends to be the way of destructive innovation. But the people who learn to embrace the revolution instead of fighting it will succeed. They will be the people to reap the benefits this new superpower is going to give them.

We're going to be okay. Humans always find ways to adapt. This time will be no different.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

I want you to imagine a scenario with me for a moment. You've been an intelligent real estate investor for a while, and have an excess of cash that you want to diversify into some alternative investment other than real estate. So, you call up your stock broker and you decide to ask about buying some shares of Apple ($AAPL).

However, you're a savvy investor. You've never made an investment without doing your due diligence.

You: "Hey Jill, can you run some comps for me? I want to see how Apple's cashflow statement compares to Microsoft. Can you tell me how their Net Income compares?"

Jill: "Sorry Caleb," (in this imaginary conversation you're also named Caleb), "it's gonna be a few hours before I can run that analysis. You see, Apple calls that section of their cashflow statement 'Cash from Operating Activities', while Microsoft calls it 'Cash from Operations'. In fact, every section of their financials is the same story, it's going to take me some time to unravel and match it all up."

Doesn't that sound familiar? How many CRE operators now struggle with this exact same sort of comparable exercise because their property managers all use different accounting trees?

CRE has a problem that it's struggled with for years. That problem is data standardization.

Why No Standardization?

The problem is two-fold. First, by it's very nature CRE is just non-standardized. Every property is different. Every business plan is different. Every capital stack is different. We've developed a language that we can all use to understand each other, but that language was meant for humans, not the digital world. Second, there's no central authority in CRE to dictate or oversee the process of devising a standard that all CRE data has to conform to.

This exists in other industries – the SEC dictates how company financials have to be reported and audited so that investors can easily understand the financial health of companies. The CFTC manages financial derivatives, so that all interest rate swap and cap data is uniform and can be reported into a swap data repository. There's no equivalent within CRE.

This means that data is often siloed and maintained in different formats by different industry stakeholders. Operator to operator, broker to broker, and even lender to lender, this data is held in different structures and can't be easily shared (not that many stakeholders are trying to do so).

Despite the industry being so large, it's extremely fragmented, with no single player able to hold much influence over how this data is structured.

Industry Initiatives

As the industry becomes more tech enabled, having a standard for data becomes important. It's next to impossible to utilize a SaaS product if there's no standard format. It's even more difficult to take advantage of publicly available data if there's no way to compare your data to other data sets.

There are several players working on this problem. LoanBoss is pioneering the standardization of loan data (full disclosure, I'm on that team), while companies like Reonomy and RCA have been working on problem of structuring property data for years. These standardized data sets and APIs help streamline the problem of data aggregation.

Driving Standardization

The growing use of technology and data analytics in our industry is helping to drive data standardization. As we move away from an Excel-only way of doing business, and into one where we save Excel for the complex stuff, there's more pressure on companies to standardize their data in a less fragmented way. Using other technology tools to help streamline operations and help in decisions making processes has made the need for standard data structures more apparent.

Standardized data can help ensure that technology solutions are able to effectively communicate with each other and that data analytics are based on consistent and accurate data.

Overall, while data standardization in commercial real estate is still an evolving area, there are promising signs of progress. As the industry continues to embrace technology and data analytics, the need for standardized data is going to become increasingly important, and efforts to develop common standards will likely continue to gain momentum.

I expect as artificial intelligence tools become more accessible and easier to use, we'll see an acceleration in standardization. AI will make it much easier to transform existing data into something that can be more easily utilized.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

Last week, during the fallout of SVB, Signature Bank, and Silvergate, the FOMC decided during it's March 22 meeting to hike Fed Funds by 25 bps. This decision came pretty much in line with futures markets expectations, and signaled one more hike in May before pausing, also mostly in line with futures markets.

Despite this seemingly expected behavior, markets reeled following the announcement, with the 10T falling 20bps between the decision and market close, and continuing a downward trend into Friday.

This is not the sort of response you expect for simply behaving the way markets expect you to behave. Why is this?

Before I get into why I think markets responded the way they did, let me just point out that I'm no macroeconomic expert, the FOMC more than likely consists of a panel of people much smarter than I. This is just a few observations I've seen pointed out by other commentators that make me wonder if the policy decision the Fed took was the smartest one.

Let's Rewind

Let's look back to why we're in this situation. We all know the storyline so I'll be brief:

• 2019 - Life as normal
• New virus, what's this?
• Boom, COVID. We all go on lockdown, "For 2 weeks, we promise"
• It's longer than that. WFH becomes a thing.
• We have a short deflationary period as we adjust to a new way of life.
• Stimulus checks to keep things moving. Most of us don't need it, so we buy $GME instead.
• More stimulus checks
• Another one
• Another one -- wait, aren't we past this now?
• Inflation has been picking up. It's transitory though, we promise. It's because of the ships parked off the CA coast.
  • Nothing to do with pumping stimmy checks to people who don't need them to buy a shrinking supply of stuff.
• We keep watching grocery bills go up for a year, but the Fed doesn't do anything because, "Inflation is Transitory".
• Fast forward after a year of hearing the word "transitory" more times in 12 months than I've ever heard it in the rest of my life combined, and the Fed admits it was wrong.
• We're behind the 8-ball though, so we've gotta hike, we've gotta hike fast, and we've gotta do it now.
• Mar 2022 - Mar 2023, Fed Funds moves from 0.25% to 5.00% upper bound.
• Mar 2021 - Mar 2023, the 10T moves from ~1.60% to ~3.40%

Inflation, Inflation, Inflation

So we're in the place we're in because the Fed has decided it's #1 priority is to keep inflation in check. That's the biggest problem facing the long term economic health of the United States.

Makes sense if that's your priority. If that's the big issue, I can take you at your word, let's fight inflation! Hike baby, hike!

Bank Failures

I won't go into grueling detail about how and why banks are failing, but if you do want to read more, because maybe you're the last person to read anything about it, you can check out a detailed description here.

FDIC Takeover: An SVB Primer

In case you need a refresher, here's a quick recap of the banking sector stress.

Falling Deposits

Bank deposits are the lifeblood of banks. When you go put your money in a bank, it allows the bank to deploy those assets into something that can make money. For basically all of banking history, deposits have only GROWN. Even back in 2007 - 2008, bank deposits grew at banks, they never decreased.

However, if you squint your eyes and glance towards the right side of this graph, you'll see a big spike in bank deposits where deposit growth accelerated off-trend (you'll see my very scientific trend line in red).

Let's forget for a moment about why deposits spiked, we can argue about that for days. I just want to point out that there seems to be some artificial acceleration away from the historical trend, and if that's the case, then this pull back down may have been unavoidable. In fact, if we argue mean-reversion, we may not even be close to the end of deposit deflation.

In fact, if we zoom into this chart, we can see that deposits at banks peaked about 9 months ago.

Our Challenge: Making Depositors Whole

Ok, so if we're a bank, deposits across our entire industry are falling. That means to fix our problem we either need to a) keep deposits from falling, or b) liquidate some assets for cash.

Given that falling deposits are a problem across the entire banking sector and not just our bank, we're unlikely to fix that problem. The only banks who have a hope of at least maintaining their deposits are the Big 4 banks (JPM, BofA, WFC, and Citi), who may benefit from a flight from smaller institutions that are seen as more risky.

With that in mind, let's take stock of our situation.

Consumer Loans

As bank, I issue consumer debt. Things like Credit Cards and HELOC loans. Those balance have risen and continue to rise. I make those loans with depositor money, which is leaving in droves.

Those probably aren't going to go back down of their own accord. If we check the unused balances of those revolver lines we see the amount of credit offered continue to rise alongside the amount of credit used. Yikes.

The Prime rate, which nearly all consumer revolving debt is based around, steps up in lockstep with Fed Funds. As we all know, that's skyrocketed over the last year.

What this adds up to is MORE debt that costs MORE to maintain, which means less cash to pay down balances (since more is going to interest), so this credit increase is unlikely to subside on its own. Higher interest also means higher minimum payments, which takes more money out of my bank account (deposits).

Ok, so unless we start calling in credit limits and cancelling HELOCs, this isn't a great place to start. I'm already losing deposits right and left, I can't risk giving my depositors yet another reason to leave, so this is probably a non-starter.

Consumer Mortgages

In theory, this should be a good place to turn. We just stop originating or buying new mortgages, and just let refi's roll off our books.

Trouble is, this seems to be everyone else's playbook too. The most recent data we have on this is Q3 2022, but even then originations were trending down. I bet when Q1 2023 data comes out we'll see a massive slump downward.

But of course, in this rate environment, who is going to refi of their own accord? Currently, mortgage rates are floating between 6% and 7%.

Meanwhile, only ~9% of mortgages (as of Q3 2022) were north of 6%. I doubt any rational person is refinancing their loans.

The only people paying off their mortgages are those who are selling their homes. Of course, home sales are falling as mortgage rates rise, so the loans you need to roll off are rolling off at a slower rate than in recent history.

Valuing Mortgages

If you remember bond math from college, you'll recall that the price you pay for a bond is correlated to the bond's coupon and the yield you're looking to gain.

• If the bond's coupon = the bond yield, you buy the bond at par (i.e. face value)
• If the coupon > yields, you buy the bond at a premium (i.e. more than face value)
• If the coupon < yields, you buy the bond at a discount (i.e. less than face value)

If you're a bank with these loans in a balance sheet, you've got quite the dilemma. You can't get borrowers to refinance their loans with somebody else, and you can't assign your position either, because you'll take a pretty hefty loss. If your balance sheet is something similar to the national average, that means you can't assign your position to 90% of you mortgage portfolio without taking a loss.

Commercial Real Estate Debt

This is a big issue for small banks. According to the Fed, nearly 70% of CRE loans are held by banks outside of the 25 largest. As of Feb, that's 70% of $2.898 TRILLION, which is still north of $2T.

If you're a bank looking to assign a loan position, you're more than likely going to use a calculation called Cash Equivalency -- the amount of cash paid or received to assign a position. It's pretty similar to bond math, and the premium/discount relationships are the same.

Historically, roughly 50% of CRE debt is fixed, and roughly 50% is floating. This means that at least half of your portfolio is going to be deeply affected by the long-term treasury moves. If you're a really small bank, your ratio probably leans fixed. Let's take a look at where you would have been underwriting loans the last few years.

So we've underwritten our loan portfolio in the following:

• 2020 vintage: sub 1% Treasury Rates
• 2021 vintage: dancing around 1.50% treasury rates
• 2022 vintage: we start the year at ~2% and end ~4%

Do you know any CRE operators who didn't refinance every single loan they possibly could in their debt portfolios in 2020 - early 2022?Ignoring spreads for a moment, every single loan we've underwritten in the last several years just keeps getting devalued. I think it's safe to say that at least 50% of outstanding CRE loans were underwritten since Jan 2020, meaning small banks are left holding the bag on loans they can't liquidate to appease depositors that are drawing down funds en masse.

A Perfect Storm

If you've been listening to debt brokers, you know banks are in risk management mode -- this means no new loans, which means less credit is being spent (worsening the cash spend/drawing down deposit problem), and a potential credit crisis is looming.

If banks can't lend new money because deposits are dropping, and the 2023 debt maturity wall that everyone is talking about is looming, then how are CRE borrowers going to refinance their properties? If borrowers can't refinance their properties, how are banks (small banks in particular) going to roll that debt off their balance sheet to get liquidity?

Only time will tell, but this problem of shrinking deposits doesn't seem like it's going to resolve itself anytime soon.

Conflicting Priorities

Now the Fed has two big issues to contend with.

• A suffering banking sector that desperately needs some interest rate relief to get some liquidity. This priority would call for an DECREASE in rates.
• An economy reeling from 2 years of historically high inflation. The only tool the Fed has to control inflation is interest rate policy. This priority would call for an INCREASE in rates.

Here's a good visual of the problem at hand.

The Fed Meeting - March 22, 2023

In the most recent Fed meeting, the Fed made what might have been the worst decision of all. They had two moves that would have signaled to the market that they know the problem they have to face down. The could hike rates 50 - 75 bps and signal to the market that they believe banks are as sound as the Fed is claiming they are, or they could have cut and signal that they recognize the weakness of the financial sector and are taking action.

Instead, they took the middle of the road path. They hiked 25 bps.

The Signal

The signal to the financial sector with this policy decision is that the Fed was once again caught sleeping at the wheel. The banks that the Fed are supposed to be regulating could get themselves in a long position where their asset portfolios are worth less than their liabilities. This policy move just signaled what we all already knew, which is the Fed really isn't sure how strong the banking sector is.

Of course, they can't come out and say that, that would cause panic and a self-fulfilling prophecy. But this latest rate decision just confirmed that the Fed isn't sure how long they can sustain this tightening cycle. Their best bet is just to try and get more dry powder they can cut later this year.

BTFP

If you needed some data showing that the banking sector isn't in as great of shape as the Fed wants you to believe, you only need to look at the Bank Term Funding Program. This is a brand new program, in response to the SVB collapse, that provides emergency lending to banks against certain collateral (like Treasurys), valuing those assets at par. It's going to be a critical program to keep smaller banks that didn't hedge there long exposure.

This is how the program works. If you bought a 10T at 1.90% 2 years ago and need liquidity when yields are ~3.40%, the market value on those bonds is 89.7 while par is at 100.0. Typically, repo markets would be used to secure this sort of liquidity. However, the amount of collateral needed to secure that position is greater than the cash you need (due to market value of securities). This leaves banks in a bind when enough bank deposits get withdrawn. The willingness of the Fed to potentially hold these securities to maturity and lend against their par value, for an extended amount of time, is what makes this stand out.

You can take a look at the Fed's balance sheet to see how much this is getting utilized. The Fed's balance sheet is up $400B in just 2 weeks!

One more thing about this program -- these loans are just meant to provide emergency liquidity to banks for one year. Do you think that a bond valued at 89.7 is going to recoup enough value that those banks can pay back the $400B in March of 2024? Not unless rates come back down...

Conclusion

So, in summary, the Fed has two big conflicting priorities right now. One says it should keep hiking, and the other says it should start cutting. The Fed took the middle of the road path, neither committing to continued hikes (to bring down inflation), nor to providing rate relief to banks. Instead they hike 25 bps, maybe committing to another 25bps hike, and giving some emergency lending to banks that they cannot even hope to pay back in a year.

I think what the Fed has done is told us that we're getting ready to cut again by the end of the year. This last hike, and the expected hike in May, is just to build in some more dry powder to slash away. The Fed knows the banks will need emergency liquidity beyond a year at current rate levels, so their plan is to buy themselves enough time to let current rate levels do their work on inflation and let the banking sector issue become next year's problem.

Here's to hoping that they're smarter than me and not picking a priority was the right move...

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

In tech, we LOVE planning. We plan meetings to describe functions, which are the frameworks we use to plan user stories, which is a different framework we use to plan developer tasks and the acceptance criteria for testing user stories. We plan the crap out of stuff.

We need planning! It's really important to plan out what we're going to build, how we're going to build it, how it's going to serve the customer, and how we're going to know it works correctly. However, at some point along the way, we need to engage is something called Strategy. Strategy is great, it really help us to answer the why we're going to do something, and how all these plans we put into place are going to succeed.

However, at some point along the way, some MBA suits decided that planning and strategy as separate activities were too many steps and that we should smush both of those things together into a brand new activity, called Strategic Planning.

There's only one problem though. Strategy and planning aren't the same thing. Putting those two things together and giving it a catchy name doesn't help. It has nothing whatsoever to do with strategy.

Strategic Planning

When we talk about strategic planning, what we usually mean is describing a set of activities that we want to accomplish in order to achieve some out come.

• We're going to improve user experience
• We're going to market to a new type of user
• We're going to open west coast office

We make these plans because they all sound good and we can easily understand them. But they're not really going to get us where we want to go, because they're not a strategy.

What's a Strategy

The strategy definition that I like the best is defined as (I didn't come up with this, by the way, I'm not nearly clever enough):

An integrated set of choices that positions you on a playing field of your choice in a way that you win.

Strategy is a Theory

It's really nothing more than a theory. It's a set of educated assumptions about why this is the playing field we should be on, and not some other one, and how we're going to be better at playing the game than anyone else on the field.

The strategic theory must be coherent, and it must be doable. You have to be able to translate that strategy into actions for it to be a great strategy. Planning doesn't have to have any such coherence.

A plan is just the new set of features the sales team thinks they can sell, or what customer success wants to fulfil a client request, or what sort of new development environment engineering wants because it'll make some process faster, etc. It's an internal list of things that doesn't necessarily have any cohesiveness. What it's missing is some unifying mechanism that is going to help the company as a whole reach some goal.

Why Do Leaders Plan So Much?

We plan because planning is comfortable. It has a known value. Plans usually have to do with the resources you're going to spend. It's all on the costs side of the business. It's comfortable because I can control the cost side and I become the customer.

Strategy involves making a plan about some goal we wish to achieve, which involves customers wanting our product or services enough to pay for them. The tricky part is we don't control customers. We can't make them buy our product or service.

That puts us out there, it makes us uncomfortable. We're saying that we have some belief about an outcome. We can't prove it in advance and we can't guarantee it.

It's much easier to say, "I'll build this thing, I'll implement this policy, I'll hire these people", than it is to say, "I will have customers liking our product more than those of competitors".

The trouble with planning is that at least one competitor is out there trying to figure out how to win.

How to Avoid the Planning Trap

Accepting Angst

Recognize that strategy will have some angst associated with it. Just accept it. You can't prove that your strategy will work in advance, while you can prove the cost of your plans. It's difficult to go to your boss and say, "If our theory is right, and customers respond well to this, then we'll succeed". Accept the fact that you can't be sure about the outcome, and that's okay. That's what leadership is about.

Not knowing for sure isn't bad management, it's great leadership.

Lay Out The Logic

Lay out the logic of your strategy. What would have to be true about the playing field you're on in order for this strategy to work? What would have to be true about our customers, about our business model, our pricing model, the market environment, etc. in order for this to work?

With this in place you can watch your strategy unfold. Oftentimes our assumptions are not right, and we have to tweak the strategy. That's okay though! Strategy is a journey. We want to keep refining it to make it better and better as we go along.

K.I.S.S.

Don't make it overcomplicated. You strategy should be concise enough to fit on a sheet of paper, and simple enough to explain to one of your kids. I figure if my kids can get it, I'm not overcomplicating it!

It should lay out the basics: Here's where we're choosing to play, here's how we're going to win, here's the capabilities we need to have in place, and here's the management systems we need to succeed.

Having a strategy certainly won't guarantee that you'll win, but resorting to planning is a surefire way to guarantee you'll lose.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

By now we've all heard about the implosion of Silicon Valley Bank. If you haven't, then this is a really odd place to be hearing about it for the first time.

This bank failure represents the second-largest in US history, but the way it failed is largely unprecedented (to my knowledge). This post is intended to be a primer on the long road to its insolvency, and whether this is an indicator of things to come.

How Banking Works

Before we can get to how and why SVB failed, it's important to understand how the business of banking functions. Banks have a really interesting business model, unlike any other business in the world. Most businesses make money by selling you something. A product, a service, etc. It might be something you produced directly, or it might be as a market-maker.

For example, Samsung designs and manufactures TV's. They make money by selling TV's for more money than it cost to produce. The economies of scale they operate at doesn't allow them to sell directly to consumers though, so they sell their product to wholesalers, which eventually makes its way down to a retailer. You, the consumer, can then buy your TV from Walmart, who also sells the TV for more than they bought it for.

While banks do have divisions that sell financial products, the way the business as a whole is stitched together is pretty unique.

Depositors

If you decide to open your own bank, the first thing you're going to have to do is raise money from depositors. This can be individuals, or from other businesses. Depositors will place funds in accounts at your bank, and in exchange you agree to give them access to those funds anywhere in the globally connected financial world.

In return for offering that service, you don't charge a monthly fee, in fact you will often PAY depositors to keep their money in that account.

So, with that kind of a business model, how do you make money?

Collecting Assets

Banks make money in a variety of ways, but one of the primary engines of that income is by issuing debt, either on the primary market is the issuance of loans, or on the secondary market purchasing debt.

The idea here is that you will make more money on the products you lend than the interest you have to pay to depositors to keep money at your bank.

Pretty straightforward right? Except...

Fractional Reserve Banking

Ok, so this is where things get weird, and where things can get fragile. Banks lend out more money than they have cash on their balance sheet. How does this work?

Meet Joe. Joe is local businessman who owns a shop on main street. He decides to open a new account at your bank. He's been doing well, and has decided to move all of his bank business to you. He opens up the accounts he needs for his business and deposits $100,000.

Here's our current situation:

Ok, so we have something new here: Required Reserves. Even though we want to loan out Joe's money, we have to keep some of it on hand in case Joe needs it (you know, to make payroll). The Federal Reserve has regulations on the reserves that banks must have on hand for different financial products. For now, let's call it 10%.

Now that we have Joe's deposit, we can lend out up to $90,000 (Joe's deposit, less 10%). The next day, Emily walks in and wants to take out a loan so she can start up a business down the street. She's got a great business plan, and a track record of building successful businesses. You make the loan on the condition she does her banking with you. She agrees, and deposits her newly acquired $90,000 of cash with you.

Let's review where we are now:

We have $190,000 deposited at our institution now. We are obligated to provide that cash to our depositors on demand. However, I've only got the original $100,000 in cash to cover those demands. If you carry this out to it's logical conclusion, I could actually lend out as much as $900,000 on the original deposit!

I'm sure the intelligent among you can see the problem. I could have as much as $900,000 in deposits I'm required to produce on demand, but I've only got $100,000 in cash to cover the demands.

If this is the first time you're hearing this, just know that the banking system of the entire world runs this way. This system runs smoothly so long as everyone doesn't want all of their money at the same time.

We'll get back to this soon...

Enter, SVB

Silicon Valley Bank was founded on October 17, 1983 by Bill Biggerstaff and Robert Medearis. The idea was simple – they were going to cater to startups funded by venture capital. Once banking customers, they could add additional services to continue catering to these clients as they scaled their business.

The bank has had its ups and downs over the years, largely influenced by investment cycles. During the dot-com boom, their stock price soared and fell again as soon as it burst. In 2000, the bank gained a new CEO, Ken Wilcox, who chose to continue to concentrate in servicing tech companies instead of diversifying into a more traditional bank servicing model.

By 2015, the bank claimed to serve 65% of all US Tech startups, and many prominent VC firms.

The Pandemic

As many of you will recall, financial markets went through an interesting period during the pandemic. Instead of collapsing in the face of an economic slowdown, the stock market boomed. Armed with stimulus checks, a lot of people stuck at home began doing what every bored person with some extra cash does – they start gambling. This pushed valuations for public companies through the roof, and as a result, the VC business model become even more profitable.

With public valuations getting pushed ever higher, private valuations weren't far behind. Plus, without the votes of the masses influencing stock prices on Robinhood, private valuations can sometimes be even more insane than GameStop circa 2021.

WFH meant more people were spending money online than ever before, and a new generation of entrepreneurs were ready to build new products for them to spend that money on. Those new products usually needed funding, and money was cheap (and often easy to get). It almost reminded you of the party scenes from The Great Gatsby – the money flowed and everyone had a good time.

Venture Capitalists had a lot of money to place, and if you had a URL ending in ".ai", you got a check. A big one, and Silicon Valley Bank was standing by ready to serve your needs. Over the course of 2020 into 2022, SVB's total assets swelled from $71B to over $211B – The 16th largest bank in the nation.

Treasury Portfolio

With all of these new deposits coming in, SVB decided that instead of rushing poor quality loans out of the door, they would try to do the responsible thing and invest their depositor's money into the safest type of investment out there – US Treasury Bonds.

At face value, it's pretty smart actually. But they didn't execute on it very well.

For starters, as we all know, bond prices are inversely related to yields. Yields up, price down. They got all of these new deposits in a zero interest rate policy environment, and subsequently bought some of the most expensive Treasurys in history. But what ultimately ended up causing issues, was that most of their investments were in long-dated stuff that wasn't going to mature anytime soon. This exposes them to interest rate risk.

The problem with being concentrated in the startup world is that startups tend to burn cash. So, as rates rose, two things happened: 1) the party stopped, the money stopped flowing, and depositors as a whole were pulling more money out than they were putting in, and 2) bond prices were in free-fall.

Now, all of this money they had tied into bonds had to get liquidated in order to fulfill their obligations to their depositors. They had to sell sub-2% coupon bonds in a ~3.90% rate environment, leading to a loss. They're obligated to make depositors whole, so they had to back-stop this loss by issuing stock. This spooked markets, and more depositors, who demanded more cash.

The cycle had begun...

Hedging

Banks use hedging for the exact same reason you do – they don't want to get pinched when rates move the wrong way. In this case, the swaps they used for hedging were Fixed Payer swaps. This means that they paid a fixed rate, and received a floating rate.

In this position, the swap value moves in their favor as rates rise, and moves against them as rates fall. It's a handy instrument to have when you hold a bunch of long-dated Treasurys.

SVB did actually have some hedges in place at the end of 2021, about $10.7B worth. It was less than 10% of their total portfolio, but you don't really need to hedge your entire treasury portfolio, unless all of your depositors suddenly start demanding all of their money back at the same time 😬.

Here's a summary of SVB's hedge positions for FY 2021 and FY 2022. You can see that most of their hedges had been unwound over the course of the year

This is pure speculation on my part, but I think this is one of the most concrete signs that SVB knew things were bad way back in 2022. They had a LOT of fixed-payer swaps in a steeply rising interest rate environment, they would have been worth a lot in SVB's favor. I'm sure they made a killing unwinding those positions. If you needed a way to raise some cash without selling any assets, this would have been a good way to do it.

Bank Runs

What's the surest way to kill a bank? Convince enough depositors to all demand their cash at the same time. That's exactly what happened with SVB.

To be clear, it wasn't the bad hedging, it wasn't the losses from their treasury portfolio, it was the good old fashioned rumor mill that collapsed SVB. Last Wednesday, SVB surprised investors with the announcement that they would need to raise $2.25B to cover their realized bond losses. On Thursday, SVB seemingly botched an investor call that sent their stock price plummeting, and by Friday they were taken over by the FDIC. So what triggered this?

The Dominos

First things first – nobody actually pays attention to what's going on at their bank. This includes the VC's and founders that used SVB for their banking. That is, until on February 23rd, Byrne Hobart's newsletter, The Diff, called out SVB for their less than stellar risk management situation.

Every VC on the planet reads Byrne Hobart. Every VC on the planet is also in the business of evaluating the viability of businesses, so after reading this they do what VC's do, and they started looking into this situation themselves. It wouldn't be too much longer until the next earnings call, so they started pay attention.

Strategic Actions/Q1'23 Mid-Quarter Update

This was the title of the investor presentation sent out on March 8th. It was a pretty standard looking bank presentation. You can take a look at it yourself here.

First, if your bank is sending out a voluntary mid-quarter update, it's probably not good news. The first couple of pages they rip the band aid off and say that they're taking a big realized loss and then spend the rest of the presentation trying to convince you it's not a big deal.

It's a little bit like when one of my kids tells me they got an F on an exam, but it's okay because as long as they get a 55 on the final they'll still pass the class.

This, of course, spooked the hell out of not only their investors, but their depositors (and more importantly, the VC's that backed them).

The VC Scare

Peter Thiel, USV, and Coatue send out messages to their portfolio companies to pull out funds from SVB. Cue the first couple waves of bank runs, but nothing the bank can't dig up cash for.

You can't keep this sort of thing a secret for long though (measured in hours, not days). Pretty soon, tech twitter catches word that all of their buddies have been told to get out, making them wonder if they should be pulling out as well. That's when the real bank run starts.

In the space of 48 hours, a staggering $42B in deposits are pulled out of SVB, roughly 25% of their base. I'm not sure even the most well capitalized banks are in a position for 25% of their deposits to evaporate overnight.

Back to Fractional Reserve Banking

Recall our explanation of fractional reserve banking above. The bank is fine so long as everyone doesn't want all of their money at the same time. What's interesting about SVB though, is their assets didn't really outstrip their deposits by all that much. Most of it was just stashed in Treasurys.

The problem was still the same though. They hedged badly (or rather, not at all), and when depositors came for their cash, the bank was forced to take a loss. That loss is sizeable for a bank their size.

A Sign of Things to Come?

So let's get this out of the way, is this a sign of things to come? Yes and no. Yes, there are going to be banks that hedged badly and got caught by the changing interest rate environment. No (probably), the largest banks that represent a systemic risk if they collapsed probably won't face any trouble. They're well capitalized, stress tested annually, have way better hedging strategies in place, and aren't diversified into a single, fickle group of depositors.

However, we can never say never. This could just be the first domino to fall. But let's also try to see this in context. SVB got pinched because they were too heavily concentrated in one type of clientele, and stuck all of their cash into an instrument that would expose them to interest rate risk without hedging the exposure.

How Did This Happen? Aren't Banks Regulated?

Yes, banks are regulated, but many of the regulations, hedging requirements, and reserve requirements only apply to banks with more than $250B in assets under management. This includes the annual stress tests that the largest banks in the country undergo each year. SVB fell shy of that, with around $212B at its peak.

I think the irony in all of this, is that their asset portfolio was ~50% Treasurys – they tried to do the responsible thing! Well, responsible from the perspective of a risk committee with little no risk management experience. What they didn't prepare for was the potential of having to realize paper losses.

It took more than 48 hours

SVB knew about this long before last week. They did operate without a Chief Risk Officer for most of the last 18 months, with Kim Olsen not joining until late 2022 – too late to do anything about SVB's precarious position.

The folks at Forbes released some disclosures they believe point to some signs that over the last year, SVB was acutely aware of the position they were in.

• It's 2023 proxy statement called for seven of its 11 board members to serve on its risk committee, while no other committee has more than 5 members. Interestingly, their most qualified director, Thomas King, a former IB CEO, wasn't on the board. His experience would have been far more useful than that of a Napa vineyard owner, a retired healthcare CIO, a former US Treasury undersecretary, VC partners, and consultants.
• The risk committee met about twice as frequently in 2022 as it did in 2021 – 18 times vs 7 times. It's not clear whether these were evenly spaced, or whether the frequency accelerated towards the end of the year.
• Most troubling was that SVB operated without a CRO for most of 2022. Their former CRO was moved into a non-executive role in April 2022, and a replacement wasn't announced until January 2023.

Takeaways

There's a couple of things that make SVB's failure (and most recently, Signature Bank) unique from the banking sector as a whole:

• Each bank was concentrated in a very niche market. SVB serviced startups, and Signature was focused heavily in crypto. Both segments are coming out of recent boom cycles, leaving the banks exposed to a rapidly shrinking deposit base.
• SVB tried to do the conservative thing and place deposits into Treasurys. A smart move, if their exposure had been hedged, or if they had rolled short-term investments to ensure they could always be no more than a month away from getting cash they needed.
• The rumor mill killed SVB. Their collapse is putting every other bank under scrutiny, so there is absolutely some non-zero chance that some banks will face scrutiny from their depositors.
• First Republic was suggested as an alternative by the same VC's that told their portfolio companies to pull their funds out of SVB (the same VC's that told them to put their money there to begin with). Not the kind of recommendation you want, sending their stock plummeting.
• The Federal Reserve and the US Treasury is going to be going full-blast trying to reassure American citizens that the financial sector is stable. They've already back-stopped all SVB deposits, beyond the normal FDIC insurance of $250,000 per depositor. If you work for a startup that uses SVB, your employer will get access to their funds to make payroll. The Fed's primary concern, before inflation and unemployment, is ensuring the stability of the US financial system.
• Interest Rates are DOWN. Two-year Treasurys had dropped 100bps since Thursday, and are down by ~50bps as I'm typing this (Monday morning, 3/13/23). This represents the largest single drop in US history.
• Emergency rate cuts are on the table to ensure the stability of the financial system. Not guaranteed, just on the table.

The Story Isn't Over Yet

This saga is still unfolding. Take everything above with a grain of salt. This is only based on the information that was available in the days following the collapse, so everything is subject to change in the face of new information.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

One of the coolest things I get to do in a director level role at a software company is meet a lot of different people outside my organization. I get to converse some of the most experienced, intelligent people in our broader industry and getting some incredible nuggets of wisdom.

Earlier this week, I met with a tech consultancy here in Charlotte to talk about some sophisticated data management strategies and techniques. During our discussion, one of their team members sitting off in a corner made a statement so profound to me that I decided to write an article about it.

Strategy Debt is way more expensive to fix than Tech Debt.

I mean, whoa...

Have you ever heard something that you kind of knew intuitively but it didn't really hit you until you heard it phrased that way? This was one of those moments for me. Product Strategy is my job, and yet it somehow hadn't occurred to me to think of strategy decisions using the same frameworks that we think of tech decisions.

Tech Debt

If you haven't heard of the term "Tech Debt" before, it's a common way to describe shortcuts or compromises taken in the software development process. Every piece of software you have ever used has tech debt.

For example, let's say you're building a new product feature to wow a new prospective client that could open the door to a new market segment for your product. The potential customer asks you to show them this feature in just a couple weeks time. Not wanting to miss the opportunity, you ask your developers to get it out the door faster than what it would normally take to build. They of course agree to do their best to hit the deadline, but in the process they take shortcuts. Maybe they hard coded some variables, or wrote really fast, ugly code that doesn't make sense to anyone who has to read it later. The point is, is it wasn't really done the "right" way.

The reason we describe this phenomenon as "debt" is because it functions exactly in that way. You've borrowed from the future in order to get something done today. At some point, that debt is going to have to be paid. A library upgrade makes a breaking change to your implementation, or some other new feature that builds on the one you made in haste requires some refactoring of the first to make the second.

You can think of the types of tech debt as have an interest rate, just like with CRE debt. Some debt has a low, or even a zero percent interest rate, while other debt has really high interest rates that have to be paid off eventually before it puts you under.

Having tech debt isn't bad, just like debt in real life. It's all about using it intelligently and making sure you keep your interest expense down.

Strategy Debt

Strategy debt is really no different, but the interest rates are a lot higher.

Think about it. When you set a strategy in motion, everything that moves to support that strategy is built alongside it. Your company is going to set up operations to support the strategy. Your product and tech teams are going to design software to support this strategy.

Bad strategy decisions are expensive. Even if everything is executed flawlessly, changing the strategy means unwinding everything downstream from it. Bad strategy means you're moving forward burning cash to build up infrastructure to move you in the wrong direction. If you don't recognize the bad strategy in time, you could end up with a flop from what could have been a promising product.

Ambiguity

Broad objectives with no clear direction or appreciation of nuance are usually unsuccessful. If there's no buy-in from your leadership team or real consensus on what your objective is, you're leaving a door open for each stakeholder to make their own interpretation of what needs to be done.

I've become a proponent of a concept called a value pyramid. How does our platform build layers of value? How can we continue leveraging value as we hop from one feature to the next? If you cannot answer those questions with specificity, then we have too much ambiguity in our strategy.

You also have to know where you're starting from. Ambiguity sometimes comes from a lack of understanding your starting point, not a lack of knowing where you want to go. If you don't know where you're starting from, you're going to waster countless man hours and resources floundering for a foothold (anybody remember the Fire Phone?).

Value Drivers

It's absolutely critical to understand your target customers and how you drive value for them. You have to know what that core competency is that you are the best at and how that creates value for a target customer.

Your target market isn't aspirational, it comes from extensive research and testing to discover your target customer and what they care about. Your target customer isn't "everybody", or for B2B companies like mine, "everybody in XYZ industry". There's a specific type of customer with a specific problem, or set of problems, that your product can solve.

Not Making Hard Choices

This is a big one. You can't be all things to all people. You have to make hard choices about what your core competencies are and who you're going to create value for. Avoiding the hard choices inevitably ends with a team trying to support conflicting demands. You have to choose.

This often stems from the idea that adding more and more features, you will automatically create more value out of thin air. Instead, you have to make decisions about what value you can create and then decide whether you can create features off of that.

Bad Strategy Will Happen

Bad strategy can and will happen to every company. Even wildly successful companies have their faceplant moments (a la Apple's Newton, or more than 280 products killed by Google). Just apply a little sanity testing and be aware of where your strategy missteps can come from. There's a lot of resources out there to help.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

I’m going to get philosophical.

We humans always long for something we can’t have. We’re constantly trying to tinker with and experiment with the way we operate and do things to find this thing that alludes us. We’ve experimented with different political and economics systems in the search of utopia. We constantly innovate trying to build a better mousetrap. New influencers pop up every day to convince us that their dietary model is the answer to better health.

But the thing that alludes them all — perfection.

It’s such a human thing, to constantly try to achieve the impossibility of perfection. Yet, humanity has constantly fought internally over making changes to try and achieve this.

Software is no different. Countless methods and systems, check and balances, different coding languages and documentation styles, automated and manual testing processes — all created with the same goal in mind — to eliminate bugs.

You Can’t Have Perfection

There’s a fundamental law of the universe that will always prevent us from reaching perfection. It’s simple really: it’s far easier to break things that to build them. Anyone who’s tried to assemble anything from IKEA knows this is true. I think building software makes this more blatantly obvious than in other things.

Software platforms are best described as “Complex Systems”. Simply put, a complex system in one that cannot be understood in it’s whole (within the limitations of the human brain), but by studying the behaviors of its parts.

There are several characteristics that are symptomatic of complex systems. The first, and most obvious from it’s name, is Complexity. That is, a system’s behaviors cannot be easily inferred from its properties. The can exhibit Non-Linearity, which is a system responding in different ways to the same inputs. Parents of small children will know this effect by another name: Chaos. Lastly, and probably most importantly, is the concept of Emergence. This are traits of a system that are not apparent from its components in isolation, but result from the relationships and interactions between parts of a system. The most frustrating bugs in software come from this emergence trait.

Bugs Live In Code

My CTO is fond of a saying that has entered a regular part of my vocabulary. It’s a simple phrase that holds a lot of lessons to unpack:

Where do bugs live? Bugs live in code.

This is a hard truth to learn, especially for young guys like me that think we can solve anything if we’re given enough time. But there’s wisdom to this way of thinking.

To quote Mark Twain¹, “I didn’t have time to write a short letter, so I wrote a long one instead.” In writing, it’s often said that it’s much harder to write shorter than it is to write longer (clearly evident by the length of this post — does this guy know when to stop typing???). The same is true with app development.

The best way to write good code is to write less code. Fewer lines are easier to read, there’s fewer dependencies, and just fewer places to make mistakes. Fewer requirements means the engineers can write less.

This is also taken into consideration when we’re faced with a build vs buy decision. When you BUILD, you have to write a LOT of code. That’s opportunity for bugs, and only builds onto your complex system. When you BUY, the code you write is de minimis, just enough to integrate with the other service. There’s fewer opportunities for bugs, and therefore usually easier to maintain.

Problems Increase Exponentially

It’s way easier to write code the first time through than it is to go back through and debug it. Both from a time and number of lines of code written, it’s the debugging process that kills forward momentum.

In practice, what this means is that the number of bugs you add to your software increases exponentially by the number of features you add to it.

Take adding a simple form for example:

The function of what a form does is to take an input and record them to a database. It’s pretty simple, it only adds a single new piece of functionality. However, by creating this form, I create an exponentially larger number of risks. Thankfully, computer science has progressed to a point where these risks are minimal, but there’s a number of things that could go wrong that can become bugs that need to be fixed:

• Multiple UI elements that may not render correctly
• Buttons that need to be wired to API calls
• Multiple API call that may not function as expected
• SQL queries to add the inputs to the database

Obviously, any skilled developer could probably build a simple form like this with no fanfare, but imagine all of the potential pitfalls from a simple form being multiplied across an increasingly complex system. In order to gain one new piece of functionality, there are dozens or hundreds of potential points of failure that would need to be debugged.

So what’s the implication? That software isn’t to be trusted??? No, of course not. All of these risks have have run through by thousands of engineers before us, so we know how to handle these issues reliably. BUT… the more features you add to a platform, the more that need to be supported and maintained.

In other words, the number of real world problems you can solve with your application is limited by the size of your technology team, which in turn is limited by the amount of revenue you generate from your customers, which is in turn limited by the number and severity of problems you’re solving for your customers. There comes an equilibrium of all of those forces you can’t push beyond.

Filters Instead of Prioritization

One of the most annoying practices in agile culture (in my humble opinion) is prioritization ad nauseum. Everything in agile software development is about prioritization of solutions. This leads to a constant state of meeting after meeting prioritizing the latest set of problems within the always growing list of existing problems.

A better method is filtering. What problems need to be solved and which don’t matter if they’re never solved? Empowering your people to filter these problems will yield incredible results. Your engineers and product people don’t need to know the order of prioritization for 20 different items in order to begin solving problems, that just slows them down. However, they will know which buckets of items need to be fixed asap and which don’t matter if they’re never fixed.

Progress Is Incremental

Think about your daily life as a busy adult. You wake up and get ready for the day. That takes time. If you’re a parent, you also have some little minions to get ready for a daily routine. More time. Get kids to school, commute to work. Daily hygiene routines, eating meals, cleaning and maintaining your home and car. Mundane tasks at work. Dozens of little activities that are needed of you just to keep going. How much of that time do you have left to improve yourself?

Do you think building software is any different? There’s a lot of work that has to be done just to keep things humming. Software updates have breaking changes that need to be fixed. Security patches need to be applied and tested. Changes to real-world processes and workflows need to be applied to existing software functions (do you really think it took 4+ years to transition to SOFR because it took that long to say, “We want that one”?).

This leaves only a small part of your available capacity available to be committed towards forward momentum. Anything less, and you have a fragile system.

To Err Is Human

Perfection isn’t our default state. Don’t get too caught up trying to achieve it, or thinking that it’s somehow attainable. That sort of reasoning will only end in failure, if we just work hard enough, plan hard enough, everything will come out perfectly. If we don’t, it’s because someone screwed up somewhere.

This just isn’t reality. Chaos is our default state. We build things to make our situation better, but anything we build is ultimately built by people, which are only human. You can’t change that. Instead of trying to fight it, instead build processes with the knowledge that things will never be perfect. Your software will be better, your business will be better.

Make your software better, not perfect.

¹Okay, like a lot of quotes we attribute to famous people, he didn’t actually say this, but it sounds cool.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

About a year ago I found out I was going to be taking on a brand new role inside of my company. I would be leading a department of three (me, myself, and I) on a quest to help our still young company to “grow up” a bit in the way that we approached building our product. This department, called Product Strategy, would be responsible for developing the frameworks that we used to decide what our product would become, and to evangelize that vision within our company.

The very first challenge we had to tackle was making sure we were all on the same page with where this company was going. We were going through a pretty rapid expansion, experiencing above average growth in customer base and headcount. This increase in headcount included growth in our leadership team. As our leaders grew in their respective roles, so did the number of opinions on what it is we needed to do next.

This isn’t a bad thing — these opinions all highlighted areas of improvement that needed to be made in our company and our product. But before we were going to resolve any of these issues and move forward as a more mature company, we would need to make sure we were all speaking the same language.

The first question — is this a Product or a Platform?

Building a Product

So first off, let’s talk about Products. These are conceptually simpler than platforms, and therefore simpler to develop. You already know intuitively what a product is — it’s something that was created to serve a limited purpose, a specific solution to a specific problem.

Holiday API is a perfect example of this. This is a one-off solution to a problem for anyone who’s had to contend with calendars before. This product provides you with a list of public holidays for just about any country in the world. It solves the problem beautifully too, giving you not only the actual holiday, but the observed date as well. It makes working with any date-based functionality that much easier.

Products are often some of the most pleasant types of software to work with. Because the scope is so small, the developers can focus on making the interaction with that product perfect. However, because the scope of the solution is so limited, it also makes the impact that product can have limited as well.

As great and amazing as Holiday API is, it’s reach can only extend to users who are creating software that require some sort of date based functionality that needs to know when public holidays are occurring, and the end user needs to know how to code. Because I fit that criteria exactly, my experience with the product has been amazing. But the second I lose one of those, the product is worthless to me.

That’s okay though, not every product is going to be useful to every person. It just means that my reach as a business is limited.

Building a Platform

A platform is software that connects products. These are more complex to work with, but the number of problems they can solve becomes broader. This is an important concept, because we shift away from solutions being product-led and towards solutions being user-led. Because of this, we’re not limited to a strictly defined user with a strictly defined problem.

Zapier is a great platform example. It’s a platform with a sole purpose of connecting OTHER products together. Their webpage shows an example of this. When your sales team gets a lead on Facebook, post a notification in Slack, and finally add that person to our CRM. Zapier’s platform isn’t part of any of those products, but it can connect all of them together.

Platforms can be a little more challenging to work with, because of the user led solutions model. This puts some of the problem solving back on the user. However, if the platform connects functionality appropriately, then it means the user can solve many more problems that with a product.

I’ve used Zapier myself, and while getting all of the API’s to work flawlessly can sometimes be a little bit of a challenge, it’s always been due to user error (i.e. yours truly) and not the platform itself. It just took a little more effort on my end. In exchange for this extra effort, I get to automate a near infinite number of workflows and solve an infinite number of problems. The platform can be useful to nearly anyone.

Keep in mind that while this is in theory more useful to more people, it is harder to pull off.

Which to do?

As with most questions, it’s not that straightforward. You can imagine the Product-Platform Continuum as existing on a spectrum, like this:

We have pure products on one side, with pure platforms on the other. In reality, most software applications fit somewhere in the middle.

Think of a product ecosystem. Apple products all work together seamlessly in order to get you to buy other Apple products. If you have an iPhone, you can iMessage on your Mac or iPad as well, making you more likely to buy those products over a competitor’s. Google’s ecosystem is software based instead of hardware, but it’s intent is to keep getting you back to Google search and clicking on those sweet, sweet ads. The most popular phone OS in the world by a wide margin is Android, which defaults you to Google as it’s search engine. Chrome, the world’s most popular browser by far, also uses Google as it’s default search engine. This ecosystem is meant for you to keep using Google search and clicking on Google ads.

Each one of those products above isn’t a pure product or a pure platform, it’s something in between. They all exist as independent products, but they’re also all interconnected into an extended platform.

If you run cloud-based software, it’s almost inevitable that you will find that you have created some sort of limited platform, even if it’s not your intent. It’s difficult to create a standalone product that creates a significant amount of value all on its own.

The Product Evolution

Generally speaking, almost no platforms start life as a platform (they do, but those are rare). Instead, products tend to evolve into platforms, settling somewhere in between each pure state.

Our application is the same. We started life as a well-defined singular product, that over time has morphed into platform of products. Some of the products we’ve created ourselves, and others are 3rd party products.

I want to stress that you shouldn’t equate Product = Bad and Platform = Good. They each have their benefits. Sometimes you just need a holiday api — something that solves a very specific need really, really well. Other times you just need a platform to connect all of your other products together. Most applications just naturally end up being somewhere in between.

P.S. Aristotle

The Ancient Greek philosopher, Aristotle, is often credited with saying, “The whole is greater than the sum of its parts”. As it turns out with a lot of clever sayings from the past, this isn’t entirely true. The actual quote¹ reads,

“In the case of all things which have several parts and in which the totality is not, as it were, a mere heap, but the whole is something besides the parts, there is a cause; for even in bodies contact is the cause of unity in some cases, and in others viscosity or some other such quality.”

In light of what we’ve discussed above, I like this version better. When you’re building your software application, having a platform isn’t better than having a product. After all, since platform is something besides the collection of products, not necessarily better than them.

[1] Aristotle’s Metaphysics, Book VIII, 1045a.8–10, 1908 translation by W. D. Ross

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.

I think one of the most difficult aspects of building debt management software is defining exactly what that means. It’s also one of the more interesting thought exercises to walk through. It’s something every real estate firm does, but everyone has their own practices and methods for it. In some firms, it’s a joint exercise between executives, in others it’s up to the asset managers, and in others still there are dedicated finance teams to stay on top of debt portfolios.

To accomplish their task, processes are usually set up to solve specific problems as they come up. Organize files in a drive system so we can read docs. Go run a prepay calc when we’re thinking about a disposition. Create a spreadsheet to keep track of Lender Compliance requirements. All one-off solutions to fix specific problems.

There’s nothing wrong with this approach, I imagine most best practices started life as people creating ad hoc processes to solve problems as they came up. Eventually, processes are refined and connected to create best practices. These practices have existed for Asset Management for a long time. You would be hard pressed to find an asset manager that couldn’t easily fill into a similar role at a new firm. However, I suspect it’s harder to find the same similarities when it comes to debt management practices.

I’ve had the privilege of seeing the practices and procedures of dozens of firms over the last several years, which I’ve tried to distill the best of into three distinct capabilities. These capabilities have been designed in such a way that you do not have to do all 3 simultaneously, but rather build on one another and can be implemented over time.

Decision Making Capability

The foundational capability for any management practice is to enable decision making. The same is true for both asset management and debt management. These practices exist so that you can make timely, informed decisions.

To master this capability, you want to be able to fulfil the following elements.

• Locate loan information quickly — This will usually involve creating quality loan abstracts and linking the data back to the original reference in the loan docs.
• Create reference calculations that can be updated easily — Think about the different data points you need to reference frequently, or those where timeliness is an advantage. Loan Cashflows, prepayment penalties, financial covenants (like DSCR and Debt Yield), and supportable loan amounts are all data points you may want to have access to without a 2 day waiting period.
• Access Systems — Management/Executives generally don’t want just anyone to have access to this info, so you’ll need to create some sort of access system for this. It could be as simple as a drive service with user access permissions, or it could be as much as a dedicated debt management service.

Just so we don’t lose the forest for the trees, remember that the goal of this capability is that you are able to provide timely, accurate information to the people that need it, when they need it. The degree to which you build this out is dependent on your firm’s needs.

This is just the foundation, once this is in place, we can build the next layer on top of this…

Loan Administration Capability

As we master control over our loan information, we enable ourselves to take on more sophisticated debt structures. These sophisticated debt structures often mean a greater administration burden. Don’t worry though, because we anticipated this and began laying the groundwork for this well ahead of time.

Just like last time, there are elements to this capability that we need to be able to master.

• Lender Compliance — Am I the only one who thinks it’s funny/odd that the lender relies on the borrower’s math to prove they’re in compliance? Regardless, we need systems in place to collect deliverables, create/update calculation workbooks, review compliance packets, and actually deliver them on time.
• Loan Management — This is a category of items that entails things like construction loan draws. This won’t apply to everyone, but for borrowers that use high-touch debt, this is a must-have. You’ll need a system in place to track who made a lender request, what it was for, how much it was for, what deliverables had to accompany it, and who approved the request.
• Debt Valuation — For most, this practice is largely dependent on what kind of investors you have, and whether they want to see this sort of information. Thankfully, if you decide to do something like this in-house, most of the effort to create a calculation engine is front-loaded, and the maintenance is pretty straightforward.

I’m sure there are other elements to this capability, but this will cover the big ticket items. Once this capability is mastered, we can move on to the last capability.

Strategic Management Capability

We’ve thus far managed to gain mastery of our Decision Making Capability, as well as our Loan Administration Capability. These two capabilities have allowed us to really become sophisticated in the way we make decisions around and administer our loans. However, we now also need to make sure that we stay on top of ever changing debt markets and are using the most efficient financing that we can.

• Portfolio Analysis — This means we’re going to start looking at our debt portfolio as a whole, instead of as an asset-by-asset decision point. Do we have processes in place that allow us to answer questions like the impact a portfolio-level hedge will have on our projected debt cost? Can we see how a new financing will affect our overall Debt Yield?
• Debt Optimization — Continuing our line of thought above, this is a specifically aimed at finding ways to optimize our debt structure. For example, is there a way for us to shift debt burdens around to properties that can fetch the cheapest debt in order to pay down more expensive loans? Should we be using credit facilities or lines of credit instead?

Given how abstract this capability is, there’s virtually an infinite number of ways to manage this and create this capability depending on your firm’s makeup and needs.

Summary

There’s a need to create debt management best practices for CRE. Without standard practices, it’s impossible to set policies, implement any sort of controls, or even understand how certain habits are costing you money.

I’m interested in hearing from you. Are there any capabilities you think should be included here that aren’t?

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.