DevOps Demystified: SLA, SLO, and Continuous Delivery Explained with Xing Zhou, Ford Credit

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand.

[00:00:05] Ashok Sivanand

[00:00:06] Being able to deploy at any point, to me, is a technical capability. Any team can and should get to the point where they can deploy at any point and make deployment a non-event.

[00:00:19] On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of. Welcome back to the Convergence Podcast. Today, I'm joined by one of my favorite technologists and also favorite people, Xing Zhou.

[00:00:47] Xing's career spans companies like Amazon, Pivotal Labs, Ford Credit, and also alongside myself at Integral. In that time, Xing has led and consulted to high-performing teams implementing cutting-edge DevOps strategies

[00:01:03] and helping organizations take meaningful steps toward improving their Dora metrics. He's also worked on so much more in the world of lean, agile, and product leadership.

[00:01:13] After our episodes with Derek Ferguson in early December of 2024, where he talked about the benefits of focusing on Dora metrics, I wanted to dive deeper into what actionable steps that both the folks in the C-suite as well as on the product teams could take in order to get better control

[00:01:30] and make incremental progress at improving their Dora metrics toward those elite benchmarks.

[00:01:37] Xing has been in the trenches, solving real-world problems, working with both technology and product leadership to break down technical complexities into clear next steps that the team can use.

[00:01:50] Xing might be one of my favorite colleagues and had a tremendous impact on the culture and the technical prowess of the integral team.

[00:01:57] Xing is really rare to find folks who have both the ability to be technically strong and also have the emotional intelligence and management acumen to drive change across large teams.

[00:02:08] On the episode, we dive into the nitty-gritty of Dora metrics and Xing's recommendations on the first steps you can take today.

[00:02:16] These include SLAs, CICD, behavior-driven development, event-storming workshops, and other ways in aligning your team and driving productivity, which ultimately reflect better on your Dora metrics for your organization and more delighted customers for your products.

[00:02:33] Plus, Xing shares some great stories and advice on bridging the gap between leadership and product teams, creating alignment, and fostering incremental progress towards elite performance.

[00:02:44] If you've ever wondered how to make DevOps work better for your software team, or how to build trust across a product organization and turning metrics into a reflection of your team's health rather than just to say FKPIs, you're going to love this one.

[00:02:59] Here is Xing Zhou.

[00:03:19] What's up, Xing?

[00:03:20] It is awesome to have you here, man.

[00:03:22] Hey, thanks for having me.

[00:03:24] I'm excited.

[00:03:25] Before we go into the details, let's go into some definitions around what those Dora metrics are.

[00:03:31] So the Dora metrics came out of research led by Google, and they were looking at how to identify productive teams.

[00:03:42] And they found productive teams tend to have these four, initially four metrics, and then they added a fifth one.

[00:03:50] Where if the metrics are high, then the teams tend to be productive.

[00:03:53] So there is a correlation.

[00:03:54] And the metrics are change lead time, deployment frequency of their software, a change failure percentage, failure deployment recovery time, and reliability.

[00:04:10] And Dora stands, I understand for DevOps research and assessment.

[00:04:15] And while we're doing the definition phase of this, there's a lot of very convoluted definitions.

[00:04:22] And one thing I love about talking to you is you're able to take a lot of that complexity and make it into something simple that I can use.

[00:04:29] So what do you, how do you define DevOps or if I were to ask you if a team does DevOps well, what do you tend to look at at a more simpler state?

[00:04:40] My definition for DevOps is really, it's about automating things that are not so valuable to do repeatedly.

[00:04:50] All right.

[00:04:51] All right.

[00:04:52] So I believe from the SRE realm or SRE group, they have this concept of toil, which are activities that you do that's repetitive, that don't add a lot of value every time you do it.

[00:05:05] So the goal then is to identify things that are toil, eliminate it, or automate it away.

[00:05:13] So I look at DevOps as a way to achieve removing of waste in a process or a system.

[00:05:23] Awesome.

[00:05:24] And I think from the lean school, we can maybe correlate toil as something that your customer does not tell the difference whether you're doing it or not.

