Latest / Chief in Tech Deep Dive Shortcast / Chief in Tech S1E69 - Roopa Jayaraman : Platform Thinking in Action – Driving Product, People & Tech Alignment at Enterprise Scale

Transcript

Chief in Tech S1E69 - Roopa Jayaraman : Platform Thinking in Action – Driving Product, People & Tech Alignment at Enterprise Scale · Chief in Tech Deep Dive Shortcast

• 0:00
  Imagine adding like 50 top -tier engineers to
• 0:03
  your development team and your actual deployment
• 0:06
  speed drops by half. Right, which sounds completely
• 0:09
  backwards. It completely defies logic. You know,
• 0:11
  you threw money and talent at a bottleneck and
• 0:13
  the bottleneck just got wider, slower, and honestly
• 0:16
  incredibly expensive. Yeah. But it happens every
• 0:19
  single day in enterprise technology. We're looking
• 0:21
  at a phenomenon where the very act of growing
• 0:23
  basically becomes the anchor dragging an organization
• 0:26
  down. It is... It's the ultimate paradox of scale.
• 0:30
  I mean, the initial phase of any project or company
• 0:33
  is just exhilarating because the communication
• 0:35
  loops are incredibly tight. Yeah, everybody's
• 0:37
  in the same room. Exactly. You have an idea,
• 0:39
  you write the code, you ship it to the user.
• 0:41
  Boom. But as you add more microservices, more
• 0:44
  customer data pipelines, and more product features,
• 0:47
  the friction isn't additive. It's exponential.
• 0:50
  Well, today we are taking a deep dive into a
• 0:53
  brilliant session note titled Platform Thinking
• 0:55
  and Action, Driving Product, People, and Tech
• 0:58
  Alignment at Enterprise Scale. It's a great piece.
• 1:00
  It really is. It comes from Rupa Jayaraman, who
• 1:03
  is a chief technology officer and a recognized
• 1:05
  thought leader in the global B2B SaaS space.
• 1:08
  We have her frameworks and insights right in
• 1:11
  front of us. And our mission for you today is
• 1:13
  to basically cut through the corporate buzzwords.
• 1:16
  Because there are a lot of them in this space.
• 1:18
  Oh, for sure. We want to demystify what platform
• 1:21
  thinking actually means mechanically and how
• 1:23
  it acts as a catalyst for getting your organizational
• 1:25
  speed back. OK, let's unpack this. Because to
• 1:29
  understand why platform thinking matters, we
• 1:31
  first have to examine what the source calls the
• 1:33
  complexity trap. Right, the trap. Yeah. When
• 1:37
  an organization is small, it basically operates
• 1:39
  like a frontier tone. You have a few pioneers,
• 1:42
  right? If you need to get from your cabin to
• 1:44
  the river, you just walk in a straight line and
• 1:47
  trample the grass. Makes sense. That's your dirt
• 1:49
  road. It is highly efficient for, like, three
• 1:52
  people. But fast forward and 10 ,000 people move
• 1:55
  into that town. Yeah, the dirt road doesn't really
• 1:57
  work anymore. Exactly. If everyone is still building
• 2:00
  their own custom dirt road every single time
• 2:02
  they need to connect a new house to the water
• 2:04
  supply, the town just paralyzes itself in gridlock.
• 2:08
  The mechanical reality of that paralysis is what
• 2:11
  engineers affectionately refer to as dependency
• 2:14
  hell. Such a great term. It's painfully accurate.
• 2:19
  Let's say you have a feature team tasked with
• 2:22
  building a new checkout page. In a hyper -growth
• 2:25
  non -platform environment, they might literally
• 2:28
  have to custom build their own authentication
• 2:30
  protocol just to verify the user. Wow. Yeah.
• 2:33
  And their own integration into a payment gateway.
• 2:36
  and even their own database schema just to store
• 2:38
  the transaction. They are essentially paving
• 2:42
  a brand new dirt road from scratch. So they're
• 2:44
  reinventing the wheel. Exactly. Now, multiply
• 2:46
  that by 50 different product teams. Now you have
• 2:49
  50 different ways users log in, 50 different
• 2:52
  potential security vulnerabilities. Oh, that
• 2:54
  sounds like a nightmare for security. It is.
• 2:57
  And when the core payment provider updates their
• 2:59
  system, 50 separate teams have to stop whatever
• 3:02
  they're doing and rewrite their code. So the
• 3:05
  complexity trap isn't just that you have more
