Automated Governance with Michael Edenzon

Carolyn Ford:

Welcome to Tech Transforms, sponsored by Dynatrace. I'm Carolyn Ford. Each week, Mark Senell and I talk with top influencers to explore how the US government is harnessing the power of technology to solve complex challenges and improve our lives. Hi, thanks for joining us on Tech Transforms. I am Carolyn Ford. Today I get to welcome Michael Edenzon, co-founder and CEO of Fianu Labs. And today Michael's going to talk to us about something that I've thought about to a certain extent, a super abstract extent. Let's be honest, I'm marketing guys, but I've listened to really smart people talk about this issue for years and not be able to solve it. And so what we're talking about today is automated governance. So you heard me write even though I stuttered, automated governance. And Michael co-authored a book called Investments Unlimited about this and has been working with some really smart people to solve these problems. So welcome to Tech Transforms, Michael, how are you?

Michael Edenzon :

I'm good. Thanks for having me, Carolyn.

Carolyn Ford:

I really appreciate you joining us today. Let's start off with, give us a little bit of your background.

Michael Edenzon :

Yeah. So I cut my teeth as a software engineer. That's my background, that's my trade. That's where my heart lies and where my sympathies are too. So the majority of my career was spent in the financial services industry where in the latter years I focused a great deal on governance and compliance of software releases in the context of bank regulations. So that's where I am. I'm a developer. That's where I get all of my inspiration from.

Carolyn Ford:

Okay. So I'm just going to bridge a gap right now between finance and government agencies. So many regulations, so much governance in finance that will certainly translate to government agencies. So let's talk about Fianu Labs. You guys automate software governance and bridge the gap between engineering, quality security and audit. Tell me a little bit more about that. What are your goals? What does that mean exactly? Because a marketer wrote that line. So tell me what it means to you.

Michael Edenzon :

Well, what it means to me, our goal is to make software governance accessible and easy. So if we did our job, compliance will go up, release cycle times will go down, developers will be happier and more productive. So Fianu Labs provides products that help you capture event metadata throughout the CICD pipeline, compare against predefined policy producing immutable attestations of pass or fail. Very simple, straightforward, easy to understand, and then ultimately provide the mechanism for automated enforcement of those policies. So taking all of the subjectivity out of the governance process and making it completely objective and reproducible so that you can make automated go or no-go decisions and then your audits are as easy as a simple click.

Carolyn Ford:

Okay. What have your biggest challenges been so far at tackling this mammoth goal?

Michael Edenzon :

Well, there've been a lot of challenges, but I think our biggest challenge right now is really elevating what it means to call something evidence in the context of software governance, I think a lot of the solutions out there, or a lot of the current thinking around evidence is, okay, what can we captured and not really what is the story that we're trying to tell at the end of this thing? And so our real focus in that regard is trying to get people to realize that evidence isn't just this random metadata that's captured from here and there, but instead it's going through all of the enrichment and providing all of the context that's necessary for an auditor to come and reproduce those results that you're using to base your enforcement off of. And so we'd like to get the community to a point where they have a higher standard for what constitutes as evidence.

Carolyn Ford:

Okay. So clarify for me what you mean by evidence and how that plays into the automated governance.

Michael Edenzon :

Sure. Well, when you look at a lot of manual governance right now, what passes as evidence could be something either just a manual attestation that said, yes, I did this, or a screenshot of the results to give some type of proof that you've done it and anything in between of varying degrees. And I've seen firsthand, and I've also heard many stories about organizations where a developer, and it's been uploading the same screenshot for the last 18 months and suffice to a particular specific requirement, and it was just checked off because they filled out the slot. Evidence is just, it's a CYA type thing if you're asked about it. Instead of evidence and it's integrity being the core of what the criteria is.

And so promoting evidence that allows you to define certain pieces like, all right, I'm saying that this event happened that I did this thing. What was that event? What did it happen to? What is the asset in question? When did it happen? When did it start? When did it stop? When did I observe it? How did it happen? What was the result? Did that result mean policy? How can I verify that data? So being able to fill out those slots as you capture your evidence in making all of those data points an integral part of the evidence that you're using to make these governance decisions.

Carolyn Ford:

