Fast Time To Market
In the early 1990s, lateralworks conducted an extensive multi-company study involving over 500 people who worked on fast-to-market projects in Silicon Valley. Since then, they have worked with hundreds of teams to accelerate the delivery of new technology products to market. The research continues today to keep the best practices current.
This podcast series will share many of the practices that teams use to deliver the right product to the market at the right time.
Fast Time To Market
Triads for faster product development execution
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
The discussion on the FTTM podcast delves into the Triad Model for faster product execution, based on lateralworks research. The model addresses the "ownership gap" and functional silos in traditional corporate structures by introducing a flat, three-person product ownership team: the End-to-End Owner, Process Owner, and Design Owner. These roles work in real-time collaboration to ensure seamless product development. The Technical Program Manager (TPM) drives execution using practices like "schedule as driver," "macro-micro planning," and "assume acceleration." The Product Delivery Team (PDT) model scales this approach across multiple product lines, emphasizing trust and speed over control. The Freedom Scale measures empowerment levels, aiming for level one (act, routine, reporting only) for most decisions.
Welcome back to the FTTM Podcast, your guide to getting the right product to the market at the right time. This week, we're going to focus on FTTM planning, how to execute to achieve right time.
SPEAKER_01Glad to be here for this one.
SPEAKER_00Yeah. And just to set the stage immediately for everyone listening, uh FTTM stands for Fast Time to Market.
SPEAKER_01Right.
SPEAKER_00And, you know, welcome to the deep dive. Because today, our mission is to explore these groundbreaking structural models for product teams, and we're basing this entirely on LateralWorks research and uh lateral works best practices.
SPEAKER_01Aaron Powell Which is such a massive paradigm shift.
SPEAKER_00Oh, it really is. I mean, for anyone who has ever felt completely bogged down in corporate bureaucracy or you know, maybe watched a huge product launch, just stall out because of endless approvals.
SPEAKER_01Death by a thousand approval.
SPEAKER_00Exactly. This deep dive reveals exactly how high-speed technology organizations completely restructure themselves. You know, how they strip away the red tape to dramatically accelerate product delivery. Trevor Burrus, Jr.
SPEAKER_01And that acceleration is everything right now.
SPEAKER_00Right. So here is our roadmap for the discussion. We're going to explore the transition from a really slow uh kind of research culture to a fast product culture.
SPEAKER_01Crucial step.
SPEAKER_00Then we'll unpack the revolutionary go-to-market triad model. We're going to decode the freedom scale of organizational empowerment, which is fascinating, and finally learn the exact planning mechanics that drive actual execution.
SPEAKER_01It's a packed agenda.
SPEAKER_00It is. But before we get to the solution, you know, be before we understand how to fix it, we have to understand why traditional corporate structures fail so spectacularly at fast execution.
SPEAKER_01Aaron Powell Yeah, we have to diagnose the disease first.
SPEAKER_00Aaron Powell Exactly. And the core problem, according to the lateral works research, is this thing called the ownership gap.
SPEAKER_01Right.
SPEAKER_00And uh these functional silos. Aaron Powell Right.
SPEAKER_01The functional silos, it's the standard way almost every legacy tech company is organized today.
SPEAKER_00Aaron Ross Powell So to visualize this for you listening, I want to use an analogy. Think of a traditional functional organizational model like a relay race.
SPEAKER_01Okay, a relay race.
SPEAKER_00Yeah. But imagine a relay race where every single runner is absolutely obsessed with running perfectly in their own specific lane.
SPEAKER_01Aaron Ross Powell Oh, I see where this is going.
SPEAKER_00Aaron Ross Powell Right. Like they have perfect form, perfect breathing.
SPEAKER_01Yeah.
SPEAKER_00But literally, no one is assigned to hold the baton.
SPEAKER_01Aaron Ross Powell No one is watching the baton.
SPEAKER_00Exactly. No one is watching the baton.
SPEAKER_01Aaron Ross Powell That is uh honestly the perfect way to describe a research-oriented functional culture. Because what the Lateral Works research found is that in these legacy companies, people are organized completely by their discipline.
SPEAKER_00Aaron Powell Like departments.
SPEAKER_01Right. Big departments. You have a giant silo for process engineering, you have another one for design, uh, another for qualification.
SPEAKER_00Right. Supply chain.
SPEAKER_01Supply chain, exactly. And this model actually works really well for planning or for pure research.
SPEAKER_00Because you're just deep diving into one specific thing. Aaron Powell Yeah.
SPEAKER_01If you want 50 PhDs to just sit around and theorize about new materials with no deadline, silos are great.
SPEAKER_00But for execution.
SPEAKER_01For execution, it completely fails. It is a disaster. Because when you're trying to execute and actually build a product, trade-offs start piling up.
SPEAKER_00Right, because things get messy.
SPEAKER_01Very messy. Decisions are delayed because they have to get routed up one vertical silo, cross over at the VP level, and go down another silo. And that creates what the lateral works best practices call the ownership gap.
SPEAKER_00The ownership gap.
SPEAKER_01Yeah, because there is no single person who owns a product end-to-end from its conception all the way to delivering it to the customer. Wow.
SPEAKER_00Nobody actually owns the product.
SPEAKER_01Aaron Powell Nobody. The symptom you see, and it's so common, is that engineers identify with their technology or their functional silo rather than the customer outcome.
SPEAKER_00So they don't say, I'm building the new smartphone.
SPEAKER_01Aaron Powell No, they say I'm a thermodynamics engineer.
SPEAKER_00Right.
SPEAKER_01Or uh I am a memory circuit designer. Their identity is their function, not the product they're helping to create.
SPEAKER_00Aaron Powell Well, let me push back on this a little bit just to play devil's advocate. If everyone in that company is highly specialized, right? They're brilliant people, and they're doing their specific functional job perfectly, shouldn't the product just naturally come together at the end?
SPEAKER_01Aaron Powell That's the logical assumption.
SPEAKER_00Aaron Powell Yeah, like an assembly line.
SPEAKER_01Right. But product development, especially in high-tech, is not linear. It's not an assembly line. It is this massive, complex web of dependencies.
SPEAKER_00Aaron Powell So perfection in one lane doesn't equal a perfect product.
SPEAKER_01Exactly. Without a central integrator, conflicting priorities between departments cause silent schedule slips.
SPEAKER_00Silent slips, meaning nobody knows it's happening.
SPEAKER_01Aaron Powell Right. Because the process team thinks they're doing great, the design team thinks they're doing great, but their work is completely incompatible. And it causes these massive late-stage integration disasters.
SPEAKER_00So they finally bring the pieces together at the end of the year and nothing fits.
SPEAKER_01And then you miss your market window. So the silos are fatal to fast time to market.
SPEAKER_00Aaron Powell Okay. So that brings us to section two, the antidote.
SPEAKER_01Aaron Powell Yes, the cure for the ownership gap. Trevor Burrus, Jr.
SPEAKER_00Which lateral works best practices introduce as the go-to-market triad model.
SPEAKER_01Aaron Powell Right, the triad.
SPEAKER_00It's a radically flat, completely product accountable structure. It's designed specifically to force speed and force lateral information flow.
SPEAKER_01Aaron Powell It forces people to look at the baton.
SPEAKER_00Exactly. So unpack the anatomy of this triad for us. What is it?
SPEAKER_01Aaron Powell So the Go-to-Market Triad is essentially a three-person product ownership team, and they are completely focused on one specific product family.
SPEAKER_00Aaron Powell So they aren't bouncing between 10 different projects.
SPEAKER_01No, zero context switching. And the design principles here are critical. First, it is flat, not hierarchical.
SPEAKER_00Aaron Powell Meaning no one is the boss.
SPEAKER_01Exactly. There are no internal reporting lines within the triad. All three roles are peers, and their new identity is the product, not their function. Aaron Powell Okay.
SPEAKER_00So let's break down the three roles. Who is the first person in the triad?
SPEAKER_01Role one is the end-to-end productization owner or the E2E owner.
SPEAKER_00Aaron Powell The E2E owner. Okay.
SPEAKER_01You can think of them as the product boss or the system architect.
SPEAKER_00Aaron Powell But wait, you just said they aren't the boss. Aaron Powell Right.
SPEAKER_01They aren't the HR boss. They don't write the performance reviews for the other two, but they are the boss of the product vision.
SPEAKER_00Aaron Powell Oh, okay. That makes sense.
SPEAKER_01Aaron Powell They maintain the integrated view across all the dependencies. They act as the internal voice of the customer.
SPEAKER_00Aaron Powell So they represent the person actually buying the thing.
SPEAKER_01Exactly. And because of that, they make the ultimate start, stop, or continued decisions for the product. Aaron Powell Okay.
SPEAKER_00So that's the E2E owner, the visionary, who is role number two.
SPEAKER_01Aaron Ross Powell Role two is the process owner.
SPEAKER_00Trevor Burrus Process owner.
SPEAKER_01Yeah. This is your deep technical expert in manufacturing and process integration.
SPEAKER_00Aaron Powell So they're the ones on the factory floor.
SPEAKER_01Basically, yeah. They own the baseline. And they own what the Lateral Works research calls aggressive yield learning cycles. Aaron Powell Okay.
SPEAKER_00Aggressive yield learning cycles. Break that down for me.
SPEAKER_01It means they must provide daily data on how the manufacturing is going. They never ever wait for quarterly reviews. Daily data.
SPEAKER_00Wow.
SPEAKER_01Yeah. If a machine is spitting out bad parts at noon, they are analyzing it at one o'clock and tweaking the process by three.
SPEAKER_00Aaron Powell No hiding until the end of the month.
SPEAKER_01Exactly. Constant brutal reality checks.
SPEAKER_00Aaron Powell Okay. So we have the E2E owner with the vision, the process owner with the physical reality. Who is the third role?
SPEAKER_01Role three is the design owner.
SPEAKER_00The designer.
SPEAKER_01Right. Their job is to translate the customer performance specs, which the E2E owner gives them into actual physical designs.
SPEAKER_00Sounds standard so far.
SPEAKER_01But here is the magic of the triad. The design owner works in continuous real-time partnership with the process owner.
SPEAKER_00Real-time?
SPEAKER_01Yes. They work together to define design margins. And the rule is if the process owner sees a shift in the manufacturing process, the design owner must immediately assess the impact of that shift within 48 hours.
SPEAKER_0048 hours. That is incredibly fast.
SPEAKER_01It has to be. If the factory suddenly can't handle a certain heat tolerance, the designer can't weigh a month to redraw the plan. They have 48 hours to figure out how it impacts the design.
SPEAKER_00Aaron Powell, I love this. It's like a three-legged stool. But uh I have a question about this dynamic.
SPEAKER_01Sure, go for it.
SPEAKER_00If they are all peers, no HR boss in the room, what stops them from just arguing endlessly?
SPEAKER_01Aaron Powell That is the number one question executives ask when they see this model.
SPEAKER_00Aaron Powell Right. Because who breaks the tie when the process owner and the design owner want completely different things?
SPEAKER_01Aaron Powell Well, it's a brilliant system of checks and balances. The E2E owner keeps the customer in view. The process owner grounds everyone in physical realism, and the design owner holds the performance spec.
SPEAKER_00Okay, but when they clash.
SPEAKER_01When they clash, they do not escalate to their functional managers.
SPEAKER_00Aaron Powell Oh, they don't run back to the VP of design.
SPEAKER_01Aaron Powell Never. That would ruin the speed. The E2E owner resolves intra-triad conflicts by using the customer milestone as the ultimate judge.
SPEAKER_00The customer is the tiebreaker.
SPEAKER_01Exactly. The E2E owner basically says, look, if we go with the design owner's idea, we miss the customer deadline by two months. The customer cares more about time than this one feature. So we are going with the process owner's reality.
SPEAKER_00That is fascinating. The milestone is the judge. Okay, so we have these three leaders, but a triad is just three people. They need an engine to actually drive the timeline forward day by day for the hundreds of engineers under them.
SPEAKER_01Right. Three people can't do all the actual work.
SPEAKER_00Which brings us to section three, the execution engine. And this introduces a fourth essential player.
SPEAKER_01Yes, the technical program manager or TPM.
SPEAKER_00Now clarify this for the listener because when I hear program manager, I think of someone taking meeting minutes and coloring in Excel cells.
SPEAKER_01Right. The classic administrative product manager. The lateral works best practices are very explicit here. The TPM is a technical role, crucially technical.
SPEAKER_00Aaron Powell So they aren't just an admin.
SPEAKER_01Absolutely not. They own the how and when, while the triad owns the what and why.
SPEAKER_00Okay. So how do they actually drive this execution? What are the mechanics?
SPEAKER_01The TPM uses core lateral works FTTM practices. The first one is a concept called schedule as driver.
SPEAKER_00Schedule as driver, meaning the schedule is the boss.
SPEAKER_01Exactly. In a slow company, a schedule is just a reporting tool for senior management. You look at it once a month to see how late you are. But under FTTM, the schedule dictates the daily work. It drives every action. Aaron Powell Okay.
SPEAKER_00And how do they manage a schedule that big? A multi-year tech project is massive.
SPEAKER_01Aaron Powell That leads to the second practice: macro microplanning.
SPEAKER_00Aaron Powell Macro micro. So big picture and small picture.
SPEAKER_01Yes. The TPM maintains a live macro schedule, which has the big customer milestones alongside highly detailed micro schedules.
SPEAKER_00Aaron Powell And what counts as a micro schedule?
SPEAKER_01Aaron Powell A micro schedule is for near-term tasks that are strictly under 10 days in duration.
SPEAKER_00Under 10 days. So very tactical.
SPEAKER_01Highly tactical. You can't manage a two-year project by staring at a date two years away. You manage it by staring at a task due next Tuesday.
SPEAKER_00Aaron Powell That makes a ton of sense. It keeps the urgency high.
SPEAKER_01Aaron Powell, which ties perfectly into the third practice: know the gap.
SPEAKER_00Know the gap. What gap are we talking about here?
SPEAKER_01Aaron Powell The TPM explicitly calculates the gap between the target customer date and the real schedule that the team is currently on track to hit.
SPEAKER_00Oh wow. So they calculate exactly how far behind they are?
SPEAKER_01Yes. And they make this gap the central conversation at every single meeting.
SPEAKER_00They don't hide it.
SPEAKER_01They broadcast it. It generates what the research calls before-the-fact urgency.
SPEAKER_00Before the fact urgency. So you panic in March instead of panicking in November.
SPEAKER_01Exactly. You want the panic early when you still have time to fix it.
SPEAKER_00Aaron Powell Now, the next practice is one that really stood out to me. It's called assume acceleration.
SPEAKER_01Yes, assume acceleration.
SPEAKER_00And this is wildly different from typical corporate culture, right? Because normally people pad their estimates.
SPEAKER_01Oh, everyone pads their estimates.
SPEAKER_00Yeah. If a job takes five days, they tell their boss it takes ten just to avoid looking bad. So how does assume acceleration work?
SPEAKER_01It means the TPM expects the critical path to get shorter. They bank time when the team gets ahead, and they recover instantly when they fall behind.
SPEAKER_00But how do you get engineers to agree to that without demoralizing them?
SPEAKER_01Aaron Powell That's the secret sauce. The schedule must be built by the team for the team.
SPEAKER_00So it's not top-down.
SPEAKER_01No. If a VP hands down an arbitrary deadline, people will sandbag their estimates out of fear. But if the team builds the schedule bottom-up, they take psychological ownership of it.
SPEAKER_00Aaron Powell So they actually want to beat their own estimates.
SPEAKER_01Exactly. It replaces the fear of top-down deadlines with an internal drive to compress the timeline.
SPEAKER_00Aaron Powell That is brilliant. And the last TPM practice?
SPEAKER_01Eliminate interrupts. The TPM is systematically hunting down bottlenecks before they stall the team.
SPEAKER_00Aaron Powell Like late data or approval delays?
SPEAKER_01Right. The TPM acts like a snowplow, just clearing the road ahead of the triad so that engineers can just run.
SPEAKER_00I love that snowplow analogy. Okay, so we've got the triad and we've got the TPM snowplow, but this works great for one product. What happens when you scale this up?
SPEAKER_01Right, because most enterprises have dozens of product lines.
SPEAKER_00Exactly. This brings us to section four, scaling up and the product delivery team ecosystem or the PDT.
SPEAKER_01Yes. The PDT model is how you scale the triad concept across a massive enterprise with shared resources.
SPEAKER_00Aaron Powell So how is a PDT different from just a triad?
SPEAKER_01It's an expansion. The core team is led by a product delivery leader. That's basically your E2E owner. It's driven by a PDT program manager, your TPM, but then it's staffed by embedded leads.
SPEAKER_00Embedded leads. So these are experts from different functions who are embedded directly into the product team.
SPEAKER_01Exactly. They live and breathe the product context every day.
SPEAKER_00But if you have 20 PDTs running around, how do you manage the chaos? What if they all need the same testing lab on the same day?
SPEAKER_01That's why you introduced the program director.
SPEAKER_00The program director. Okay, where do they sit?
SPEAKER_01They sit above multiple PDTs. And their main job is to maintain the single source of truth, the integrated master schedule.
SPEAKER_00Aaron Powell So they are looking at all 20 PDTs at once.
SPEAKER_01Right. They surface cross-product resource contentions, like those shared fabrication facilities or testing hardware you mentioned.
SPEAKER_00So they practice that before-the-fact urgency at a macro level.
SPEAKER_01Exactly. But here is the absolute golden rule for the program director. They coordinate, they do not command.
SPEAKER_00Aaron Powell They coordinate, they don't command. Meaning they can't tell the PDT what to do with their product.
SPEAKER_01Aaron Ross Powell Exactly. They don't make technical decisions for the PDT, they just manage the traffic between them.
SPEAKER_00Okay, hold on. This brings up the elephant in the room.
SPEAKER_01The functional managers.
SPEAKER_00Yes. Because if I'm a functional manager, say the VP of design or the head of quality, and my people are now embedded leads taking direction from a product delivery leader, I'm basically losing control over what my people do every day.
SPEAKER_01You are. It is a massive cultural shift.
SPEAKER_00How on earth do you get them to agree to this without a mutiny?
SPEAKER_01It is the biggest point of friction in adopting lateral work's best practices. But you have to face the truth. Functional hierarchy overriding product schedules is the number one cause of fragmentation.
SPEAKER_00It's the number one cause of delays.
SPEAKER_01Yes. So the PDT model demands a new rule. When there is a conflict between what is good for the function and what is good for the product, the product wins.
SPEAKER_00The product wins. That has to hurt a VP's ego.
SPEAKER_01It does. Under this model, the functional managers lose their power to direct daily work. Their job shifts entirely to provisioning talent, setting enterprise standards, and technical governance.
SPEAKER_00So they train the people, but they don't micromanage their daily tasks.
SPEAKER_01Exactly. Now, to prevent a total mutiny, functional managers do retain what is called a 20% veto.
SPEAKER_00A 20% veto? How does that work?
SPEAKER_01It means they can step in and veto a decision only if it violates a core enterprise standard like safety or critical quality baselines.
SPEAKER_00Okay, so they are the guardrails. Yes.
SPEAKER_01But for the other 80% of daily work, they must operate via dotted lines. They advise, but they don't dictate.
SPEAKER_00That is a huge structural change. But it all relies on trust, which leads perfectly into section five. Institutionalizing trust. Yes, the freedom scale. Because all of this structure collapses if people still feel like they have to ask for permission to do their jobs.
SPEAKER_01Exactly. To achieve fast time to market, you have to actually quantify empowerment.
SPEAKER_00And Lateral Works uses this diagnostic tool called the freedom scale. Can you unpack the levels for us?
SPEAKER_01Absolutely. There are five levels on the freedom scale measuring how empowered a person really is. Let's start at the top. Level one.
SPEAKER_00Okay, level one.
SPEAKER_01Level one is act, routine recording only.
SPEAKER_00Act, routine reporting only. So you just do it.
SPEAKER_01Yes. You see a problem, you make a decision, you take action, and you only mention it to your boss during your normal weekly report. This is maximum speed. It's after the fact control.
SPEAKER_00I love that. Okay, what's level two?
SPEAKER_01Level two is act, but advise it once.
SPEAKER_00So you still take action immediately.
SPEAKER_01Right. But because it might have a cross-functional impact, you shoot off an email right away to let people know what you did.
SPEAKER_00Got it. Level three.
SPEAKER_01Level three is where things start slowing down. It's recommend, then act.
SPEAKER_00Recommend, then act. So, hey boss, I intend to do this unless you tell me no.
SPEAKER_01Exactly. It's before the fact control, you have to wait for the thumbs up.
SPEAKER_00Which introduced delays.
SPEAKER_01Huge delays. Then there's level four. Ask what to do. You bring the problem to your boss and say, How should I fix this?
SPEAKER_00And level five.
SPEAKER_01The absolute bottom. Wait until told. You do nothing until someone gives you an explicit order.
SPEAKER_00This is such a great framework. Because level one is like an experienced chef in a kitchen, right?
SPEAKER_01Oh, that's a great analogy.
SPEAKER_00Yeah, they just see a steak is done, they pull it off the grill, they serve it. They don't ask the head chef for permission to flip a burger.
SPEAKER_01Exactly.
SPEAKER_00But level five is like a brand new line cook waiting to be told exactly when to move their hands. You cannot run a fast-paced restaurant with level five cooks.
SPEAKER_01You'd go out of business. And the golden rule of the triad and PDT models is this the target state is level one for almost all product, process, and design decisions.
SPEAKER_00Level one for almost everything.
SPEAKER_01Well almost everything. Level two or three is reserved strictly for major things, like hiring or major capital expenditures, capex, or resolving massive cross-team resource wars.
SPEAKER_00But everything else is level one. That requires so much trust. Why don't people just naturally operate at level one, though?
SPEAKER_01That is the psychological trap identified in the lateral works research. The phrase they use is people disempower themselves by asking.
SPEAKER_00They disempower themselves. How?
SPEAKER_01Well imagine a brilliant engineer gets yelled at by VP once for making a decision. Next time, to protect themselves, they ask for permission. That's level four behavior.
SPEAKER_00And the boss thinks, oh, they need my help.
SPEAKER_01Exactly. So the boss starts dictating. And soon that brilliant engineer is operating at level five. They've learned to just wait until told. Wow. When experienced professionals operate at level four or five, it signals a structural problem in the organization, not a personnel problem. Trust produces speed, control produces slowness.
SPEAKER_00Trust produces speed, control produces slowness. I want to highlight that for the listener because that is the core of FTTM.
SPEAKER_01It absolutely is.
SPEAKER_00Okay, so let's move to section six. Diagnostics. How can a listener tell if their own company is genuinely executing this way or just using the buzzwords?
SPEAKER_01You have to look for specific signals. Let's start with the healthy signals.
SPEAKER_00Okay. What tells me the machine is actually working?
SPEAKER_01First, lateral information flow. Are process and design talking directly in real time? If yes, that's healthy, there should be no surprises at integration reviews.
SPEAKER_00Because they already figured it out laterally.
SPEAKER_01Exactly. Another healthy signal. Decisions are made inside the team without functional escalation.
SPEAKER_00Right. They don't run to the VPs.
SPEAKER_01Right. And for the TPM, the schedule is refreshed weekly and the critical path is always visible to everyone.
SPEAKER_00Okay. What about the team identity?
SPEAKER_01Huge signal. Team members identify as product creators, not just functional specialists.
SPEAKER_00Aaron Powell Okay. Those are the green lights. What are the warning signals?
SPEAKER_01Functional managers demanding approvals for daily trade-offs. That's pure level four or five behavior. Trevor Burrus, Jr.
SPEAKER_00The red tape is back.
SPEAKER_01Yeah. Also, if schedule surprises are emerging late in review meetings rather than proactively from the TPM, that's a massive warning signal.
SPEAKER_00Aaron Powell Means know the gap completely failed.
SPEAKER_01Exactly. Or if the E2E owner doesn't actually know the product status because information is trapped in vertical silos.
SPEAKER_00Aaron Powell That's a disaster. Now there's also a financial tracking element to this, right?
SPEAKER_01Aaron Powell Yes. The best practices discuss an activity-based costing mechanism. It's basically a quasi-PL tracking.
SPEAKER_00Trevor Burrus, Jr.: PL meaning profit and loss.
SPEAKER_01Right. Hours and costs are tied directly to the product team, not just a general department budget. It ensures strict financial accountability for the triad.
SPEAKER_00Okay, so let me ask you the ultimate question here. What is the absolute biggest red flag a listener should look out for on Monday morning? Like, how do they know their team is trapped in the slow zone?
SPEAKER_01The absolute biggest red flag is hearing someone say the phrase, let me check with my manager.
SPEAKER_00Oof. Let me check with my manager.
SPEAKER_01If peer-level experts cannot make real-time trade-offs together in a room, the system is fundamentally broken. It means you don't have an empowered team, you just have a room full of messengers.
SPEAKER_00A room full of messengers. Wow. That is such a powerful image. You've got these brilliant people, but they can't actually do anything without making a phone call first.
SPEAKER_01And while they are making that phone call, the competitor is taking market share.
SPEAKER_00This has been an incredible deep dive. We've gone from the disease of functional silos to the cure of the go to market triad. We looked at the TPM execution engine, scaling with PDTs, and unlocking everything with the freedom scale.
SPEAKER_01It's a complete rewiring of how a company operates.
SPEAKER_00Do you have a final provocative thought you want to leave the listener with? With to maul over?
SPEAKER_01I do. We talk a lot about the bottlenecks in technology development. People think the bottleneck is processing power or equipment or even finding the right talent.
SPEAKER_00Aaron Ross Powell Right, the hard constraints.
SPEAKER_01But the ultimate bottleneck in technology development isn't any of those things. It is the speed of internal human trust.
SPEAKER_00The speed of internal human trust.
SPEAKER_01Yes. If you are building a product, ask yourself is your organization chart designed to facilitate trust, or is it designed to facilitate control?
SPEAKER_00That is the million dollar question.
SPEAKER_01Because you can only have one at maximum capacity. You have to choose.
SPEAKER_00Are you designed for trust or designed for control? Amazing. Thanks for listening. Make sure to tune in next week where we will dive deeper into key practices of FTTM teams.