• 3:07
  code. It's the chaotic, undocumented coupling
• 3:11
  of all that code. Right. So the friction comes
• 3:14
  from everyone reinventing the wheel simultaneously
• 3:16
  and, you know, doing it slightly differently
• 3:18
  every single time. Which is why the solution
• 3:20
  is scaling with intent. Platform thinking is
• 3:22
  really this architectural shift from building
• 3:25
  discrete, isolated features to building a master
• 3:29
  grid. Okay, a master grid. Yeah, you stop paving
• 3:32
  dirt roads and you lay down foundational infrastructure.
• 3:35
  So a single, highly robust authentication service,
• 3:39
  a single secure payment router. So everyone just
• 3:41
  uses the same one. Right. You abstract all of
• 3:44
  that heavy lifting away from the individual feature
• 3:46
  teams. That way they can just plug their new
• 3:49
  application into the grid and focus entirely
• 3:52
  on creating unique value for the user. Here's
• 3:55
  where it gets really interesting. Because if
• 3:58
  the core principle of platform thinking is clearing
• 4:01
  up that dependency hell, we need to categorize
• 4:03
  what this actually looks like in the wild. Yeah,
• 4:06
  the practical application. Right. And the source
• 4:08
  breaks this down into three distinct models.
• 4:11
  Internal platforms, ecosystem platforms, and
• 4:15
  marketplace -driven platforms. Now, I'm going
• 4:17
  to push back here on behalf of you, the listener,
• 4:19
  because the word platform, it's dangerously close
• 4:23
  to losing all semantic meaning in the business
• 4:25
  world. Oh, totally. It's a massive buzzword.
• 4:28
  Right. Like, do we really need to slice this
• 4:30
  into three different models? When I hear platform,
• 4:32
  I just think of the underlying compute infrastructure
• 4:35
  like AWS or Google Cloud. Yeah, the hardware,
• 4:38
  basically. Yeah. So layering on internal ecosystem
• 4:42
  and marketplace feels like we might just be multiplying
• 4:45
  jargon instead of actually reducing complexity.
• 4:48
  That is a completely valid skepticism to maintain
• 4:51
  because the term is heavily heavily abused. But
• 4:54
  the reason the text deliberately separates these
• 4:57
  three models is that the architectural friction
• 4:59
  you're trying to solve changes radically, depending
• 5:02
  on who the actual user is. OK, so it's about
• 5:06
  the end user. Exactly. Let's look at the mechanics
• 5:09
  behind each one. So an internal platform, which
• 5:12
  is often called an internal developer portal,
• 5:15
  is entirely focused on cognitive load reduction
• 5:17
  for a company's own engineers. Got it. It basically
• 5:20
  operates like a self -service vending machine
• 5:22
  for infrastructure. If an internal developer
• 5:25
  wants to, say, spin up a new testing environment,
• 5:28
  they shouldn't have to submit a ticket to the
• 5:29
  IT department and wait three weeks for some manual
• 5:32
  approval. Nobody wants to wait three weeks. Right.
• 5:34
  So instead, they interact with the internal platform,
• 5:37
  press a button, and the system automatically
• 5:39
  provisions the server, sets up all the security
• 5:41
  guardrails, and connects the logging. The customer
• 5:43
  here is the employee. Oh, OK. So then we jump
• 5:46
  to the ecosystem platform. This is where a company
• 5:49
  opens its foundations to the outside world, right?
• 5:51
  Like an app store or a software company providing
• 5:55
  public APIs so other businesses can build integrations
• 5:58
  on top of them. Exactly. And what's fascinating
• 6:01
  here is the massive shift in governance required
• 6:04
  to actually execute that transition. Governance.
• 6:07
  Like rules and policies. Yeah, because when you
• 6:10
  move from an internal platform to an ecosystem
• 6:12
  platform, you basically surrender control over
• 6:15
  the developers using your system. Oh, because
• 6:17
  they don't work for you anymore. Precisely. Internally,
• 6:19
  if you push a fundamental change to an API, you
• 6:21
  can just mandate that your own teams update their
• 6:23
  code by frame. Right. You just send an email.
• 6:25
  But in an ecosystem platform, if you break an
• 6:28
  API, you instantly break hundreds of external
• 6:31
  businesses that rely on your infrastructure.
• 6:33
  Wow. Yeah, that's a huge liability. It's massive.
• 6:35
  So the mechanics of an ecosystem platform require
• 6:39
  extreme backward compatibility, really rigorous