[00:05:34] And it's wasteful by that measure.

[00:05:37] Yes.

[00:05:38] And so I started off by kind of talking about this disconnect between leadership and the teams.

[00:05:44] And you've done this as a consultant.

[00:05:46] You've done this at various companies.

[00:05:48] And what do you see as being maybe your interpretation or analysis of that root cause of that disconnect between leadership and teams when it comes to trying to be really good at Dora?

[00:06:01] It's one thing for leadership to understand what the metrics are and why it is important from an organization standpoint.

[00:06:08] It's a whole different ballgame when it comes to getting the team not only understanding the importance of the metrics, but also implementing changes and developing skills to actually improve on the metrics.

[00:06:24] I think from, I think the reason that I think there may be, maybe there's a disconnect is that the leadership may not always have insight into the current state of the teams.

[00:06:39] So the leadership will introduce a metric and the teams may, or they're trying to do their best.

[00:06:46] They feel like they might be drowning in work or they, maybe they feel like they're doing really great.

[00:06:50] And suddenly there's this set of new metrics that's coming down from leadership and they don't understand why.

[00:06:56] So I think it's very important for the leadership team to explain, reiterate why these metrics are important.

[00:07:07] But I think what really gets traction is if the leadership team can go where the teams at and understand some of the pain points the teams may be experiencing.

[00:07:21] And then highlight that these pain points, by addressing these pain points, by making changes to process, to skill set that reduces these pain points, it's actually reflected in the metrics.

[00:07:35] Right. So if you set up that context and accept that relationship, then the metrics becomes a reflection of the team's health.

[00:07:49] Creating expectations more explicitly is an amazing way for leadership to be able to align themselves first and then the team second, so that we're all rowing in the same direction and de-risk our chances of getting to where we want to get to.

[00:08:03] And we chatted earlier and you and I have worked on SLAs and SLOs before.

[00:08:09] That's probably a good example, maybe, of something that leadership can prioritize as an expectation, maybe?

[00:08:15] First, let's define SLAs and SLOs.

[00:08:18] So we're on the same page, right?

[00:08:20] Just like we had to do with DORA.

[00:08:21] SLA is service level agreement, SLO is service level objective.

[00:08:26] Their way, their definitions, they're things that you can measure a service's performance by or how you measure a service.

[00:08:43] And you mentioned leadership setting expectations for SLAs and SLOs.

[00:08:50] That's very powerful.

[00:08:53] At the same time, for teams who don't have experience with setting SLAs and SLOs, that also may become another burden for them.

[00:09:02] Right. So what's important is to demonstrate that SLAs and SLOs, once established for a team, actually empowers the team to make decisions to their own benefit.

[00:09:16] So I've had experiences where a team does not have SLA and SLOs.

[00:09:23] And they were getting requests from teams that were using their service, where their service was having infrequent but observable performance issues.

[00:09:43] Mm-hmm.

[00:09:44] So the team was responding to each of these issues requests as if it is the most important thing on their backlog, on their to-do list.

[00:09:53] But once they establish an SLA, SLO, they're able to, first of all, observe that in the longer time span of 10 seconds, right?

[00:10:10] Longer than 10 seconds, if they were looking at, if they look at their past month performance of their system, they're still meeting their SLAs.

[00:10:20] So they're doing fine.

[00:10:21] So any issue that comes in can be considered to be lower priority.

[00:10:27] Obviously, it depends on the specific issue, but it gives them a level to measure by.

[00:10:38] More important for this particular example of this team, the SLAs and SLOs, once they created it, they're able to socialize it with the rest of their organization and their ecosystem.

[00:10:53] By socializing that, they're able to set better expectations for their consuming teams, teams that use their service.

[00:11:00] This is what you can expect in terms of our system's performance.

[00:11:04] Because at the end of the day, these systems are distributed systems, which means things could just randomly slow down.

[00:11:13] Things could just randomly fail.

[00:11:17] So we cannot achieve, you know, they cannot achieve 100% failure.

[00:11:22] They cannot, sorry, they cannot achieve 100% availability or very, very low latency.