Okay. So you just blew my mind a little bit. It never occurred to me that somebody would fake governance, but why not? When you think about all the controls in place, and I'm thinking about government controls specifically, I'm familiar with the NIST controls to a degree, and there's so many, and this showing that you're within compliance has to happen pretty fairly often. So yeah, why not say, yep, here's my COVID test, it's negative, and use the same photo over and over all year long. I didn't do that. So is that what you just told me, that developers are responsible to prove their own compliance with the governance and sometimes they fake it?

Michael Edenzon :

Well, yeah, and I don't mean to say in a malicious sense. I'm not trying to indict anyone here, but developers are-

Carolyn Ford:

You got to just do your job.

Michael Edenzon :

Yeah, it's a do your job type thing. And developers want to be productive. They want to get the job done. And oftentimes proving compliance stands in the way of that. And so what ends up happening is absolutely, there's a disconnect oftentimes between the stakeholders that are responsible for enforcing a control and the party that is responsible for producing the evidence of that control. Because the stakeholders oftentimes aren't in the weeds enough to actually get the evidence. So they rely on the developers to produce it. And so developers are going to do what developers are going to do, which is get the job done.

And so in some cases, in large organizations, they're able to squeak by with things like that. And I've seen it in varying degrees sometimes just a simple, just this one time. In other scenarios I've seen it where it's been a pretty long-running pattern of behavior that was really hard to catch because oftentimes the people that are responsible for doing the manual work of enforcing the integrity of this evidence simply can't keep up with the amount of software, the amount of changes to that software and the number of developers that are making those changes. And so naturally, things are going to slip from the cracks.

And that's one of the reasons why I think our focus is really to elevate what evidence means. Because if you get that piece right, that'll answer a lot of those challenges right off the bat.

Carolyn Ford:

Yeah. So we baseline what the evidence is, and then we automate that audit trail. So we're improving security, we're improving productivity, and we're able to scale. The manual stuff, like I said, just the few controls, which are hundreds that I've seen and I'm slightly familiar with, it's overwhelming to think about how anybody can keep up with this. Okay. Let's talk about your book, the book that you co-authored last fall, Investments Unlimited. Who was your co-author, curiosity?

Michael Edenzon :

Oh, we had a couple co-authors. So Helen Beal, John Rzezotarski, Caleb Queern, Bill Bensing, John Willis, Topo Pal, Jason Cox. It was quite the list of people.

Carolyn Ford:

Okay. Village.

Michael Edenzon :

Yes. But all of them were great collaborators and have really, everyone brought their own in the weeds stories to the book. So I think it was a large roster, but it meant that we covered a lot of scenarios in the book.

Carolyn Ford:

So give us an overview of what the book is about specifically.

Michael Edenzon :

Sure. Well, Investments Unlimited is a fictional story, it's a novel about a fictional bank called Investments Unlimited and their journey to automated governance. So as they cross a certain threshold, they were a smaller bank that became a bigger bank. And when they crossed that threshold, there were a heap of new requirements that were put on them, and they really were not able to keep up with those requirements. And so in the face of an MRIA, which is a pretty severe ruling from a regulator, so in the face of an MRIA that they needed to remediate, it was a race against the clock to find a solution. And their approach was more holistically, which was to build automated governance into their software release procedures.

And so it details, but I won't give away the ending, but it really details not just the technical piece of how to get it done, but talking about the organizational side of things and how do you get all of these different silos, risk, audit, security, quality, engineering, executive leadership, everyone to buy into this same shared language and agree on this new paradigm for governance and enforcement of these policies.

Carolyn Ford:

You just touched on something that I meant to ask earlier about. So if you have managed to automate some governance, have you?

Michael Edenzon :

Yes.

Carolyn Ford:

Do you have some automation in place? Okay. So you just listed a whole bunch of different, essentially business groups, well, some of them. How did you get them to trust the automation?

Michael Edenzon :

Well, that's a really good question, and I think this is going to vary from organization to organization. I've seen organizations where one group was really against that whole idea because they were really well-adjusted to the manual process. Oftentimes in that scenario, the group that's most defensive of the current state are not the ones that are bearing the brunt of what that entails. In other organizations I've found where those groups that are traditionally more reluctant were first on board in leading that change. I think it's different when you go from organization to organization, but I think the way that we found applies best across the majority of organizations, is to first get everyone to write down what they're responsible for, how they go about achieving that. So for example, if you have a security director whose team is responsible for vulnerability, remediation, and time to remediate among other things, and part of that is ensuring that applications of the highest risk tiers are not allowed to release to production with certain higher critical vulnerabilities.