• 6:42
  versioning, and flawless external -facing documentation.
• 6:46
  So it's a completely different beast. Totally.
• 6:48
  The engineering goal isn't just internal efficiency
• 6:51
  anymore. It's about creating a gravitational
• 6:53
  pull. You're designing a system that actively
• 6:56
  incentivizes third -party developers to orbit
• 6:59
  around your core product. which makes your offering
• 7:02
  exponentially more valuable to the end user.
• 7:04
  So you're basically shifting from building an
• 7:06
  internal tool to governing a small economy. That's
• 7:10
  a great way to put it. You'd need completely
• 7:12
  different security protocols and like severe
• 7:14
  rate limiting because now you're dealing with
• 7:16
  unknown, totally unpredictable actors on your
• 7:19
  grid. Right. And then we reach the third phase,
• 7:23
  the marketplace -driven platform. Okay, the third
• 7:25
  one. In this model, the platform itself is the
• 7:28
  primary business. Its entire function is to connect
• 7:31
  producers and consumers. Think of global B2B
• 7:35
  procurement networks or consumer apps like Uber
• 7:38
  and Airbnb. Oh, right. So they don't really own
• 7:41
  the products, they just own the connection. Exactly.
• 7:45
  And the engineering challenge here goes way beyond
• 7:47
  just providing integration points. A marketplace
• 7:49
  platform has to algorithmically reduce transaction
• 7:52
  friction. And it has to solve the cold start
• 7:55
  problem. The liquidity issue. Yeah. Like if a
• 7:58
  buyer shows up to a marketplace and there are
• 8:00
  no sellers, they just leave. And if a seller
• 8:02
  lists a product and there are no buyers, they
• 8:04
  leave too. Exactly. So the platform architecture
• 8:07
  has to artificially stimulate both sides simultaneously
• 8:10
  until network effects can finally take over.
• 8:14
  That sounds incredibly difficult to code. It
• 8:16
  is. The code itself has to build trust between
• 8:19
  two strangers conducting business. which means
• 8:22
  engineering really robust escrow systems, identity
• 8:25
  verification loops, dynamic pricing algorithms.
• 8:29
  Wow. So the foundational DNA of platform thinking
• 8:32
  is definitely present in all three models because
• 8:35
  they all reduce friction and scale via standardization.
• 8:38
  But the actual engineering architecture required
• 8:41
  to build an internal developer portal versus
• 8:44
  a global transaction marketplace, it couldn't
• 8:47
  be more different. That makes total sense. So
• 8:49
  moving from what these platforms are to how enterprise
• 8:52
  leaders actually built them, the source emphasizes
• 8:55
  the necessity of aligning a specific triad. The
• 8:58
  triad, yes. Right. Product strategy, engineering
• 9:00
  execution, and people systems. The stated goal
• 9:03
  of aligning these three pillars is to enable
• 9:05
  reuse, autonomy, and speed. Which is the holy
• 9:08
  grail of tech. Literally. Let's explore the mechanics
• 9:12
  of this tryout, though, because it's super easy
• 9:14
  to just say, align product and tech. But we really
• 9:17
  need to know what that physically looks like
• 9:19
  inside an organization. Well, fundamentally,
• 9:21
  it looks like a continuous negotiation over system
• 9:24
  boundaries. What do you mean by that? So to achieve
• 9:27
  reuse and autonomy, you have to engineer for
• 9:29
  it structurally. And that starts right at the
• 9:31
  intersection of product and engineering. If a
• 9:34
  product strategy is just a chaotic reactive list
• 9:37
  of custom feature requests from, say, the loudest
• 9:40
  clients. Which happens a lot. All the time. Then
• 9:43
  the engineering team will basically be forced
• 9:45
  to build a monolithic tangled mess of code just
• 9:48
  to appease those clients quickly. There is literally
• 9:50
  no opportunity for reuse there. So the product
• 9:53
  strategy has to actively identify the common
• 9:56
  denominators instead? Yes. Like, instead of asking
• 9:59
  engineering to build a custom reporting dashboard
• 10:01
  for client A and a totally different dashboard
• 10:04
  for client B, product needs to step back and
• 10:06
  say, hey, 80 % of our clients need data extraction
• 10:09
  capabilities. Which is brilliant, because that
• 10:11
  allows engineering to architect that extraction
• 10:14
  capability as a distinct abstracted microservice.
• 10:18
  OK, a microservice? Right. They build a powerful
• 10:21
  data export engine just once. And now any future