[00:11:31] So they needed the SLAs and SLOs to set expectations for themselves, but more important for the teams that's using their service.

[00:11:40] And so that eased their workload in terms of handling issues all the time.

[00:11:45] Yeah, and there's nothing better for a team to kind of have a decision tree of some kind to know like, hey, is this something I jump on like a five alarm fire?

[00:11:54] Is this something that we, maybe on the other end of the spectrum, if we're meeting our SLAs, but our customers are continuing to maybe raise it, then it's a good business conversation.

[00:12:04] Where we say, hey, we're currently maybe doing two nines or 99.99 and go to our business owners or other folks that are responsible for more than just the technology and the budgets and investments and priorities and say, hey, do we want to go from one nine to two nines?

[00:12:23] And really, I think we also have to look at the infrastructure on which this all sits in the first place.

[00:12:29] If you're using AWS or GCP or any of those folks, they're not going to give you 100% availability anyway.

[00:12:36] And so asking of your team of doing anything better than that is just really infeasible.

[00:12:41] And there's also a long tail of investment that goes to getting jumping from two nines to three nines.

[00:12:48] And if you were maybe running a healthcare monitoring system that sits inside a patient, you want to have a very different level of availability than an e-commerce application where it's revenue loss, but not life and death per se.

[00:13:02] Right.

[00:13:03] And so how does that work for a business conversation?

[00:13:08] Do you think the business or product folks tend to be able to get into that too?

[00:13:12] I think it kind of depends on the experience and capabilities and skill set of the business individual or the business folks who are involved.

[00:13:22] Some business folks may not have the technical background to really have very nuanced conversations about what infrastructure or what tools or frameworks or libraries that we really need to invest or what architecture techniques that we should really invest.

[00:13:46] But if we have SLAs and SLOs, those are framed in less technical terms, in more observable technical terms, such that in my experience for product folks who are not as technical, they can still understand it.

[00:14:09] And having that defined allows product folks who have conversations among themselves to understand this is our service's current performance.

[00:14:23] If we want, do we really want to improve the performance by this much, but the spending is orders of magnitude more compared to what we're spending right now on this particular service?

[00:14:41] Fostering an engaged product organization and aligning them with the principles around lean, human-centered design, and agile will more than likely lead to successful business outcomes for your organization.

[00:14:54] But getting started or getting unblocked can be hard.

[00:14:57] This podcast is brought to you by the player coaches over at Integral.

[00:15:01] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile.

[00:15:12] Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:15:21] During this session, the integral team will facilitate a problem-solving exercise that gives you clarity and confidence to solve a product design or engineering problem.

[00:15:32] That's integral.io slash convergence.

[00:15:36] Now, back to the show.

[00:15:43] Was CICD, right?

[00:15:45] And I think that's going to help probably the change lead time, deployment frequency.

[00:15:50] And so I had mentioned in maybe like a pretty high level that I'd love for you to get a little bit deeper.

[00:15:58] Some teams do the integration part, which we can get to next.

[00:16:01] But in terms of the CD part, whether it's continuous deployment, continuous delivery, there is some friction and some decisions I think teams have to make around how far they want to be good at that.

[00:16:13] And I'm curious to know, you've worked in a variety of settings and what you've seen there.

[00:16:19] Yeah.

[00:16:21] The continuous delivery is always an interesting conversation.

[00:16:26] The way I look at continuous delivery, I kind of split it in multiple ways.

[00:16:34] So there's this definition of continuous delivery where every change made to a piece of code is automatically deployed to the customer.

[00:16:49] Throughout this automated process that takes maybe just a matter of minutes.

[00:16:58] To me, it ultimately comes down to a business decision on whether or not you want that to be how your teams and how your software functions.

[00:17:12] Right.

[00:17:12] And the reason I say it's a business decision is because I think what your business is and the domain of your business is important.

[00:17:21] Take financial applications.

[00:17:26] They're much more heavily regulated than, say, social media or just a simple web app.

[00:17:33] So in the financial institutions, they may not want to have every single change be automatically deployed to in front of their customer.

