Why AI Is Multiplying Technical Burden

Hey everyone. Welcome back here to Techstrong TV. We've been talking up what's happening with Flowtopia this year.

It's a conference we always help promote. com audience, and as well as others, platform engineering, cloud native now. But Flowtopia is June 24th, so it's coming up in the next week or so.

And we've been featuring a lot of the key sessions that you can tune into this virtual event. I want to introduce two people who are also, again, two presenters at Flowtopia this year with a really great session. I want to introduce you to Craig Statham and Stephen Walters.

Craig, Stephen, welcome to Techstrong TV. Guys, thanks for joining us. Thanks, Alan.

Pleasure to be here. All right. Hey, before we jump into what you're talking about, let's find out, people always want to know who's talking to them.

We'll start with you, Craig, if you don't mind. Give people a sense of kind of who you are. Sure.

Yeah, happy to. Yeah. So I'm Craig Statham.

I've been in the software business now for well over 35 years. Majority of that time's been working as a distinguished systems architect for SAS Institute. But got together with Stephen a few years ago and started talking about value stream management and trying to understand how that works within organizations, and we had some really interesting conversations.

Excellent. Stephen, you? Same length of time in the IT industry, not that it shows.

My brief history, I like to say, I think I've done every role that exists in IT except for network engineer, because those guys just talk a different language. But right now, I'm a field CTO within GitLab. And I've had the pleasure of knowing Craig for even longer than I've been at GitLab, where we've done some fantastic and really interesting work together, producing the Value Stream Reference Architectures paper.

And our research is continuing through the community, with the community, and there's more exciting stuff to come in the future. But I'll leave that for another date. All right.

Hey, I appreciate it, Stephen, and thank both of you, actually. So you mentioned the Value Stream Reference Architecture, and you guys are really kind of the founders of a whole community built around this Value Stream Reference Architecture. It's formerly the Value Stream Reference Architectures Community of Practice.

Talk to us about that a little bit. So it started really as Craig mentioned. We started having this discussion about what value stream management actually meant and how you could actually have it in some sort of tangible way.

Back then, value stream management for software, for the IT industry, was still a bit squishy. It wasn't really properly formed. And Craig was interested to find practical and pragmatic ways in which value stream management could actually be incorporated into an organization.

And as a result of that, we started having lots of theoretical talks and discussions, and we had a few aha moments. " So we just decided to write it, and we created this thing called the Value Stream Reference Architectures, and it's built from there, really. We've had people follow it.

We've had people use it, provide us with feedback that's in there, and it's developed and grown from there. The headline concept of Value Stream Reference Architectures is it is a way for people to view their organization, using team topologies as a pattern language and graph theory as a tool in order to visualize their organization, and then to apply the inverse Conway maneuver in order to create a high-performing organization. I'll let Craig take over at this point here because he is one of those who's actually put it into practice within his organization.

Yeah, it was a real eye-opener because one of the things that we didn't really understand in my own organization was just how our teams kind of worked together and how they interacted. We kind of treated all of the teams the same, which sounds very equitable. We just treated all teams equally, and we didn't give them labels, and they knew what their roles and responsibilities were, but they didn't really know how to interact properly, and it just seemed to be problematic.

" And they just didn't know how they were going to achieve the outcomes that they wanted to get. So that was a key problem that I was sort of presenting to Stephen when we got chatting. " And that was what started the conversation.

I was like, "No, that's not a good answer. " And that's where we sort of just evolved some of these ideas till eventually, we stumbled on a model that we think is applicable to every organization that's involved in IT, and really has helped us to be able to reason about how we create good structures in orgs. I love it.

The Flowtopia Conference originally started as an in-person conference in Las Vegas. I think the last couple of years it's been virtual. io is the web address for the community on Circle and stuff.

Talk to us maybe about the relationship between your community of practice and the broader Flowtopia community. Yep. Both Craig and myself have been members of Flowtopia since day one, since the day it was created.

We both knew Helen from the DevOps Institute. Sure. I was a DevOps Institute ambassador at that time.

So when the Value Stream Management Consortium was created, and that being so close to my heart even then, I jumped straight in with both feet, joined Helen amongst that community. And really it's been a vital community, I think, in advancing these kinds of concepts and these kinds of ways of working. I don't think we would necessarily...

Well, certainly myself and Craig would not have had a platform to put forward our ideas without the support and help of Helen and the Flowtopia group and what they do and what they provide. Mm-hmm. So us creating the Value Stream Reference Architecture community of practice was born out of the work that we were doing with Flowtopia.

We just needed somewhere in order to concentrate that work on there. But we're very close in alignment with what they're doing within Flowtopia. A lot of the premise around what we do is linked into the value stream management implementation roadmap, which is something that they originally produced, in that it shows this concept to the right-hand side towards the end of the flow, where you've got this connect, inspect, and adapt cycle, which is very much around the technology and the tooling piece.