• 10:24
  product feature, whether it's for client A, B,
• 10:27
  or Z, can just call that single standardized
• 10:30
  service. That is how product strategy dictates
• 10:33
  the what for reuse and engineering architects
• 10:36
  the how. Which directly enables the autonomy
• 10:40
  piece, right? Exactly. Because if an engineer
• 10:42
  is tasked with building a new user interface,
• 10:45
  they don't have to wait for some centralized
• 10:47
  database team to build them a custom export button.
• 10:50
  They just plug and play. Yeah. They just plug
• 10:52
  the pre -existing standardized engine into their
• 10:55
  new app and keep moving. The standardization
• 10:58
  provides the freedom to actually move fast. Yes.
• 11:01
  So what does this all mean? For me, the absolute
• 11:05
  crux of this entire framework is the third pillar
• 11:08
  of the triad, the people systems. Ah, yep. The
• 11:12
  hardest part. Right. We can discuss APIs and
• 11:15
  microservices endlessly, but if the human architecture
• 11:19
  is flawed, the technical architecture will literally
• 11:22
  collapse. You are describing Conway's law perfectly.
• 11:26
  Oh, what's that? It's a foundational adage in
• 11:28
  software architecture. It basically states that
• 11:31
  organizations design systems that directly mirror
• 11:34
  their own internal communication structures.
• 11:36
  Oh, wow. Yeah, so if you have four highly siloed
• 11:40
  territorial departments that basically refuse
• 11:43
  to share information, they will inevitably build
• 11:46
  a software platform with four highly siloed,
• 11:49
  poorly integrated modules. That is wild, but
• 11:52
  it makes so much sense. If the overarching goal
• 11:55
  of the platform is autonomy and speed, but your
• 11:58
  management culture requires a developer to secure
• 12:00
  three VP signatures and sit through a two hour
• 12:03
  change approval board just to deploy a single
• 12:06
  line of code. Then you're going nowhere. Right.
• 12:08
  The platform's technical capability for speed
• 12:10
  is completely irrelevant at that point. Exactly.
• 12:13
  You bought a high speed bullet train, but you
• 12:15
  are forcing it to run on a local commuter schedule.
• 12:18
  That's a great analogy. The people systems, like
• 12:21
  how an organization measures performance, how
• 12:23
  leadership tolerates failure, how the reporting
• 12:26
  lines are structured. All of that has to be completely
• 12:28
  upgraded to match the technology. It forces a
• 12:31
  radical change in incentive structures. Sure.
• 12:33
  Because in a pre -platform hypergrowth culture,
• 12:37
  engineers are frequently rewarded for heroics.
• 12:39
  Oh, yeah. The guy who stays up all night. Exactly.
• 12:43
  Staying up until three in the morning to build
• 12:44
  a duct tape custom fix for a critical client.
• 12:48
  They get praised for that. But in a platform
• 12:50
  culture, leadership has to incentivize reuse
• 12:54
  and documentation instead. Which is way less
• 12:57
  glamorous. It is. You have to promote the engineer
• 12:59
  who spent three weeks quietly refactoring an
• 13:02
  old piece of foundational code so that five other
• 13:05
  teams could use it safely. Wow, yeah. If HR and
• 13:08
  management are not actively aligned with that
• 13:10
  philosophical shift, the technical platform just
• 13:12
  gets abandoned because the human beings operating
• 13:15
  it are literally not incentivized to maintain
• 13:18
  it. Okay, so aligning this triad of product,
• 13:21
  tech, and people is the absolute prerequisite
• 13:23
  for surviving massive organizational growth.
• 13:26
  Yes, without a doubt. Now, the text frames the
• 13:29
  real -world application of these principles around
• 13:31
  two distinct paths. It talks about hyperscaling
• 13:35
  sustainably versus blitzscaling strategically.
• 13:39
  Let's contrast those mechanics because they dictate
• 13:42
  very different realities for the people actually
• 13:44
  building the systems. They really do. If we connect
• 13:47
  this to the bigger picture, both of these growth
• 13:50
  models test the absolute limits of an enterprise,
• 13:54
  but they handle risk and architectural integrity
• 13:56
  fundamentally differently. Okay, how so? So blitzscaling
• 14:00
  is a concept born out of hypercompetitive markets,
• 14:03
  where the first mover basically takes everything.
• 14:06
  Like ride -sharing apps back in the day. Exactly.
• 14:09
  It's about deliberately prioritizing velocity.
