The Outer Loop (Paving Gravel Roads Into Scalable Software)

Has you ever noticed how so many enterprise AI deployments start with this incredibly slick, perfectly polished demo, only to slowly and painfully devolve into endless, wildly expensive, and just fundamentally messy consulting project? Oh, absolutely. I mean, the boardroom slide deck is always flawless, right? The demo is running on this perfectly clean, carefully curated data. And then, you know, the reality on your operating floor is totally different. Yeah, where the software actually has to live and breathe. Exactly. Where it interacts with your weird 20-year-old legacy systems, it's just a completely different universe. It really is. You sit in the boardroom, the vendor shows you a beautiful dashboard, you sign a massive check. And then, I mean, a year later, you have an army of consultants living in your office. Just writing duct tape code to keep the whole thing from collapsing. Yeah. Writing duct tape code. Because you buy the software, thinking you're getting this massive, scalable leap in efficiency, you think you're buying a product. But you're not. Right. Six months in, you're essentially funding a bespoke IT service firm just to handle your company's unique edge cases. It's an incredibly common pain point for anyone buying or, you know, building enterprise tech. Which is exactly the dynamic we are tackling today. Yeah. So, welcome to this deep dive. We have a highly requested mission on the table for you today. We do. We are extracting the most vital, actionable insights from a truly fascinating text. It's a book called The Forward Deployed Engineer by Show Shimoda, which by the way, you can pick up right now on Amazon. And honestly, anyone operating in the enterprise software space, especially AI, needs to internalize this book. For sure. Shimoda has essentially written the survival manual for the last mile of deployment. He tackles that exact friction point where, you know, beautiful theory meets ugly operational reality. Okay. Let's unpack this because we aren't trying to summarize the whole book today. We have a laser focus on one specific game changing section. Yes. Chapter nine. This chapter covers what Shimoda calls the outer loop. And the entire premise is about how you scale field intelligence. So your AI deployment doesn't become that bottomless money pit we just described. And we really need to establish the stakes for you, the listener, right up front here. Yeah. If you are a founder or an engineering leader or even an investor, the concepts in chapter nine literally dictate your survival. Wow. Literally dictate survival. Yeah. Because the difference between an AI startup surviving as a highly profitable software business with say 80% margins versus dying a slow, miserable death as a low margin services firm, it entirely depends on mastering the outer loop. So it's maker break completely. You might have the greatest foundational AI model in the world, but if you get this operational mechanic wrong, your business economics will just collapse under the weight of all that custom work. So what does this all actually mean to understand the outer loop of chapter nine? We have to establish chronological baseline first. Right. We need to briefly touch on the inner loop, which Shimoda actually covers earlier in chapter eight. Yeah, the inner loop. It's the starting point. It is. It's the tight, fast, highly reactive cycle of building a custom deployment for a single customer. You drop a forward deployed engineer and FDE into the customer's environment, right? Exactly. And they prototype rapidly. They hit the messy reality of the customer's operational pain points. And they basically force the software to work for that specific localized problem. So it is inherently bespoke. Yes. Highly bespoke. But the outer loop, which is our focus today, it begins the exact moment that single customers bespoke deployment goes into production. Right. The outer loop's entire reason for existing is to capture the brutal lessons you just learned from that one specific deployment and feed them back into your core platform. Exactly. Feed them back. The mission is to make the next customer's deployment infinitely cheaper, faster and just more robust. So if the inner loop is about brute forcing a victory for an audience of one, the outer loop is about harvesting that localized victory. I love that phrasing, harvesting the victory. Yeah, you are extracting the value from that messy deployment. So the centralized platform gets smarter and more capable for every single future customer you sign. So Shmota uses this core metaphor to explain the dynamic between the FDE and the field and the core engineering team back at headquarters. And I really want to linger on this because it frames everything else we're going to talk about. Thick organ for. He describes the dynamic as gravel roads versus paved super highways. It perfectly captures the tension and the utility of both engineering approaches. So the gravel road represents the customer specific code written by the FDE. Right. It's quick. It's rough. It definitely doesn't scale cleanly to other customers. But it successfully gets that specific customer from their operational pain point to a business outcome. Yeah. Imagine you need to get from point A to point B through this dense, completely uncharted forest. The FDE doesn't do like environmental impact studies, right? No. They chop down some trees, lay down some gravel, and get a jeep through. It works for that one customer's journey today. And crucially, that gravel road is built under the severe constraints of the customer's actual living environment. Like what kind of constraints? Well, the FDE might be trying to pull data from a legacy mainframe that hasn't been updated since like 2004 or writing a weird script to parse these incredibly inconsistently formatted spud sheets. Right. The road is ugly because it has to be expedient. Exactly. It prioritizes immediate business value over architectural elegance. Okay. Then you have the paved super highway. This represents the generalized pristine platform code built by the home office engineering team back at HQ and building a super highway is phenomenally expensive. You have to bring in the heavy machinery, pour the asphalt, paint the lines, build the guard rails. It takes months. But once it's built, the cost of adding one more customer to that highway is virtually zero. Right. Yeah. And it can handle massive amounts of traffic at high speeds. The super highway is clean. It's scalable. It has automated testing and it's maintained centrally. So is the definition of high margin software leverage? Yes. But again, the upfront capital and time investment is just massive. Okay. Wait. I have to pause and push back on this fundamental premise. Okay. Go for it. Highway, custom code, you know, laying down these messy gravel roads, exactly what modern sauce companies are explicitly taught not to do. It usually is. Yeah. It sounds like Shimoda is actively encouraging massive technical debt. If you tell your engineers, hey, go out into the field and build a bunch of unscalable custom integrations, every traditional engineering manager is going to have a panic attack. Oh, to a traditional engineering manager, it absolutely looks like technical debt. But Shimoda argues something completely counterintuitive here, which is what's fascinating here is that it isn't debt. It is validated learning validated learning. Okay. Explain the mechanics of that difference because debt and learning look awfully similar when they are both made of undocumented code. Fair point. Well, consider the alternative. In traditional software development, product managers sit in a room, guess what a customer might need, and spend millions of dollars building a pristine super highway. Just based on a guess. Exactly. Six months later, they open it up to traffic and realize nobody actually wants to go to that destination, or the customer's trucks are too heavy for the bridge they built. The super highway just sits empty. That is a catastrophic, unrecoverable waste of engineering capital. Ah, right. It's the classic. Build it and they will come fallacy. You built the perfect solution to a problem nobody actually had. Exactly. So instead, you build the cheap, ugly gravel road first to prove that the route actually has economic value. You test the demand. Right. The FDE builds this rough path because the customer is bleeding today and needs to turn it. Once it's built, you watch the traffic. Are the customers users actually getting value out of it? Do they abandon it after a week? Right. Do they hit unexpected potholes? You only mobilize the heavy machinery to lay the expensive asphalt of a super highway after the traffic on that gravel road proves the investment is actually justified. So the gravel road is essentially a high fidelity prototype that the customers paying you to use in production. Yes. You aren't building it with the intention of maintaining it forever. You're building it to figure out if the destination is worth the platform team's time. The natural tension between the FDE and the field optimizing for speed and the platform engineer at HQ optimizing for scale is the actual engine of this operating model. The FDE is your scout. And the platform engineer is your city planner. That reframes it perfectly, yeah. We are using the FDE's quick and dirty work to de-risk the platform team's massive investments. But that naturally introduces a terrifying operational bottleneck, doesn't it? It can, yeah. Like if you have 50 FDE's running around the globe, building hundreds of custom gravel roads for different enterprise clients, how do you decide which ones actually deserve to get paved? You can't possibly pave all of them. Right. Or your engineering team would just grind to a halt. Attempting to pave every gravel road is a fast track to bankrupting the company. You need a rigorous filtering mechanism. And Shimoda calls this the productization decision. Yes. This decision is driven by the productization committee, which is a joint task force, right? Right. Comprise of leaders from both the forward deployed engineering function and the core platform team. They typically meet every quarter to review the landscape of all the gravel roads built in the field. They are looking at this chaotic web of custom code and asking, basically, to pave or not to pave. And they apply a very strict four-dimensional rubric to every single gravel road. If a custom feature doesn't pass this test, it stays a gravel road or it gets deprecated entirely. Okay, let's explore those four dimensions because this is where the rubber meets the road for anyone trying to run this playbook. Pun intended. Always. So dimension number one is reusability. Is this just a bizarre quark for one specific customer or do enough customers share this exact pain point to justify generalizing it for the broader market. Evaluating reusability sounds simple, but it really requires deep market intuition. Move though. We'll say an FDE builds a gravel road to handle a highly specific convoluted way, a particular German automotive manufacturer formats its supply chain PDFs. Okay, very specific. The committee has to ask, is this one company just eccentric or does this format represent a broader European regulatory standard that 20 future enterprise prospects are also going to demand? But wait, if I'm on this committee, how do I actually measure that? Because if an FDE has been three weeks building this PDF parser, they're going to lobby hard for it to get paid so they don't have to maintain it anymore. Oh, they definitely will. Is there a trap here where FDE's exaggerate the broader market need just to offload their own maintenance burden onto the platform team? That is exactly why the committee includes platform leaders and product managers, not just FDE's. Ah, checks and balances. Right. The FDE has an inherent bias. They want their gravel road paved so their pager stops going off at 2 a.m. Naturally. The committee has to demand evidence. Not just, I think other customers want this, but here are three other active deployments where this exact same gravel road would reduce our time to value by two weeks. And if they can't prove that. If it's truly a one-off quirk, you leave it as a gravel road. The FDE maintains it for the life of that specific contract and the platform team is shielded from the bloat. Okay. So say a feature passes the reusability test. We know multiple customers want it. Dimension number two is differentiation. This one is huge. Does paving this gravel road give our platform a unique competitive edge in the market? Or is it a commodity feature that just distracts our engineers? This dimension is literally the graveyard of countless AI startups. Why? Confuse things the customer asks for with things that make our company valuable. Let's use a hypothetical to ground this. Imagine you're selling a highly advanced AI tool for predicting supply chain disruptions. A massive retail customer comes to your FDE and says, "Our team loves the predictive dashboard. But we really need a basic chat interface built into the app so our logistics managers can message each other without switching tabs." Yeah, that's all the time. So the FDE builds a quick gravel road chat tool. This customer wants it, it's highly reusable. But does a chat feature make your core AI supply chain products smarter? No. Right. Does it create a defensible moat against your competitors? No. You've just burned engineering cycles, building a generic slack clone inside your logistics tool. Exactly. Anyone can copy that. Yeah. You have gained zero competitive advantage. But you have successfully forced your core, highly paid AI engineers to maintain a messaging app for the next 10 years. And that's why the committee must have the discipline to look at a highly requested reusable feature and just say, "No." Just say no to the customer. Yeah. We're not paving this. The customer can use an off-the-shelf communication tool for that. We are dedicating our platform engineers strictly to features that compound our unique AI advantage. Love that. Okay. Dimension number three is platform fit. Does this field-tested gravel road actually align with our core system architecture? Or would we have to break the fundamental design of the platform just to force it in? This is an unyielding technical filter. Out in the field, an FDE might do something incredibly clever like a real MacGyver move to bypass a limitation in the customer's firewall. Right. It works flawlessly as a gravel road. But it completely violates the security paradigms and data flow of the home office platform. If you try to jam that clever hack into the core platform, you introduce structural instability for every other customer. Exactly. Shimoda points out that it is perfectly acceptable for a gravel road to remain a permanent customer-specific extension. It can live outside the core platform forever. And it requires immense maturity from engineering leadership to accept that outcome. You don't have to assimilate every brilliant idea into the mothership if it doesn't fit the architectural mold. Which brings us to the fourth and final dimension. Cost. The cold, hard engineering math. The committee has to weigh the massive upfront capital required to pave this feature into a superhighway against the ongoing long-term operational cost of having FDE's manually maintain that gravel road week after week. It's a localized return on investment calculation. But it requires brutal honesty about maintenance overhead. Like how much time the FDE's actually spending on it? Right. The gravel road is relatively stable and the FDE only spends, you know, one hour a month checking on it. The ROI to pave it might not be there. But what if it's constantly breaking? If that gravel road breaks every time the customer updates their database and an FDE is losing 10 hours a week patching it, that is a cripplingly expensive gravel road. It becomes cheaper to have the platform team spend a month paving it properly. So the productization decision filters through reusability, differentiation, platform fit, and cost. I want to emphasize the overarching danger here. Paving everything is into strategy. It's a surrender. If the platform team says yes to every gravel road, you don't get a beautiful superhighway. You get a bloated, unnavigable parking lot. A parking lot that's a great visual. The core code base becomes this Frankenstein's monster of ultra-specific toggles and features that only one or two customers actually use. And feature velocity slows to a crawl, right? Because every new update breaks three obscure legacy features. Exactly. It's the death of agility. The committee is the immune system protecting the core platform. But here's where the theory hits a massive practical wall. A committee cannot make these nuanced life or death product decisions without flawless, high-resolution data. No, they can't. How does the messy chaotic reality of the operational field actually make its way back to these isolated platform engineers sitting in their pristine headquarters? If the committee is making decisions based on second-hand assumptions or vague Slack messages, the outer loop is already broken. The data has to be systemic. That transitions us perfectly into Shemotus mechanisms for bridging the gap. He outlines four distinct formal feedback channels that must exist to make this loop function. Without these channels, the FTEs and the platform team are essentially speaking two different languages while working for the same company. So the first channel is the engagement retrospective. I need to stress that this is not a casual 15-minute chat over coffee, where everyone says good job and goes home. This is a rigorous, formal, written document produced after every major milestone in a deployment. It details what worked, what spectacularly failed, and critically, it captures what Shemota calls domain secrets. Yes. What exactly constitutes a domain secret in this context? Okay, so when an FTE embeds with a massive enterprise customer for three months, they learn the unwritten rules of how that business actually operates. The stuff that isn't in the manual. Exactly. They learn things that the customer's own C-suite executives often don't know. Give me an example. Well, the executive thinks the bottleneck is the legacy database. The FTE discovers the real bottleneck is that Brenda, in accounting, physically prints out the invoices, checks them with a red pen, and only approves them on Thursday afternoons. Brenda is the actual operational constraint. Brenda is the constraint. If the FTE doesn't write that reality down in a structured retrospective, what happens? The platform team back at HQ looks at the data, makes a logical assumption, and builds a blazing, fast, real-time, invoice processing engine. Which sounds great. They ship it, and it fails completely upon deployment because it doesn't account for Brenda's red pen and her Thursday schedule. The written retrospective forces the tacit on the ground knowledge out of the FTE's head, and translates it into a format the platform team can consume and analyze before they build. The second channel is FTE tooling requests. This is vital to separate from customer future requests. Very important distinction. This is the FTE saying, "Hey, platform team, forget about the customer for a second." I spend four hours every single Tuesday doing this one mechanical, mind-numbing task just to set up the customer's data pipeline. Can you build an internal tool that automates my job? And building tools for the FTE's is often the highest leverage investment a platform team can make. Really? More than building for the customer. Yes. If you automate a major friction point for your FTE's, you instantly accelerate every current and future deployment across the entire company. You're not just building roads, you're building better excavators for the road crews. Exactly. It radically shifts the unit economics of the deployment. The third channel Shimoda outlines involves regular sync meetings. He specifies weekly 30-minute meetings between the FTE pods and the core platform team. But he draws a massive line in the sand regarding the agenda. Which is. These meetings are strictly for coordination, not for reading status updates. We've all suffered through meetings where someone just reads down a list of gira tickets. Oh, it's the worst. For anyone unfamiliar, Gira is a ubiquitous project management tool engineers used to track bugs and tasks. If your cross team meeting consists of reading a gira board out loud, you are incinerating company time. So what does actual coordination look like between field and HQ? That's the question. Coordination is proactive pattern matching. The FTE team says. As we're seeing a weird trend, three different banking clients in Europe have suddenly asked for this specific security audit trail in the last two weeks. Is something shifting in EU regulation? All this smart. Simultaneously, the platform team uses that time to warn the field. We are deprecating a major architecture component next month. It is going to break the gravel roads you built for clients x and y. You have three weeks to migrate them. It's about identifying collisions before the car is actually crash. It's active alignment. Which brings us to the fourth feedback channel. And honestly, the one that sounds the most intense and disruptive. Field rotations. Yeah. This one is tough. Shimota argues that FDE should regularly spend sprints embedded on the platform team at HQ. And platform engineers need to pack their bags and embed out in the field on messy FDE engagements. If we connect this to the bigger picture, this is the channel that executives always try to cut to save money. Because it's expensive to fly people around. Exactly. But it is the channel that prevents the company from tearing itself apart. This isn't just about cross-training engineers on different code bases. It is about the forced transfer of empathy. I love that you brought up empathy because, let's be honest, typical engineering cultures aren't exactly famous for prioritizing emotional intelligence in their operating models. Why is empathy a business imperative here? You have to look at the natural human psychology and the incentive structures at play. The FDE in the field is under staggering pressure. They have a frustrated customer breathing down their neck demanding a solution yesterday. Right. They look at the platform team back at HQ and think those guys are living in an ivory tower, sipping kombucha, and building theoretical features that take six months while my customer is on fire. And the platform engineer's perspective is the exact opposite. Totally. The FDE and think that cowboy is writing terrible, undocumented code, breaking my pristine architecture and promising the customer features we haven't even scoped yet. Without intervention, it is a recipe for total tribal warfare. Two camps just hating each other. The two teams become inherently hostile toward each other. But when you mandate a physical rotation, everything changes. How so? When a senior platform engineer has to sit in a windowless conference room in Ohio for three days, getting yelled at by a logistics manager because the data pipeline failed. They suddenly understand exactly why the FDE makes those quick, expedient choices. They feel the pain of the gravel road. Yes. And when the FDE has to sit at HQ and maintain the core code base, they realize how incredibly fragile the entire system becomes when someone tries to force a messy, undocumented hack into the core architecture. The rotation strip away the caricatures. They build the mutual respect required for the outer loop to actually function when things get stressful. The human element is literally the glue holding the technical architecture together. Absolutely. But let's pivot slightly because empathy and communication are warm and fuzzy. But in enterprise AI, we're dealing with multi-million dollar contracts. Good vibes don't guarantee delivery. How do you enforce actual rigorous accountability between these two teams so that misdependencies don't derail a massive deployment? Because the failure mode is severe. If the FDE promises the customer a capability based on the platform roadmap and the platform team misses their deadline, the deployment stalls, the customer churns, and the company bleeds revenue. Shemota solves this with a mechanism called the platform commit. The platform commit. This is a formal, written agreement established at the very start of a customer engagement. It details the exact platform capabilities the FDE will rely on complete with strict service level agreements or SLA's. For listeners outside of enterprise tech, an SLA is basically a binding operational guarantee. It dictates the required uptime, performance, and accountability for a piece of software. In this context, it acts as an internal contract. It says we, the FDE team, are committing to delivering this specific business outcome for the customer. But we can only achieve it if you, the platform team, commit to delivering these specific APIs, these ways for our software to talk to yours by these specific dates. It completely eliminates the ambiguity that plagues so many deployments. It stops the FDE from selling vaporware the customer because they can only promise what the platform team has formally committed to. And it forces the platform team to prioritize features that are directly tied to active revenue rather than theoretical improvements. It aligns the engineering roadmap with the commercial reality. Here's where it gets really interesting. How do we mathematically prove to the board or to investors that this whole complex outer loop system is actually working? The metrics. Right. How do you prove you're gaining leverage? Shimoto lays out four core metrics. These metrics are the heartbeat of your economic health. If you are a founder listening to this right now and you're looking at your burn rate wondering why your margins are shrinking despite signing new clients, these are the dials you need to be looking at. These four metrics are the ultimate shield against the CFO who accuses your AI startup of secretly just being a glorified IT consulting firm. And that is the existential threat for any company running a forward deployed model. Are you a high margin software business? Or are you a low margin services firm wearing an AI trench coat? Wearing an AI trench coat? I love that. Yeah. Let's look at the math that proves you are a software company. Number one, the platform promotion rate, okay, this asks, what percentage of engineering hours spent building gravel roads in the field actually gets paved into the core platform within four quarters? The mechanism here is critical. If you have a team of FTEs building thousands of hours building custom pipelines and 0% of that code ever makes it back to the platform, you are a consulting firm. You're doing custom work for individual clients and throwing it away. But if that promotion rate is high, your field work is compounding. Exactly. You are taking a feature or one customer paid you to figure out and turning it into a product you can sell to your next 50 customers at zero marginal cost. metric number two is the engagement cost trend. Over a rolling four quarter period is the average engineering cost per new engagement dropping. Kick about the operational reality of this. The very first time you deploy your AI to a massive hospital network, you have to build all the data plumbing from scratch. It takes thousands of FTE hours. It's incredibly expensive. But because your outer loop is functioning, that plumbing gets promoted and paved into the core platform. So the next time you sell to a hospital, the plumbing is already there. The FTE just has to configure it. The cost to deploy that second hospital plummets and the third is even cheaper. If that line on the graph isn't trending down over time, your outer loop is broken and your margins will never improve. You are losing the compounding leverage that justifies hiring expensive FTEs in the first place. metric number three, the reusable asset ratio. What fraction of the code shipped in any given engagement is core platform code versus custom FTE code. This gives you a snapshot of a single deployments health. You want the vast majority of the deployment, the heavy lifting, the security, the core logic to be driven by the generalized platform and the custom code. The custom FTE code should only be a very thin layer at the very top. Just enough to handle the absolute last mile specifics of that client's environment. Because if an engagement is 80% custom code and 20% platform code, you are back in the consulting trap. You want your engineers pulling tools off the shelf, not smelting the iron to build the tools from scratch every time. And finally metric number four, platform feedback velocity. This one is about speed. How many weeks in Shimoto's very specific, he says, weeks, not months does it take from identifying a critical improvement in the field to actually shipping it in the core platform? This measures the latency of your entire organization. If an FTE identifies a critical flaw and the platform team takes six months to scope it, prioritize it, and fix it. Your outer loop exists on paper, but not in reality. Because what happens in the field during those six months? The FTE isn't just going to sit there until the customer to wait. So FTEs are impatient pragmatists by nature. They have a furious customer in front of them. If the platform feedback velocity is slow, the FTE will bypass the loop entirely. They will build a hacky, undocumented work around, a terrible gravel road, just to solve the immediate problem. And once they bypass the loop, you lose the institutional knowledge. You lose the clean architecture and you lose the compounding leverage. So those form metrics, promotion rate, cost, trend, asset ratio, and feedback velocity. Those are the vital signs of a healthy enterprise AI company. They absolutely are. OK, let's assume the system is working perfectly. The FTE identified a need. They built a gravel road, the productization committee reviewed it based on the four dimensions. They decided to pay of it. And the platform team has successfully built the new, shiny, super highway. The dream scenario. The capability now officially exists in the core platform, but here's the terrifying part. You have a customer actively running their business on the old, rickety, gravel road. Right. How do you swap them over to the new highway without crashing their entire operation? It is the equivalent of trying to replace a car's engine while it is driving down the highway at 70 miles an hour. It is incredibly high risk. Shimoda describes this transition as the two team handshake. He says it must be treated as a highly celebrated operational ritual and it requires three mandatory components to execute safely. Component one. The first component is the platform team certification. It is a documented, rigorously tested, and SLA committed proof that the new capability actually works and can handle the specific load the customer requires. The platform team has to formally, publicly take ownership. They are saying, we own this code now. If it breaks at 3 a.m. on a Sunday, our pages go off, not the FDE's. - That is a massive shift in liability. - It is. - The second component is the FDE migration plan. This is the FDE's written promise, complete with a strict timeline, to move the customer's data and workflows over to the new capability and permanently retire the old gravel road. - That last part is vital. You cannot allow the FDE or the customer to keep the gravel road running just because it's comfortable or familiar. - It has to be ruthlessly deprecated and destroyed. - Otherwise, you end up with shadow infrastructure consuming resources in the background. - Burn the boats, you force the transition. - Exactly. - And the third component of the handshake is the retrospective. This is a joint meeting between the FDE's and the platform team, asking one crucial, metal level question. What could we have done differently in the interloop to make this painting process easier? - They're debugging the organizational process itself, not just the code. - Did the FDE document the initial requirements poorly? - Did the platform team misjudge the testing timeline? It's about constant improvement. - I want to dig into a specific word Chamota uses here. He emphasizes that this handshake must be a celebrated ritual. - Yes. - Why is a party necessary? Why not just close the juror ticket, send a slack thumbs up and move on to the next task? - Because an engineering culture, handing off the maintenance of a complex system is almost always a point of intense bitter friction. - Friction, how so? - The FDE often suffers from a sort of creators bias. They don't want to let go their baby and they secretly don't trust the platform team to run it correctly. Meanwhile, the platform team often resents inheriting this weird bespoke concept that originated in the muddy reality of the field, rather than their clean architectural roadmap. - Nobody wants to clean up someone else's mess and nobody wants to hand their prize project over to a stranger. - Exactly. By mandating a celebrated ritual, leadership is artificially aligning the cultural incentives of both teams. - You are publicly declaring that this handoff is the ultimate victory condition for the entire company. - The FDE is celebrated and recognized for uncovering a capability so valuable that it literally changed the core product. - And the platform team is celebrated for successfully scaling that capability to handle enterprise loads. - You have to manufacture that cultural alignment where human nature will inevitably cause the teams to fight each other during the transition. - You have to proactively reward the behavior you want to see. That makes profound sense. - It does. - Which brings us inevitably to the dark side of all this. We've built this beautiful, perfectly balanced system on paper. The metrics make sense, the handshakes are celebrated. But when corporate pressure, tight deadlines and human nature take over, how does the outer loop actually fall apart in the real world? - And let me assure you, it does fall apart. It happens to the best companies. - Shimoda warns about three characteristic failure modes, which we can think of is the three deadly sins of the outer loop. - The three deadly sins, let's do it. - Let's break them down. Deadly sin number one is gravel road accumulation. - Okay. - In this scenario, the platform team essentially ignores the FDE's. Gravel roads multiply in the field without ever getting paved. - Symptoms of this are obvious. Maintenance costs skyrocket. The gross margins of the business absolutely tank. - And the FDE function eventually collapses under its own weight, right? - Yes, because the engineers are spending 80% of their time just fixing broken bespoke pipelines instead of deploying new value. - The FTE's basically devolve into highly paid, completely miserable janitors for their own legacy code. - Exactly, and they will quit. - So what's the mitigation for this? - The mitigation for this, according to Shimoda, is imposing strict, unyielding caps on unpaved roads. - Caps. - The company leadership simply has to refuse to allow an FDE pod to build new gravel roads for a customer if they are currently caring too much unpaved technical debt. - Wow, it forces a hard conversation at the executive level. - It does. - If the FTE's hit their cap, the company either has to allocate platform resources to pave some roads, or they have to accept that they cannot take on new custom engagements. You cannot just keep piling on debt. - Deadly sin number two is the exact opposite problem, platform capture. - Platform capture. In this scenario, the platform team treats the FDE gravel roads as their literal unquestioned product roadmap. - They abandoned the productization decision rubric entirely. - And just pave everything that comes in from the field. - The platform team abdicates their strategic responsibility. They stop thinking about the broader market architecture and just become an order-taking factory for whatever the loudest FDE demand. And the result of that is catastrophic. - Total bloat. - The platform becomes a bloated, incoherent Frankenstein's monster of ultra-specific features that no single customer actually needs in its entirety. - It becomes impossible to navigate. Incredibly difficult to sell to a general market and a nightmare to maintain. - The mitigation here relies entirely on the discipline of the committee, I assume. - Yes, they must strictly adhere to the four productization dimensions and have the backbone to tell the FDE's no. And finally, deadly sit number three. Silent divergence. - Oh, this one is tough. - This is where the teams just stop talking to each other in any meaningful way. The formal channels, the weekly sinks, the retrospectives they remain on the calendar, people show up, but the trust is completely gone. - It's purely a performative. - FDE starts shipping road-goat in the field without telling anyone, 'cause I think the platform team is too slow. - And the platform team starts shipping theoretical irrelevant features that nobody in the field asked for because they think the FBEs are incompetent. - They become two ships passing in the night, working for the same logo, but building entirely different products. - The mitigation for silent divergence cannot be a new bureaucratic process. No, it requires intense direct leadership intervention. The CEO or CPO has to step in, knock heads together, and force the teams back into alignment because no juror workflow can fix a fundamental breakdown in human trust. - I wanna pose a question to you based on your experience. - Sure. - Of these three deadly sins, gravel road accumulation, platform capture, and silent divergence. Which one is the most insidious? Which one sneaks up on a company and kills it before the executives even realize they are dying? - This raises an important question, and I would argue that platform capture is the deadliest of the three, precisely because it completely masquerades as success. - Walk me through the psychology of that. - How does destroying your platform look like success? - Think about the internal optics and the Dowling or Dmetrics during platform capture. The FDEs are thrilled because the platform team is building exactly what they ask for, exactly when they ask for it. The platform team feels incredibly productive because they are constantly shipping features with guaranteed internal users. They never build something that goes unused. - So the executive dashboard show blazing fast feature velocity. - Exactly, everyone is high-fiving in the all hands meeting. - Everyone feels like they're winning the game. - But externally, structurally, they are actively destroying the company's competitive mode. - Because it's too specific. - Yes, they are building a product that is so hyper tailored to the idiosyncratic needs of their existing three or four big legacy customers that it becomes completely unsalable to the rest of the market. - So the sales team goes out to pitch a new prospect and they can't explain the product because it's too complex and full of weird bespoke logic. - Right, logic that only makes sense if you are that one specific legacy client. By the time the executive team realizes the platform has become a bloated, unscalable mess, the architecture is ruined. - It is insidious because it looks and feels like high performance right up until the exact moment. Gross completely stalls out and the company hits a wall. Wow, that is a terrifying operational dynamic. You are sprinting at full speed in the wrong direction, celebrating every step and you don't realize it until you run out of road. - It happens more often than you'd think. - Okay, let's bring this all together for you, the listener. To briefly recap the journey of chapter nine, the outer loop is the ultimate engine of compounding leverage. - It is. - It is the sole mechanism that transforms a grueling, low margin, one off consulting gig into a scalable, highly profitable software empire. You build a messy gravel road in the field to prove the immediate economic value. - You evaluate it rigorously with the productization committee. - And if it passes the test, you pave it into a super highway that benefits every single future customer you sign. - It is the operational discipline that separates the AI startups that will survive and dominate from the ones that will burn through their venture funding and quietly vanish into a fire sale. - It really is the blueprint for survival. Now, to leave you with a final, slightly mind-bending thought to ponder as we wrap up. - Oh, this is a good one. - Throughout the book, Shimoda drops hints about this rapidly emerging concept of AI FTEs. - AI-forward deployed engineers. - Yes, these are agentic AI tools that actually automate the manual coding, the data plumbing, and the integration work that human FTEs are currently doing in the field. - So the AI is essentially writing the gravel roads itself, instantly reacting to the customer's environment. - Right, but let's extrapolate that out into the future. - Okay. - If AI agents eventually start building all the gravel roads in the field, and they start automatically analyzing the usage data on those roads, how long until an AI sits on the productization committee? - Oh, wow. - Who ultimately decides what gets paved into the core platform when the machines are the ones blazing the trails and gathering the intelligence in the field? - That is the very edge of the frontier we are racing toward. and the AI becomes both the explorer in the field and the architect at headquarters, the human role shifts entirely from builder to editor. - Something fascinating and slightly terrifying to mull over as you watch this space of all. Well thank you the listeners directly for tuning into this deep dive today. We really appreciate you spending this time with us and engaging with these complex ideas. - Thanks for joining us. - As a reminder, today's incredible insights, specifically covered chapter nine. That content is from the book called, "The Forward Deployed Engineer" by Sho Shimoda from Amazon. If you are interested in these contents and would like to know more, please purchase the book and tell others about it. - It's definitely worth a read. - And finally, please follow, like, leave comments and tell friends to spread knowledge to the next software engineering generation. See you next time.