And they're responsible for making sure that that's the case prior to every release. So they sit in your change advisory board, and when an application release comes up for question, they attest that, yeah, they have no higher critical vulnerabilities subject to the policy. That's a very common use case. And in that scenario, the first question would be, all right, what are you responsible for? Okay, making sure that no applications of these risk tier's responsible for, or are able to release with certain vulnerabilities. And then how do you go about deciding that? Well, we read the security results, so whether it's SaaS or PaaS, or any of these tools. So if you get them to write those things down, which many times in large organizations, those aren't really written down or published anywhere, but if you get them to write them down, then you can put it in code.

And if you can put it in code, you can automate the collection of the evidence, automate the production of the result. And I think in that sense, if you're able to walk them along and bring them along on that process, you can say, yeah, here are your own words. We just expressed it in code. Now your entire decision making process is automated. And at first they may not trust it, they may need to do their own checks and verifications as they should, but in the long run, it's really a play for efficiency for them as well, because as I mentioned before, they're a stakeholder in this and they're not scaling commensurate with the scale of software that's being built and the number of engineers that are being added. So they need ways to have efficiency too. And so when you bill it in that regard, getting people to buy into this as a way that they can better do their job, we found that to be the most successful starting point to getting organizational buy-in.

Carolyn Ford:

Well, I'm guessing that the automation comes with a report, with an evidence trail that they can just look at and trace back. So they can not only spot check, but they could have this report and look at, I guess that would be one way they could spot check is just look at that evidence trail from the automated report. Is that-

Michael Edenzon :

Yes.

Carolyn Ford:

Okay.

Michael Edenzon :

Yeah.

Carolyn Ford:

So you are not just automating government mandated controls. You are talking to business line owners and automating what's important to them, which often, obviously they have to check these boxes so they don't get the, what's the banking, the bad thing that happens in banking?

Michael Edenzon :

Oh, an MRIA.

Carolyn Ford:

Yes.

Michael Edenzon :

A matter requiring immediate attention.

Carolyn Ford:

There we go. So they don't get that, but it sounds like they can even say, okay, these are some of, for this organization, here are some security checks that we need to make sure that we have in place.

Michael Edenzon :

Yes. And exactly right. And there are sometimes where, and you have pre-prescribed controls like the NIST or Mitre controls in other scenarios. And this is a case that's very common in a lot of different organizations in different regulatory environments. A lot of times they're audited based on their adherence to their own policies and procedures. And so that's where, when it comes to be the biggest hiccups for these organizations, it's because they've got these own policies and procedures that they need to enforce as well, that tend to add to that burden.

Carolyn Ford:

Okay. So is automated governance related to, or even is the authority to operate part of automated governance? How does that fit in?

Michael Edenzon :

Yeah, so the way that we think about it, it's separate from the authority to operate, but the way that we like to say is that it is a method for achieving the ATO. So it can accelerate your ATO process and it can help you reach it faster. But what automated governance really is, is a means of achieving continuous ATO. And it's important to note that automated governance is not automated compliance. It's automated evidence capture.

Carolyn Ford:

Got it.

Michael Edenzon :

The automated evaluation against policy to produce a repeatable result, and then the automated enforcement of that policy, meaning stopping something that that it's going to happen from happening because it either met policy or didn't meet policy. And having that all be machine led, so there's no manual attestations, which changes everything from being subjective to objective.

Carolyn Ford:

So you're working with organizations right at the very beginning, the inception, and you're baking this in to the code, their requirements, so that will, in the end, achieve a continuous authority to operate within the government, continuous or automated governance for commercial organizations. Yeah?

Michael Edenzon :

Yes. And I think once that's off the ground and once that's been rolled out, I think that the upkeep of compliance becomes easier because naturally now, if you talk to any developer in a regulated environment, when it comes to the things that they're required to do in order to make a change or in order to make a release, one of their biggest challenges is not, it's not doing that thing. Oftentimes, doing the thing is relatively simple. The biggest challenge is knowing all the things that they're required to do, because you know how it can be with these regulations, sometimes it's more of just word of mouth. And so it's not clear to them off the bat, it's not transparent what needs to be done, what do you need as a result of that? How is it being evaluated?

And then what am I able to do once I complete it? And so, one of that, those core principles of automated governance is policy transparency. So once you get to that point where you've reached some homeostasis and compliance, it's very easy to keep it now because developers know exactly what's expected of them, and then they're able to go and do those things to achieve that compliance.

Carolyn Ford:

So I'm thinking about creating an organization, an agency from the ground up, and it's like, okay, so we're building this organization, we've got these blueprints that include all of this. So much easier in my mind than taking a mature organization that's got everything already built out. How do you inject this? Because you're talking about you have to start at the code level and build it out from there. So how do you inject this into the mature organizations?

Michael Edenzon :

Yeah, that's a great question. It starts with taking inventory. So you can't govern the things that you can't see. And a lot of times there are pieces of software that are being built and pieces of software being shipped that aren't easily accounted for, for all of the things that concern them. So one of the things that we do first when we go into our organization to set up Fianu or to just even begin that automated governance process, I've seen companies do it very successfully as an internally built capability as well. But the first thing that needs to happen is knowing what's being built and what's being shipped, and being able to trace that all the way from the code repository to the commit to pipeline job that produces the deployable artifact and then the pipeline job that ships it.

And so once you take inventory of all the things that are building and all the things that are shipping in your organization, then piece by piece, start to check off different controls. And a lot of times as those controls are being serviced currently, they use a variety of different tools in the tool chain. So if you have inventory, then the next one is just take one piece, one piece of the tool chain that maybe suffices three or four controls, and then start to roll those out as deep into the company and gradually over time you're able to scale up to these controls pretty quickly I'd say if you have accurate inventory.

Carolyn Ford:

So let's just take a banking institute that's been around-

Michael Edenzon :

Investments Unlimited, let's use Investments Unlimited.

Carolyn Ford:

Let's use Investments Unlimited, let's say it's, well, you said though that they were a new bank.

Michael Edenzon :

They were an established bank that they crossed a threshold that vaulted them into a new set of regulatory requirements.

Carolyn Ford:

Got it.

Michael Edenzon :

The same problems that come from years of doing it the old way now suddenly subject to a whole host of new requirements.

Carolyn Ford:

So Investments Unlimited is going to tell me the story of how you were able to achieve automated governance in an established organization. Is that-

Michael Edenzon :

Yeah.

Carolyn Ford:

Yeah. Okay. Tell me one of your favorite horror stories from Investments Unlimited.

Michael Edenzon :

Well, there is a scene in Investments Unlimited where the engineering team that's tasked with implementing a somewhat technical solution to the problem, which became automated governance, is at a briefing with leadership and the engineering team starts to write on a board and say, here's the progress that we've made. And they talk about onboarding applications. And there's a huge dispute in that meeting over what the denominator of applications are. So the executive leadership says, I don't care that you onboarded 300 applications. What's the denominator? And the team struggled to produce the denominator because they didn't have that inventory. And so-

Carolyn Ford:

What do you mean denominator? A common...

Michael Edenzon :

So let's say Investments Unlimited had 500 applications to the company, and the team said, well, we onboarded 300. And the executive said, it doesn't matter. What's the denominator? Well, the denominator was 500, but they really struggled to realize that because they didn't know how many applications were building, so they didn't know how far along they were in onboarding. And so they go along this path, which I've seen in practice that that's really tempting, which is let's just automate the governance right away. And that's great, but you end up not really knowing how much of the established organization's applications you've covered because you've never taken inventory. And so there's a big confusion about that, which I think, I hope it's a scene that will resonate with the folks that have been in those types of meetings, but it does underscore a pretty important and uncomfortable challenge, which is you first have to know what's out there, what you're building and what you're releasing before you can start automating the governance for it.

Carolyn Ford:

How does an organization go about mapping that? I know there are tools in Investments Unlimited, in what you do with Fianu, do you use industry tools to go in and discover the IT environment?

Michael Edenzon :

Yeah, that's a great question. So we try to do it based off of observing things that happen. So observing what gets built in a pipeline, observing what gets published to an artifact repository, observing what's running in production. And so at one of those places, if we build something but never saw it released, that tells us something. If we build something and never saw it get published, that also tells us something. If something was published that we didn't see build, okay, now we're starting to understand that came from somewhere. If something was released that we didn't see get built or published, tells us something as well. So we provide those tools and the capabilities for an organization to start to fill out those different slots. But what it comes down to in that sense, is a lot of times on the organizational side where you may have a large organization, and this will sound very familiar in the government space, where you have five or six different pipeline platforms.