[00:17:44] They may have to go through regulatory approvals.

[00:17:48] They may have to check all the boxes and have the security folks and audit folks be very happy with what they've done.

[00:17:56] So maybe in that context, continuous delivery means, hey, we are deploying once a week or once a month.

[00:18:06] Whereas, like I mentioned, a social media company or a web app, you could potentially deploy 100 times a day.

[00:18:14] Right.

[00:18:15] So to me, whether you deploy automatically very, very frequently is a business decision.

[00:18:23] However, there's the technical side of building out your process and build out your tools and your skill set so that you can deploy at any point.

[00:18:38] So I've heard this described as making deployment a non-event.

[00:18:42] That is to say, we're going to deploy in two minutes.

[00:18:46] All right, cool.

[00:18:46] We're going to hit a button.

[00:18:49] It's deployed.

[00:18:50] Now we can all go home and rest easy and enjoy life outside of work.

[00:18:56] Being able to deploy at any point, to me, is a technical capability.

[00:19:00] And I think any team can and should get to the point where they can deploy at any point and make deployment a non-event.

[00:19:13] And then it becomes much easier of a conversation if the business want to actually do continuous deployment and continuous delivery all automated.

[00:19:24] That's a business concern that's separate from technical capability.

[00:19:28] So that tells us a lot about the CD part.

[00:19:31] On the CI side, I think there's a few things that we've helped teams get across.

[00:19:36] And the first one is the PR versus trunk-based model.

[00:19:41] And so maybe talk a little bit about the problem you see with PRs or your opinion there.

[00:19:49] This is a conversation I've had with almost every single team I've been involved in.

[00:19:55] The PR model, which again is a model where you have a change set.

[00:20:01] And in order for the change set to be sent to production, you have to open a pull request.

[00:20:09] And then that pull request gets approved.

[00:20:11] And then it finally emerges.

[00:20:13] In my opinion, in that setup, the team is not getting the value of continuous integration.

[00:20:24] Even if they have very good test suites, even if they have automated processes,

[00:20:29] the fact that there is a change set waiting somewhere, whether it's in a branch or some other way,

[00:20:35] this change set is separate from the main code, the code that's going out to production.

[00:20:45] To me, they're not doing continuous integration.

[00:20:48] Because continuous integration, by definition, is you're continuously integrating the changes from various folks

[00:20:58] so that you're de-risking when the changes do come together.

[00:21:01] And when you have long running branches or branches that live for longer than a day,

[00:21:06] or you have a change set that's sitting there as a PR waiting and it's there for longer than a day,

[00:21:12] you are raising the risk of when you integrate that change into other code that there's going to be issues.

[00:21:22] So in my opinion, if you're doing PR model, you're not getting the benefit of continuous integration.

[00:21:27] So my preference is trunk-based development.

[00:21:31] From the DuraMetric standpoint, when you are doing trunk-based development,

[00:21:38] I think it directly leads to lower cycle time or what is it called?

[00:21:45] A change lead time, or lower change lead time.

[00:21:49] And if you pair CI with CD, you can get a lower deployment, or sorry, increase in deployment frequency.

[00:21:59] Now, the interesting thing with trunk-based development is, again, the domain does matter.

[00:22:06] Your business domain does matter.

[00:22:07] So everything's kind of nuanced.

[00:22:09] So, again, in a financial institution, if you have regulation, legal requirements,

[00:22:17] what does trunk-based development may look different compared to other businesses, social media companies, or whatever.

[00:22:28] So I don't exactly have a lot of experience in that field.

[00:22:32] I am aware of it.

[00:22:33] So I think the best advice I've heard is make friends with your security groups and audit groups

[00:22:39] and come together to come up with a solution where you're getting majority value of trunk-based development

[00:22:45] and continuous integration, but also getting the benefit of security and auditing.

[00:22:50] Yeah, I think that sharing the why that we talked about earlier about why Dura

[00:22:55] is not just applicable from leadership to the product teams,

[00:22:58] but also the product teams sort of horizontally to the other support teams like security and audit as well

