Accelerate your Delivery by Reducing Dependencies - Descaling for Agility

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/accelerate-your-delivery-by-reducing-dependencies-descaling-for-agility/transcript.md ## Published episode notes In this episode of Scaling with Agility, Yuval discusses the challenges organizations face with cross-product work and dependencies, advocating for a strategy of descaling rather than investing in more program management. He explores the concept of empowered product teams, the importance of minimal dependencies, and offers practical steps for organizations to identify constraints and improve their architecture to enable localized work. Using real-world examples, he illustrates how to experiment with descaling, manage risk, and achieve collective ownership across different organizational levels. 00:00 Dependencies Everywhere? 00:20 Common Solutions and Their Pitfalls 00:41 Descaling and Empowered Product Teams 02:04 Identifying Constraints and Topology Options 03:39 Case Study: Scaling Startup with Specialized Database 05:03 Evaluating and Implementing Design Options 06:03 Experimentation and Change Management 07:40 T-Shaped Teams and Collective Ownership 09:35 Conclusion and Further Resources https://yuvalyeret.com/the-portfolio-agility-trail-map/The No BS Scaling w/ Agility Podcast - For leaders who aim to scale their organization with nuanced agility instead of the Agile Theater BS The Scaling w/ Agility Newsletter – yuvalyeret.com/insights Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/ ## Transcript Automatic transcript of the published podcast audio. Recognition errors are possible. Speakers are unlabeled; do not attribute a passage to Yuval or a guest without checking the audio. Episode: https://yuvalyeret.com/scaling-ai-podcast/accelerate-your-delivery-by-reducing-dependencies-descaling-for-agility/ Source RSS GUID: substack:post:166728096 Source: published Riverside RSS audio enclosure Transcription: faster-whisper base.en, English ## Transcript [00:00:00] Do you feel like almost any outcome of any significance in your organization is a cross-product project or program? [00:00:09] This is scaling with agility the podcast for leaders who are looking to find a nuanced approach to agility that replaces the edge of theater. [00:00:19] One solution the typical solution that organizations turn to when [00:00:25] They see work that cuts across products [00:00:30] Is to invest in better program management, better coordination, build a PMO [00:00:36] Use all of the scaling patterns, higher program managers. A better solution would be to descale [00:00:44] to find ways to organize around outcomes. [00:00:47] The goal here isn't to be more efficient at managing the scale, managing the dependencies. [00:00:55] The goal should be to minimize the number of [00:00:58] outcomes, the amount of work that spans product or development groups, that spans the organization. [00:01:06] And that's the whole idea of empowered product teams. [00:01:09] Also known as stream-aligned teams in theme topologies, featured teams earlier. [00:01:14] Being empowered means having decision rights, their resources and the skills to discover and deliver [00:01:21] product outcomes with minimal dependencies. [00:01:25] But those are a couple of different things. [00:01:32] Empowering people, giving them the decision rights that's meaningless without having the resources and skills. [00:01:39] You can empower product teams, you can empower product managers, but if the team is heavily dependent on other teams, [00:01:45] you're only empowering them to negotiate and spend time in a coordination like them. [00:01:51] That often flows up all the way to the cross-product layer or even the organization, the enterprise for resolution. [00:02:00] Whether you call that portfolio or something else, the problem is there. [00:02:04] When leadership teams approach me with this challenge, I guide them through first of all identifying the constraints. [00:02:12] Where in the organization are the usual suspects, the teams, the groups, that are involved in everything. [00:02:20] In many cases, we can see a pattern where the majority, maybe even 80% of the dependencies, map to 20% of these teams. [00:02:29] Those are the teams that we should probably focus on. [00:02:32] And then we look at what are some topology options that work better. [00:02:36] Could we use an architectural intervention, such as introducing a self-service platform to help melt some of this iron spaghetti? [00:02:46] Could we enable people, use some more aggressive cross-producti-shaping to enable people and teams to do the work that's currently limited and constrained by specific teams? [00:03:01] We then compared the different design options to the current state as well, based on how much of the work will be localized using this option. [00:03:12] We aim for the majority of the work to be localized, ideally 80% of the work to be localized, but we acknowledge it would never be perked. [00:03:21] Another consideration is how much of a change from the current state is this option. [00:03:28] Will the change be hard? How much risk will it introduce? [00:03:33] In general, how much product technology people risk does this option entail? [00:03:39] I've worked with a scaling startup that used a very specialized database as the core of their product. [00:03:49] They knew this team was a bottleneck, a constraint, but at the time, they felt this was too risky to distribute this core capability with limited know-how. [00:04:00] So what we've done is we've acknowledged that this team is going to be a constraint. [00:04:05] We've used some coordination patterns around this team. [00:04:08] Meanwhile, we started working on the architectural runway. [00:04:12] They started working on simplifying this core, providing an API to the so that over time, this would enable them to actually allow more and more of the work to develop and leverage this core persistency layer to happen in streamline teams rather than in this sub-system team and the constraint of the organization. [00:04:38] Another question to ask is how future proof is this option? [00:04:41] How aligned is it with our strategy? What's all known or rising? [00:04:45] How much will them work that we will need to deliver to those outcomes or impact that organization needs? [00:04:54] How much of it will be localized versus will require collaboration across many teams or even groups? [00:05:03] So we look at the different options on the table, we score them, pair these parameters, and we find the best option considering all of these factors. [00:05:14] And when we find an option, an alternative that is significantly better, if we find one, we evolve it like a product. [00:05:25] We clarify what are the outcomes that we are looking for. [00:05:30] What would success look like? What would the behaviors and the patterns of flow and people's happiness with the work? [00:05:38] How will this change enable us to do work in a safer, happier, sooner fashion to use the SSH language? [00:05:51] What would be the leading indicators that were on the right track? [00:05:54] We agree on what would be the discovery approach to try this, and we tackle it incrementally if possible. [00:06:03] When I worked with HP Software more than a decade ago, we started with the existing team structure, which was pretty much component-oriented. [00:06:17] But we identified that there is an issue. [00:06:19] The approach we decided to take from a discovery, agile approach to agile perspective was to take one specific strategic investment that they were focused on and create a streamlined team to focus on that work. [00:06:38] We made some assumptions around what would look different when we used that team, and we tried it out for one release. [00:06:45] We didn't say this is where the organization is going. [00:06:49] We didn't say this is how we are going to do things from now on. [00:06:52] We defined it as an experiment, which also has change management advantages. [00:07:00] After we've seen that this streamlined cross-functional team was much faster, was a better place for people, was actually driving people to become more T-shaped by itself. [00:07:14] We've started to scale that and figure out how could we make more and more of the teams in that group look like that. [00:07:23] We still kept one or two teams that were focused on core technologies that we didn't spread to stream aligned teams yet. [00:07:33] This pattern can be used at multiple layers. [00:07:37] You can use this pattern at the team level. [00:07:40] When we talk about T-shaped engineers, T-shaped developers, T-shaped team members, that's a pattern that aims to create more collective ownership. [00:07:52] That creates more liquidity, more flexibility and optionality for the team that helps the team tackle whatever the priorities are and make the collaboration inside the team focus on the right things. [00:08:07] What I'm talking about here is doing that at the product group level, grading some more collective ownership at the product group level and even at the organizational level. [00:08:17] Both collective ownership as well as changing the architecture, the technology that you work on to minimize the amount of dependencies that you have to face. [00:08:28] At all levels, what we want to do is we want to use the patterns of whatever patterns you use for management, whether it's agile, whether it's waterfall, whether it's a gun chart, a gun chart should also be used [00:08:44] to show you that you're facing too many dependencies, that you're taking on constraints that are potentially avoidable. [00:08:56] The purpose of these management tools is not to add more and more scaffolding to compensate for your dependencies and for your imperfect or far from perfect organizational architecture. [00:09:11] It's to add the minimum scaffolding to help you manage right now, as well as encourage you to work on your architecture, the organizational architecture and the product or technology architecture. [00:09:27] And that's a pattern that you can implement at the personal level, the team level, the group level, the portfolio level. [00:09:35] If you want to learn a bit more about how to use scaling patterns to the scale and multi product believer organization, I created the portfolio agility trail map. [00:09:48] The chair is a pattern that I've been using for a while of starting with a flow perspective, using a flow perspective to the work to see where your constraints, to see where you have dependencies that can be avoidable. [00:10:03] And start to use flow management as a catalyst towards the scaling your organization. [00:10:11] Thank you for listening to the scaling with agility podcast. I'm you Valier. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.