You've got Jenkins CI, CircleCI, GitHub Actions, or GitLab CI, CloudBees Jenkins. You could build a application on many different CI pipeline platforms using many different pipeline libraries, and you can deploy it on equally as many different deployment platforms. So what you find are that the number of different permutations of ways that you can reach production with an application at a large organization with all these different pipeline and SCM instances is a lot to manage. And so, one of the things that we encourage on the organization side for cleaning that up is trying to establish official paths to production.

So official shared libraries where you can, and you can control what's being built and what's being published, and then use the appropriate tooling to observe it and categorize that in your inventory. But that's one of the biggest tech debt challenges that we see at large organizations, that they just have a sprawl of different ways to build and release. And automated governance will help you consolidate it, but it still is an organizational challenge that you need to work on. And so that's one of those pieces that we highlight in the book that I think many will relate to if they work in those large organizations, because that's what really leads to some of the most nerve-wracking questions during audit is when you're not sure exactly how things got billed or released. But does that answer your question?

Carolyn Ford:

Yeah. And for our listeners, it sounds like if this is one of your challenges, this is a really good book to read. So I want to shift gears a little bit before we run out of time. I got to talk to Dr. Stephen Magill, such a fun interview. He was so patient helping me understand a lot of things about application security and open source, but he actually shared with me that you guys are co-authoring a white paper focused on software asset inventory. The inventory, you've already mentioned it. So tell us a little bit more about software asset inventory and maybe even how it fits into, it's obvious, tell us how it fits into automated governance.

Michael Edenzon :

Well, I think you're right in the basis of basic inventory and just knowing a piece of software where it's building, where it's releasing and knowing it exists. That's inventory. But we've got a great group with Stephen and a few others as all part of that IT revolution group of authors. And what we really set out to do is say, okay, it's great to know about all these things, and that's a foundational piece of doing automated governance. But we've noticed at companies that we've observed automated governance and that the efficacy of automated governance is still somewhat hindered by what is known about these software assets. So we may know a software asset exists, we may know that this code repository produces this artifact and it's released in these environments. And that's great. That's basic inventory, knowing that that exists. Knowing anything more about that is where the challenge comes in.

And the current model of asset inventory comes from the CMDB, which is a hot button issue. So I will say this, that the CMDB is a model that's stood the test of time. And for the 20 or so years that it's been in operation as the standard method for keeping track of software assets, it's done its job. But for the next generation of asset inventory, which leads downstream to automated governance, the CMDB tends to fall a little short. It's not native that it keeps up very well with microservices or serverless functions or micro apps. It's more suited to the monolithic application. So I'll give you an example here, which is, and again, we'll use the fictional company of Investments Unlimited, and they may have 500 applications in their CMDB. And one of those applications is the online banking experience. And the online banking experience is one application in the CMDB, but it might have 300 microservices.

And so if you have a specific policy, and I'll use just an example. The Investments Unlimited has a policy that says that any code that affects the movement of funds must undergo this completely elevated set of controls, higher level of requirements and scrutiny because there's a greater risk associated with changes to that code. Well, the current CMDB inventory model just paints such a broad brush that all 300 services in that application are now subject to the strictest level of policy because maybe 10 of those-

Carolyn Ford:

Over classification.

Michael Edenzon :

... microservices, yeah, that 10 of those microservices affect movement of code. Or say another example of services that might be internet facing, so an internet facing versus an internal facing application also have a different risk profile. So why is that set just at the CMDB application level when it can be far more granular, but when it gets far more granular? Now, you may have, Investments Unlimited might have thousands of services that need to be accounted for. So instead-

Carolyn Ford:

And at that point, are you having to dive into the software bill of materials to really understand, or no, the software bill of materials is different, isn't it?

Michael Edenzon :

Yeah, the software bill materials is an important part of inventory because it tells you for a particular asset what it's made of. But in our sense, when we talk about asset inventory, we're more so talking about the relationship of software assets to one another. So if we talked about a software that was deployed that is internet facing right now in the current CMDB model, it's someone's job to twice a year go into their CMDB platform and attest, yes, this is still internet facing, and the moment they click save, that information is static. It may be correct, it may not be correct. Oftentimes I've seen that-

Carolyn Ford:

Could change.

Michael Edenzon :

Yeah, it could change.

Carolyn Ford:

Yeah. Okay.

Michael Edenzon :