[00:23:05] and getting them on board in terms of how's it better for them in the long run?

[00:23:08] How are we collectively going to do something that's better for our customer and our business in the long run?

[00:23:13] And getting them bought in and finding maybe small areas that you can start automating this work

[00:23:19] as opposed to what sometimes happens being kind of a political fiefdom, highly sort of friction-based conversation

[00:23:27] where you're shooting shots across the bow versus getting together and collaborating on how to get started.

[00:23:33] You mentioned there around even teams that have well-tested suites.

[00:23:37] And maybe we get to our third kind of point around things to do to improve your Dura metrics is test automation.

[00:23:43] We've talked about test-driven development a lot on the show.

[00:23:46] And I think one thing we haven't gotten as much into is behavior-driven development,

[00:23:52] which is very adjacent and relevant to test-driven development.

[00:23:56] So let's hear maybe in the same fashion we have, let's hear your definition for that,

[00:24:01] and then we'll get into the detail second.

[00:24:03] BDD, behavior-driven development, is a way to write your test effectively.

[00:24:13] A way to write your test in language that's not so technical.

[00:24:20] It should be in the language of your business domain.

[00:24:24] So if you're in a financial institution, you're handling loans, then your loans can be originated,

[00:24:30] your loans can be approved, it can be rejected.

[00:24:35] Those are the words you would want to use to capture your system's behavior.

[00:24:43] And it just happens when you write those out in a certain way, the Gherkin language.

[00:24:50] It could be automated as a test.

[00:24:53] And what's the Gherkin language for anyone who may not know that?

[00:24:57] Yeah.

[00:24:59] The Gherkin language is just a format for writing.

[00:25:02] It's a document format, frankly.

[00:25:05] There are keywords, and this is how you can structure a scenario or business rule.

[00:25:11] And then there are tools that will be able to parse this document and turn them into executable tests.

[00:25:20] Yeah, I think the format, if I recall, from when I used to write the user stories myself,

[00:25:26] was given a set of assumptions, when something happens, then we do a certain thing,

[00:25:34] as certain actions taken, right?

[00:25:35] And for me, I really liked it.

[00:25:37] It was a good discipline for me as I moved closer back to the development teams

[00:25:42] from more of the business side of helping articulate and create a system,

[00:25:48] even in my own mental model, before introducing it to a development team.

[00:25:53] And it was a good set of checks and balances for myself.

[00:25:56] And of course, writing in that format allows it to be automated in a much easier way too, right?

[00:26:02] Yes.

[00:26:03] Yes.

[00:26:03] In fact, depending on how you write it and depending on how well the person who wrote the user story,

[00:26:10] how well they work together with the development team,

[00:26:13] they can write it in a way that the development team just copy-paste it

[00:26:16] into a specific file that the tool can read and turn it into a test.

[00:26:20] That's awesome.

[00:26:21] It takes time to get to that point, obviously,

[00:26:24] but it's doable and it is very powerful.

[00:26:29] And so this is similar to many of the buzzwords where maybe at the grassroots level or a team level,

[00:26:36] it's something that the technical folks or the product team folks tend to hear about at conferences

[00:26:42] or other ways that we do our continuous learning.

[00:26:46] On the other hand, it's something that may be difficult to convince the broader organization

[00:26:51] or leadership, especially in bigger companies where you kind of need a little bit more permission,

[00:26:55] don't necessarily have the same level of autonomy like you would at a tech company or a startup.

[00:27:00] Yep. So if you were to give some folks advice who really want to introduce BDD to their teams,

[00:27:07] they've got to kind of get some quick wins and there's only so much, call it a leash,

[00:27:11] that they can earn from their leadership.

[00:27:14] What's some advice on the best places to get started to get those quick wins?

[00:27:18] It's not always easy, but it's definitely doable.

[00:27:23] The best way to gain some wins, as you say, is to find a piece of code that has business logic,

[00:27:42] that has business value and it has business behavior.

[00:27:46] But it's also fairly easy to test or to put it into a test.

[00:27:53] If you have both of those cases, then...

[00:27:57] And I've done this before with teams that I've helped with.