And it states that prior to that you have to do the mapping. Now we know a lot of organizations do that value stream mapping, and we as GitLab, we're one of those with our customers. We provide the mapping so that they can get the tool right.

But it was those former parts, it was the earlier parts of the organization where you identify the vision and you identify the people, and you set up the organization, because it's important for those parts to be in place before you do the mapping and the tooling. Because otherwise you're building a house on very, very shaky foundations. And if your organization is not set up efficiently, then your processes are not going to be efficient.

They're not going to be the best way of working, and then you're going to try and automate that within a tool. So all that technology is going to do is not just automate the good stuff, it's going to automate the bad stuff. And now that we've got AI coming along, which is accelerating that kind of work tenfold, a hundredfold, if you've not got those things set up right, you're going to be producing not just the good stuff tenfold, a hundredfold, but the bad stuff, the waste as well.

And we're starting to see that with some organizations in terms of the costs for AI, how much of that cost is going into producing additional technical debt, AI slop. And it's moving into a phase of what we're starting to call technical burden, where there's going to be a bit of a crisis, really, in organizations because their concentration is so much on developing and delivering as much code as possible through AI, but they're not applying all of the other elements around it, the governance, the security, the compliance, having the planning correct. If you've got that AI around that, then that works well.

But for that, you need an organizational structure that supports all of those functions and capabilities, not just leaving the developers on their own to go off and do what they want. Sure. Guys, I want to turn to your Flowtopia talk, if we can.

Your session this year. It's called Perspectives on Value. Stephen, let's give you a chance.

How would you describe it to our audience? The quickest way to put it to the audience is everybody has a perspective on value. There's supposed to be a definition of value, and you talk to somebody about value, and probably the first thing that comes into their mind is dollar signs.

But value means different things to different people. So what we're saying is your perspective on value is both right and wrong. Because it's right for you, but it's not necessarily right for somebody else.

Other parts of the organization have different perspectives on value. And the work that we've been doing with the VSRA has shown that VSRA can be at the center, at the core of a lot of other things. So we've mentioned team topologies, but there's also the work on flow engineering by Steve Pereira.

There's the work David Anderson has done on the value flywheel effect. And we're bringing all of those kinds of things together in order to show how to deliver things that deliver actual value. And one of the things that we're showing is that at its core, everything has two flywheels.

There is a flywheel for the utility, which is the thing that delivers. That's the software delivery capability. And there's a flywheel for the product, which is the thing that the business actually uses, what the consumer, the customer actually uses.

And so we dive into that. We dive into what those different perspectives are, looking at the value and basically asking people to understand different viewpoints, balancing those flywheels, and having empathy over agreement. Greg, how about you?

Yeah, to add to what Stephen said, one of the things I think organizations tend to get a little bit lost in is understanding where value really comes from and what is valuable. And when you're in an engineering organization, what's value to you is often the utility, right? Is the things that you're doing, the CI/CD pipelines, the technology that you're using, whether you're using Kubernetes or whether you're using different cloud providers.

And all that stuff sort of drains out the real value that you're really trying to achieve, which is what the user wants, right? What is important to the user? What is valuable about the product?

And so when you have this lens where you start to really appreciate that there is this difference, this perspective between value in the product and value in the utility, you can kind of see how they interact. And when we start looking at how we're going to use the utility to deliver value in the product, what we start to understand is that some of the focus we have to have in the utility is understanding what some of these different team types are, again, right? Brings us back to VSRA, and in particular, looking at things like platform teams and enabling teams that come from the team topologies pattern language that allows us to understand that those teams are all about sort of facilitation, enablement, and providing things as a service.

They're the teams that grease the skids, right? They're the teams that kind of make things happen. But they're not delivering product, right?

They're not focused on delivering product, but they are still important. And then when we switch to looking at the product, we can start to think about where do our value streams really lie? What is valuable to the end user?

What is it that we really need to focus on that's delivering that value? And again, what are the teams that are involved in that? So these two flywheels, they kind of drive each other, right?

The requirements we get from the product is driving what the flywheel of the utility needs to do, but the utility is really driving how that value's delivered. So the two things are inextricably linked, but they're different perspectives, and I think we have to have a broad perspective where we don't lose sight of either. And too often, I think engineering an organization is focused on the utility, and they're never really focused on the outcomes and the product.

It really is about going from project to product in Mick Curson's language, right? And understanding that. Get it.

Hey, guys, we're about out of time. 15 minutes goes really quick. First of all, again, thank you for the work you do in keeping the community viable and vibrant.

Also, thank you for presenting at Flowtopia this year. I'm sure it'll be a great session. And thanks, finally, for coming here on Techstrong TV and telling us about it.

Okay? It's been a pleasure. Thank you.

All right. Thanks, Al. Thanks, Alan.

Greg, Stephen. Thank you. You can catch them on Flowtopia, June 24th.

io, you get the full schedule and agenda. We're going to take a break here on Techstrong TV. We'll be back with more.