Yeah. And so our approach really says, could we apply some of the automated governance principles, which is independent machine led observation, context driven enrichment and immutable traceability to provide a continuously updating inventory. So in that internet facing service category, instead of having a twice a year attestation, why can't you just hook up to the load balancer to detect if that services connection is configured for outward internet traffic? And so have it be something that's empirical and deduced from the properties of the application in its running state to define the application, not just by its name or who owns it, but the properties that it has. And what that ultimately leads to with automated governance is a way to provide very tailored and specific policy so that you're doing all the things that you need to do, but you're not overdoing it for applications that don't need it. So really squeaking out that last bit of efficiency when it comes to governance and policy enforcement.

Carolyn Ford:

Yeah, you're improving security, you're improving productivity. It's scalable. The biggest thing in my mind is, I'm a cybersecurity girl, so I'm thinking about being able to continually see what this thing is doing rather than relying on a screenshot that was taken last year, my COVID test, that one photo.

Michael Edenzon :

It's a good example.

Carolyn Ford:

Yeah, but you're seeing it in real-time, you know what it's actually doing right now? Or is that too, am I being too aggressive with that? Is it really real-time or is it like there's a heartbeat that you check in every so often?

Michael Edenzon :

Well, it certainly should be. I think that's one of the things that we really work on at Fianu, is making it something that's truly event driven in real-time with this singular data source.

Carolyn Ford:

Yeah.

Michael Edenzon :

So, that's really where, because the reason why is because it can be, it can be, so why shouldn't it be?

Carolyn Ford:

Okay. So time has beaten us, as always. Before I let you go, and before we move to our tech talk questions, is there one thing that you want to leave our listeners with when it comes to automated governance? Where do they start? Or let me just stop there. What's the one thing you would like to leave our listeners with?

Michael Edenzon :

What constitutes evidence needs to change? There needs to be far more scrutiny and a closer look at evidence and whether or not it truly answers the questions that you need to ask.

Carolyn Ford:

Okay. All right. Well, let's go to our tech talk questions. These are the fun questions that I get to ask you just quick, quick answers. So first question is, what's one thing your business did that you didn't expect?

Michael Edenzon :

There's a lot of things, but I think the one that was an exciting surprise I think, our background is in financial services and just how quickly this automated governance solution was able to apply itself to a myriad of regulatory environments. And so that was something that was exciting to us, and I think it really did reinforce our belief that the majority of all of these software governance principles are shared across every regulatory environment regardless of what regulations or guidelines your organization is subject to.

Carolyn Ford:

All right. So I'm always looking for something new to read or watch. So what recommendations do you have for our audience? Or really, let's be honest for me, podcasts, TV, books, movies.

Michael Edenzon :

Yeah. So one that really comes to mind is Toyota Kata, and it's a book, came out probably about 20 years ago, about why Toyota is such an incredible manufacturer and how they're able to respond to evolving changes in the industry. And it talks about this scientific method for continuous improvement, culture of learning, focused on process, not just the result. And it's a great book that has a lot of similarities with software construction and engineering at scale.

Carolyn Ford:

So I haven't read the book, but it's been referenced in several other books that I have read. Isn't Toyota the one that came up with on the assembly line, if somebody sees something wrong, raise your hand? That's them, right?

Michael Edenzon :

Yes.

Carolyn Ford:

Yeah. Okay.

Michael Edenzon :

So a great deal of autonomy at the lowest level of the organization-

Carolyn Ford:

Yeah.

Michael Edenzon :

... the core pieces of that.

Carolyn Ford:

Yeah. Okay. Good one. Anything else? Any other recommendations?

Michael Edenzon :

Not that come to mind. I'll tell you, I'm excited about my next book that I'm going to read, which is, it's called Failure Is Not an Option, it's by Gene Kranz, who is the flight director for the Apollo 13 mission. So I'm excited to get that one started.

Carolyn Ford:

That's a good one. I'm writing that one down. I'll be adding that to my personal list right after this, as well as Toyota Kata. Did I pronounce that right? Toyota Kata. Okay. Well, Michael, thank you so much for spending this time with me and with our listeners.

Michael Edenzon :

Yeah, thanks for the chance to join. I appreciate it.

Carolyn Ford:

Yeah, and thank you listeners. Please smash that like button, share this episode, and we will talk to you next week on Tech Transforms. Thanks for joining Tech Transforms sponsored by Dynatrace. For more Tech Transforms, follow us on LinkedIn, Twitter, and Instagram.

Share Episode

Shownotes

Key Topics

Quotable Quotes

About Our Guest

Episode Links

Transcripts

Follow

Links

Chapters

Video

More from YouTube