[00:28:02] I helped.

[00:28:03] Where they wrote a dozen or so scenarios

[00:28:08] that describe the behavior of this particular piece of code.

[00:28:14] And the scenarios are tests, obviously, through the tools we were using.

[00:28:20] And then if you have that, you can demonstrate that to the rest of the organization.

[00:28:27] And I have a really inspiring story from my perspective

[00:28:32] where the team I was helping with, they did exactly this.

[00:28:35] They wrote the test around business logic

[00:28:41] in ways that's understandable for non-technical folks.

[00:28:45] And then they did a presentation, a demo of what they've done.

[00:28:50] And at the end of the presentation, during the Q&A slash comments section,

[00:29:00] one product individual who's new to our organization,

[00:29:05] who's new to our group, spoke just unprompted, said,

[00:29:10] hey, this was great.

[00:29:12] I was able to follow along with everything you're doing.

[00:29:15] And now I understand a bit more about exactly what this service,

[00:29:21] this piece of code actually is intended for.

[00:29:24] Like, what's the behavior this is implementing?

[00:29:27] That was really, really powerful.

[00:29:29] Because our technical team implemented something

[00:29:34] that our product folks immediately understood the value of.

[00:29:40] And that's such a great way to get started on that journey of building trust,

[00:29:46] both vertically in your organization amongst leadership

[00:29:50] and also horizontally with your business counterparts,

[00:29:52] which then you can build into a virtuous cycle of bigger chunks of things

[00:29:59] or slightly more complicated sets of things

[00:30:00] that you can go cover your test suite using techniques like BDD.

[00:30:06] Yes.

[00:30:07] Another thing that I think I've heard a ton of teams try to implement

[00:30:13] or want to implement is event storming.

[00:30:17] And so tell me a little bit about what that means to you,

[00:30:21] how that typically helps in the context of Dora,

[00:30:25] and then we'll maybe get into how to get started after that.

[00:30:29] Yeah.

[00:30:30] Yeah.

[00:30:30] I think in the context of Dora,

[00:30:32] even if we don't talk about event storming,

[00:30:34] is the Dora metrics reflects a team's productivity.

[00:30:41] And the central thing for a team to be productive

[00:30:44] is to know what is the piece of code,

[00:30:48] what is the software they're actually developing, right?

[00:30:51] Having an understanding of what's the goal of the software,

[00:30:54] what is the business process that the software should really be implementing

[00:31:00] or should be facilitating.

[00:31:04] So understanding the business is crucial for a good Dora metrics.

[00:31:09] Event storming, I found,

[00:31:12] is a great tool to establish this understanding across the team,

[00:31:17] within the team, and even within an organization.

[00:31:22] So what is event storming, right?

[00:31:25] Event storming is you bring a group of folks together

[00:31:29] and you try to understand the business process,

[00:31:36] any business process.

[00:31:38] But the way to understand is the group will generate events.

[00:31:43] So the events that's associated with the business process,

[00:31:48] for example, a financial loan,

[00:31:50] getting originated and getting accepted,

[00:31:53] getting approval, getting rejected.

[00:31:55] The group will come together and generate these events.

[00:31:58] And it may sound a little weird, potentially, for folks to do this.

[00:32:04] But if you were to listen to product folks describe their business,

[00:32:10] they end up talking about events all the time.

[00:32:13] Right?

[00:32:13] Oh, this thing happened.

[00:32:15] And then this thing happened.

[00:32:16] And then this thing happened.

[00:32:17] Well, those are events.

[00:32:18] You can listen to them, write them down,

[00:32:20] put them in chronological order.

[00:32:22] And just by laying them out,

[00:32:25] people will have a clear understanding of what the process is

[00:32:29] and what happens within the process.

[00:32:32] And also will probably raise questions because they discover,

[00:32:35] oh, this part I don't actually understand.

[00:32:37] So let me raise this question.

[00:32:39] And the conversations that's generated by talking about these events

[00:32:43] and raising these questions become super useful

[00:32:46] in terms of achieving a common understanding.

[00:32:50] And again, tying this back to Dora,