• 14:12
  over efficiency in the face of extreme market
• 14:14
  uncertainty. The mechanics of blitzscaling often
• 14:18
  involve intentionally taking on massive amounts
• 14:21
  of technical debt. Intentionally? Oh yeah, you
• 14:24
  hard code configurations. You duplicate databases
• 14:26
  because you simply do not have the time to build
• 14:29
  a proper data pipeline. You're just sprinting.
• 14:32
  Sprinting with scissors. You accept that the
• 14:34
  system will break because if you don't capture
• 14:36
  the market share today, your company won't even
• 14:39
  exist tomorrow to fix the code anyway. So it's
• 14:41
  a calculated trade -off. Absolutely. You're trading
• 14:44
  long -term structural stability for short -term
• 14:46
  market velocity. Exactly. But eventually, I mean,
• 14:49
  the bill comes due, right? That technical debt
• 14:52
  compounds until the system becomes entirely unmanageable
• 14:55
  and feature development just grinds to a total
• 14:57
  halt. Which is precisely why platform thinking
• 14:59
  is so critical, even when a company chooses to
• 15:02
  blitz scale strategically. Oh really? Yeah. Even
• 15:04
  then. Because if you have a core internal platform
• 15:07
  in place before you hit the accelerator, If you
• 15:10
  already have standardized ways of deploying code,
• 15:12
  standardized logging, modular architecture, you
• 15:16
  can blitz scale specific experimental features
• 15:19
  without compromising the entire foundation. Oh,
• 15:21
  I see. You isolate the technical chaos to the
• 15:24
  edges of the network, keeping the core infrastructure
• 15:27
  totally stable and secure. That makes a lot of
• 15:29
  sense. So on the flip side, we have hyper scaling.
• 15:32
  Now, this is still massive rapid growth, but
• 15:35
  the infrastructure is architected to carry the
• 15:37
  load seamlessly from day one. Right. Hyperscaling
• 15:41
  requires rigorous platform discipline. Think
• 15:44
  about a system needing to scale from processing
• 15:47
  10 ,000 transactions a minute to like 10 million
• 15:50
  transactions a minute within an hour. That's
• 15:52
  a huge jump. It is. And you cannot achieve that
• 15:56
  by having IT personnel manually rack more physical
• 15:59
  servers in a room. No, definitely not. The mechanism
• 16:02
  of hyper scaling relies on the platform utilizing
• 16:05
  dynamic load balancing, auto scaling, compute
• 16:08
  clusters, asynchronous processing. The platform
• 16:11
  has to automatically provision massive amounts
• 16:13
  of server resources based on real time traffic
• 16:16
  spikes. And then it has to scale back down, right?
• 16:18
  Exactly. It aggressively spins them down when
• 16:21
  the spike passes just to manage costs. So it's
• 16:24
  highly sustainable, but it requires a massive
• 16:27
  upfront investment in engineering execution and
• 16:31
  product foresight. Well, this brings some really
• 16:33
  necessary context to Rupa Jayaraman's background,
• 16:36
  because as the CTO at Odessa, she is steering
• 16:40
  the ship for a global platform in the B2B SaaS
• 16:43
  space, specifically dealing with enterprise asset
• 16:46
  finance. Which is an incredibly complex space.
• 16:48
  Staggeringly complex. You're navigating intense
• 16:51
  regulatory compliance, international security
• 16:53
  standards, massive transactional volume. I mean,
• 16:55
  you cannot blitz scale your way through global
• 16:58
  financial compliance by duct taping APIs. together.
• 17:01
  No, definitely not. You'd have to hyperscale
• 17:03
  sustainably. And operating a platform on a global
• 17:06
  level introduces another really severe layer
• 17:09
  of complexity, which is the requirement for cognitive
• 17:11
  diversity. OK, tell me more about that. Well,
• 17:14
  when you build infrastructure that spans continents,
• 17:17
  the edge cases multiply exponentially. So a user
• 17:21
  authentication workflow or, say, a data privacy
• 17:24
  protocol that makes perfect sense in a North
• 17:27
  American market might completely break down when
• 17:30
  applied to European regulatory environments or
• 17:32
  Asian mobile networks. Wow, yeah. This connects
• 17:35
  directly back to the human element of our triad,
• 17:38
  doesn't it? It does. Rupa was actually recently
• 17:41
  recognized as one of Businessworld's top inspiring
• 17:44
  women leaders to watch in 2025, specifically
• 17:47
  for her work championing inclusive innovation