[00:32:52] you have this common understanding.

[00:32:54] You're able to make improvements.

[00:32:55] You're able to become a more productive team

[00:32:58] because you know what you're doing.

[00:32:59] I love that.

[00:33:00] In terms of helping us all understand a little bit more

[00:33:03] about event storming and really how accessible it is

[00:33:06] compared to how powerful it is,

[00:33:08] something that I think teams oftentimes overlook.

[00:33:11] And we've come in and looked like heroes

[00:33:13] with doing something pretty simple.

[00:33:15] For teams that are looking to get started,

[00:33:17] what do you think tends to make a big difference

[00:33:19] or what tips may you have?

[00:33:21] Well, the one tip that I think will probably make

[00:33:24] the biggest difference is getting a facilitator

[00:33:27] who's had experience facilitating event storming sessions.

[00:33:31] Yeah.

[00:33:32] Like I said, you might be hearing a lot of events all the time,

[00:33:39] but a facilitator is able to just smooth out the process

[00:33:42] for what you're talking about,

[00:33:44] what events you're talking about,

[00:33:45] and what you can focus on throughout the event storming session.

[00:33:50] Absolutely.

[00:33:51] I think it's similar to event storming,

[00:33:54] maybe more broadly.

[00:33:56] Facilitation skills are something that we have found

[00:34:01] being oftentimes very undervalued.

[00:34:04] And especially as the size of the organization grows,

[00:34:07] the number of people in the meeting that,

[00:34:10] because of maybe arguably good reasons,

[00:34:13] you need to have everyone there for context or decision-making

[00:34:16] or whatever, and you can't eliminate folks,

[00:34:18] getting the most mileage out of those meetings

[00:34:20] through someone who is described as a facilitator,

[00:34:24] someone that takes a little bit of extra work

[00:34:26] into preparing the meetings,

[00:34:27] the agenda, how we go about it,

[00:34:31] who needs to be there,

[00:34:32] how we get to the outcome of a decision that needs to be made

[00:34:36] or an action that needs to be taken is really key.

[00:34:40] As an aside, we had a guest on recently, Christoph,

[00:34:44] who talked about the importance of being intentional,

[00:34:48] about being rough with the things that you present

[00:34:53] as looking for feedback, right?

[00:34:55] And you mentioned when you gather the events

[00:34:58] from your business team or your customer-facing team,

[00:35:01] and then you put them into a sequence

[00:35:03] in order to solicit more questions

[00:35:05] or pushback or feedback,

[00:35:09] especially at large companies

[00:35:10] where we have a tendency to really try

[00:35:12] and polish up our slides

[00:35:14] like maybe a management consultant would.

[00:35:16] You want to do the polar opposite of that,

[00:35:18] and you want to make it look as much

[00:35:20] as like a fourth grader drew on a piece of paper

[00:35:24] because it, I think, lowers the barrier of discomfort

[00:35:27] to poke holes at something

[00:35:30] or ask questions about something

[00:35:31] if it already seems like it's maybe a half-baked thought

[00:35:34] or not fully formed.

[00:35:36] And I thought that was maybe like a good example

[00:35:39] of good facilitation

[00:35:41] and something that came to mind here

[00:35:44] around event storming

[00:35:45] where the value really comes from folks

[00:35:48] asking the questions

[00:35:49] and understanding the system better.

[00:35:51] And those questions not only help them,

[00:35:53] but they tend to help everyone else as well

[00:35:55] and make their way into your test suites,

[00:35:59] make their way into the architecture.

[00:36:00] Sometimes even make their way

[00:36:02] into marketing copy on the other side

[00:36:03] because that one person raised their hand

[00:36:06] and described it in a different way

[00:36:07] than maybe the first person did.

[00:36:10] So far we have, oh, sorry.

[00:36:13] So far we've gotten in terms of ways

[00:36:15] to take action and get control of Eudora,

[00:36:20] getting SLAs and SLOs.

[00:36:22] We talked a little bit about ways

[00:36:23] to improve how we're doing CICD,

[00:36:25] to improve our test automation using BDD,

[00:36:29] and then improve the overall context around the system

[00:36:32] using event storming.

[00:36:35] Anything else that comes to mind

[00:36:36] around things that we can do to get started on Dora?

[00:36:42] We've already covered so much.

[00:36:43] I think if we make incremental progress

[00:36:46] on the things we've talked about,

[00:36:49] I think the teams will be happy.

[00:36:53] We could spend a ton of time

[00:36:54] talking about incremental progress,

[00:36:56] and I feel like in the context of Dora,

[00:36:59] one of the things that really makes

[00:37:01] incremental progress really important

[00:37:03] is that there are benchmarks.

[00:37:05] Benchmarks with terms like elite

[00:37:06] and high-performing,

[00:37:08] and the reality is your team may not be there today,

[00:37:11] and any anxiety or friction

[00:37:14] about why your team isn't elite

[00:37:17] tends to be maybe in that toil bucket

[00:37:19] we talked about earlier

[00:37:21] in comparison to,

[00:37:22] hey, whichever level we're at,

[00:37:24] how do we get to the next level,

[00:37:25] and what do we have to do to prioritize those steps

[00:37:27] so that we have a consistent approach

[00:37:29] to incrementally arrive at that elite status

[00:37:32] tends to be more likely the way more,

[00:37:34] like a much more de-risked way to get there,

[00:37:37] and like you said,

[00:37:38] work with a much happier, more engaged, delighted team

[00:37:42] that tends to go build delighted products.

[00:37:45] Thank you so much for making the time for us today

[00:37:47] and giving us a little bit more of actionable steps,

[00:37:51] especially for the folks looking to gain better control

[00:37:54] on their Dora and make that incremental progress.

[00:37:57] What's a way that folks can get a hold of you

[00:38:01] if they want to follow up on this?

[00:38:04] Yeah.

[00:38:05] Unfortunately, I don't really have

[00:38:07] many social media accounts

[00:38:08] or any presence really.

[00:38:10] If you do want to connect with me directly,

[00:38:13] probably LinkedIn may be the best,

[00:38:16] but if anyone wants to leave comments

[00:38:21] related to this episode,

[00:38:23] I'm happy to read and reply.

[00:38:27] Awesome.

[00:38:27] And so we will have a link to that

[00:38:29] in the show notes as well.

[00:38:31] Thanks a lot, man.

[00:38:31] We'll catch you on the next one.

[00:38:33] Thank you.

[00:38:33] It was a pleasure.

[00:38:34] Thanks a lot for tuning in to the episode with Shing

[00:38:42] about ways to improve your Dora metrics

[00:38:45] through specific technical disciplines,

[00:38:48] leadership tips,

[00:38:49] and ways to bridge the organizational gaps

[00:38:51] to foster more engaged teams.

[00:38:54] If you want to hear more about Dora,

[00:38:57] check out the episode we did with Derek Ferguson,

[00:39:00] the chief software engineer at Fitch Group

[00:39:02] that shipped on December 10th, 2024 in the archives.

[00:39:06] And also for more facilitation techniques

[00:39:09] like event storming,

[00:39:10] check out the episode with Christoph Steinleiner

[00:39:13] that we shipped on September 24th of 2024.

[00:39:17] As always, we'll be back next Tuesday

[00:39:19] with another guest episode

[00:39:20] that talks about ways to foster more engagement

[00:39:23] on your product teams

[00:39:24] that ultimately lead to building more delightful products

[00:39:28] for your customers.

[00:39:29] Have a great week,

[00:39:30] and we'll talk to you then.

[00:39:38] Thank you for joining me

[00:39:39] on the Convergence podcast today.

[00:39:41] Subscribe to the Convergence podcast

[00:39:43] on Apple Podcasts,

[00:39:45] Spotify, YouTube,

[00:39:47] or wherever you get your content.

[00:39:49] If you're listening and found this helpful,

[00:39:52] please give us a five-star review.

[00:39:53] And if you're watching on YouTube,

[00:39:55] hit that like button

[00:39:56] and tell me what you think

[00:39:57] about what you heard today.