• 17:50
  -driven workplaces. And viewed through the lens
• 17:53
  of platform architecture, diversity and inclusion
• 17:55
  aren't just like HR initiatives. Right, they're
• 17:58
  structural necessities. Exactly. Their necessities
• 18:01
  for building a resilient global system. Because
• 18:03
  if an entire platform engineering team shares
• 18:05
  the exact same background with the exact same
• 18:08
  lived experiences, they are going to architect
• 18:10
  a system with massive blind spots. They'll only
• 18:13
  build the dirt roads they personally know. Yes.
• 18:16
  What a perfect way to bring that analogy back.
• 18:18
  It's true, though. Cognitive diversity within
• 18:21
  the people systems ensures that the platform
• 18:23
  is robust enough to handle those global edge
• 18:25
  cases. an inclusive environment fundamentally
• 18:28
  encourages pushback. Like people feel safe speaking
• 18:30
  up. Exactly. It allows a junior engineer in a
• 18:34
  completely different time zone to comfortably
• 18:36
  raise a flag and point out that, hey, a new feature
• 18:38
  assumes a specific type of high -speed internet
• 18:40
  access that their regional users simply don't
• 18:43
  have. Right. Without that inclusive culture,
• 18:46
  the platform just becomes brittle. It only functions
• 18:50
  under the incredibly narrow conditions assumed
• 18:52
  by a completely homogenous group of creators.
• 18:55
  It is such a brilliant way to view inclusive
• 18:58
  leadership as a hard architectural requirement
• 19:01
  for scaling a global system. It really is. So
• 19:05
  synthesizing all of this for you, the listener.
• 19:08
  Whether you're a technology executive trying
• 19:10
  to navigate the daunting growth of a multinational
• 19:12
  enterprise, or you're simply someone trying to
• 19:14
  bring a sense of order to a chaotic project with
• 19:17
  a small team, the core lesson of platform thinking
• 19:20
  remains the same. It scales to any size. It really
• 19:23
  does. It's not just about buying new software.
• 19:26
  It is a fundamental mindset shift. It's the realization
• 19:30
  that to move fast tomorrow, you have to build
• 19:32
  reusable, standardized foundations today. You
• 19:36
  have to ruthlessly align your product strategy,
• 19:38
  your engineering reality, and your people systems.
• 19:41
  It is the deliberate shift from paving individual
• 19:44
  dirt roads to designing the master grid. But,
• 19:47
  you know, as we synthesize these mechanics, this
• 19:50
  raises an important question. It's a paradox
• 19:53
  embedded in platform thinking that I think is
• 19:55
  worth lingering on. Oh, I love a good paradox.
• 19:57
  Let's hear it. Well, the session notes highlight
• 19:59
  that Rupa champions both highly standardized
• 20:02
  scalable platforms, which fundamentally requires
• 20:05
  strict governance, rigid rules, and the absolute
• 20:08
  mandate of reuse. Right. And she champions inclusive
• 20:12
  innovation -driven workplaces, which require
• 20:15
  diverse, unpredictable, out -of -the -box thinking.
• 20:18
  Oh, wow. Yeah. These two concepts are in a natural
• 20:22
  structural tension. Standardization is about
• 20:24
  making things uniform to reduce friction. Innovation
• 20:28
  is about breaking uniformity to discover something
• 20:31
  new. So you need the rigid city grid so the traffic
• 20:35
  flows efficiently, but you cannot let the rules
• 20:38
  of the grid stifle the creativity of the people
• 20:40
  trying to build unique houses on top of it. Precisely.
• 20:44
  So here is the puzzle to mull over on your own.
• 20:47
  As organizations build these incredibly powerful
• 20:50
  governed platforms to drive speed and reuse.
• 20:53
  How do leaders ensure that those underlying systems
• 20:56
  don't accidentally standardize out the diverse
• 20:59
  human innovation needed to build the next big
• 21:02
  thing? That's tough. It is. Finding the exact
• 21:05
  balance between structural governance and human
• 21:08
  autonomy is the true art of enterprise leadership.
• 21:12
  That is a phenomenal thought to leave on. Thank
• 21:14
  you for joining us on this deep dive. We hope
• 21:17
  we helped clear up the diagnostic muddy waters
• 21:19
  of corporate complexity and gave you the mechanical
• 21:21
  understanding to start building your own master
• 21:23
  grid. Keep thinking critically about the systems
• 21:26
  around you and we will catch you on the next
• 21:27
  one.