Unlocking Developer Productivity With Peter Kreslins

This is Textron tv. Hey guys, thanks for the throw. We're here with Peter Kreslins, who's CTO for Digby, and we're talking about the impact platform engineering is having on developer productivity is a ongoing debate, shall we say, and we're gonna dive into it.

Peter, welcome to show. Thanks for having me, Mike. We hear a lot about platform engineering these days, and some folks that view it as a rational effort to kinda help us manage DevOps workflows that scale better.

Um, other folks think of it more as a conspiracy to, uh, bring back centralized it at the expense of all those developers who have prized their freedom over the years. What is your sense of what's going on here in these conversations? 'cause sometimes I feel like both sides are talking past each other a little bit.

Yeah, yeah. That's a great point, Mike. Um, I, I, yeah.

As any new concept that we are trying to leverage, uh, we need to clarify things, right? We need to understand, uh, what's going on, what we're trying to achieve, right? So maybe thinking about the, uh, definition is, is a, is a good way to start, right?

So, so we can kind of dissect or unpack it, right? So it, the whole thing about platform hearing is that we can actually give developers self-service capabilities, right? Doing that while we are reducing their cognitive load, because there's a lot in their shoulders right now.

And we wanna reduce that, but we also wanna govern that better. We wanna give companies the, the standardization, the governance practice practices that are much needed, right? So the way I think about it and, and connecting back to your question is maybe there is both sides are right in the ways that they're seeing that because, um, if we wanna move faster in organizations, especially when we get larger, we need to give teams the autonomy they need.

And that's what developers want. They really want to be able to perform their jobs, solve business problems without the friction, without the boilerplate, without anything that is comes their way. Mm-hmm.

Companies cannot do that on a free for all manner, right? So they really need to apply security principles, governance principles, standard principles that would make it work at large scale. So I think it's a, it's, um, maybe it's a mix between the, both, both worlds that we need to better understand that is going to give us the results that we want, both, both from giving developers the autonomy they need, but with the right context.

Autonomy with the context without context is nothing, right? So really giving them those golden paths as, as platform engineering, uh, uh, uh, uh, people usually usually like to say, this is the golden path. Well, within this golden path, you have the autonomy you want and you need, but please follow the rules because we are going to be accountable for them, right?

So, so I, I I think that's, that, that's a good start, right? So, uh, finding the right balance between those two things is, is really what we need to, we need to do once we are introducing this new concept, right? So it has to be more voluntary than it has been in the past where centralized it is tended to want it to say thou shalt a lot.

And developers, once they hear those two words, they go in the opposite direction. Um, I guess, how do I maintain some level of sanity and still allow the developer to add a new tool or experiment with a tool? Because, you know, they always want to play with something that they decide is gonna help them innovate or make their life easier, um, without, you know, making them all feel like they're, you know, rebels.

Yeah, Yeah, exactly. And innovation. Is that right?

I really wanna try more things. Um, I think it starts with not trying to figure out everything at once. So, uh, a very interesting concept with, with the whole platform thinking is the minimum viable platform, right?

Which means we, as platform engineers, we are not trying at firsthand to come up with every single possible path possible thing that you, you, as a developer wanna do. We are really trying to enable you and, and give you that, uh, headstart so you can perform your job better. So instead of defining things, maybe defining the structure that will define things, define the ways of working that we will allow for that type of, of, uh, uh, uh, capability, right?

So, um, is there, is there a practice that I need to follow in order to select, um, a, a database from my microservice? Is there a set of database that has been already tested throughout the organization that I can practice with? Or if not, can I suggest one that will fall into the practices that the organization expect?

Right? So I, that's why I like the idea of the golden path and, and really paving the way without telling what's going to happen within that path, because that's what creativity comes in, right? I'll come across problems.

The, the microservice, the problem that I'm trying to solve with technology. Um, um, I'll, I'll need to figure it out. Maybe I need something different that has not yet been defined, right?

But maybe for all the other stuff that I really don't wanna spend my time thinking about it. And maybe we, we really don't want creativity there. Well, those are the things that we really need to define.

Why do I need to think all the time about how I should scaffold a a new project? Well, I don't, right? Uh, this, this has been defined, uh, throughout the organization.

The, the basis of what I need to do in order to build new capabilities. Are there, well, now on top of this, this is what I'm going to, uh, innovate on. And this is what we, I'm going to define, right?

So I think the difference from the past is that in the past, we really tried to define every single possibility. And, and that was the mindset that we had, right? Uh, the design, everything before starting, right?

Uh, separating clearly those stages. Well, guess what? They are all interconnected, right?

Because we are building, we are modeling, we are, we are defining what we're going to do while we are thinking about the business problem, right? So, uh, uh, so it's finding that balance that I think with platform engineering, we, we are getting there, right? We have the path, we have the concept, the product concept, the modern product concept like MVPs, right?

That helps us achieve that type of, uh, um, um, structure, right? We harp a lot around developer productivity is kind of the reason for doing this. And I scratch my head because, well, a lot of developers I know would say, who you call it unproductive, we're perfectly productive.

The real issue is, you know, you guys have these convoluted manual processes in the DevOps teams, and you're just getting in the way, and basically they're saying, you know, your approach is broken. Go fix it. Yeah.

Um, well, productivity is at huge scrutiny, right? At this point in the market, right? So everybody's talking about it.

There is a lot of, of heated discussions around it, right? And, and, and I, I, I can understand, right? I think, I think that, um, I think it's twofold, right?

We need to think about from a developer perspective, and we need to think from a business executive perspective, right? From a developer perspective, um, it's really cumbersome to get to an organization and really not understanding what you are supposed to do. How do you find yourself, how do you understand the processes?

How do you get a bigger picture of the architecture? Where do you find documentation? How can you connect with APIs easier?

How do I know what is available, right? So you as a developer, although you can productivity, productivity can talk about you as a profession, maybe you need to think differently. You need to think about how do I get into this complex body of people that needs to interact, that needs to understand each other, that needs to avoid stepping each other's food, right?

Feed. So platform engineering principles and platform and, and internal developer platforms can help with that and can give developers a much better experience on these larger organizations because now it's easy for them to start doing productive work, right? Um, so this is one, if we look at from, from an executive perspective, if you're not funding teams that are thinking about the ways that your organization work, you are missing the point.

It's not just throw money at where, uh, teams that are designing the new shiny thing, it's actually think about how these teams work. It's actually think about the flow of work. Don't we want speed and some sort of predictability?

That's what the business asks for us, right? So we really need to spend time and invest on these things so that they, they are better, right? So, so I, I really believe that there is a lot of confusion around it, but as we start to clear these things out and we start to practice, we are just starting these things.

There's a lot of vendors, and it's not, not just buying a software too, it's actually embracing the methodology, right? I think we are going to, uh, um, um, make more sense of what is possible, what's not possible, what's hype, what's not hype, and actually serve both needs from a developer standpoint, from an executive business person standpoint, so we can achieve this faster flow, right? Um, do you think the rise of AI is gonna force this conversation anyway?

And I ask this because it seems like if we want to take advantage of ai, we have to aggregate more data, and then we have to train the model. And the only way to aggregate the data, I think is through some sort of platform engineering motion. Yeah.

Yeah. No, AI is a, AI is, is, is a very important aspect of it. Um, well, let's take, uh, the a GI, uh, craziness out of this equation, right?

Let's, let's assume for, for, for quite some time yet the, the human element is there, right? So, so gen ai especially, uh, especially for the, the developer, uh, community is, is is there as a tool, right? Is there as a tool that is going to increase productivity by orders of magnitude, right?

So it needs to be seen as this, um, um, companion body, digital body that you have by your side that is going to deal with these cumbersome processes that you need to deal, right? So you should just interact with that thing, and it'll help you with the, with the work that you are not supposed to do, and actually you don't like to do, right? Um, but yes, training those models and understanding better what is within the organization is very important too, right?

So connecting a little bit what DGB does, right? We are, we are an integration platform. Um, we, um, uh, we also see and apply a lot of platform engineering principles to our own product because we also believe that integration is something that, that you don't need to spend your time on.

You, you, you come across integration problems, and you need to solve that in an easier way. And the platform should do that for you. And one of the cumbersome processes is documentation, right?

So documentation is something that no developer wants to do. It's a cumbersome process. It's, it's boring, right?

So Gen AI is actually helping us, uh, uh, improve documentation and actually do a documentation for free, right? But this is one part of the story. The other part of the story is that once you have more documentation and you continue to train or, uh, uh, add to the models, well, now you know about the organization, or you can ask questions about it.

Now, imagine I'm a developer and I'm trying to solve a business problem, but I need to figure out what's going on within the organization where I can find specific data who knows about things, right? Well, guess what, this information is not readily available. So a pretty important part of the platform engineering and this internal developer platforms is to actually expose that information in a way that is easily searchable, that is catalog, that you can actually find relevant stuff so you can perform better your job.

Again, back to the speed. You don't want your developers spending spending time on what's not leading to more value. You actually want them focused on shipping value, delivering value.

If things come across them that is not helping with that, well, you better remove it, right? Is there another phrase for that other than developer productivity? 'cause once you start tossing that around, people start thinking about, oh boy, they're back measuring lines of code and all this other business, right?

And ultimately, I think what we're talking about here is, um, the, all the things you need to do to write code shouldn't get in the way of the moment that you're inspired to write that code. Yeah. Yeah.

Um, yes. And, and there are many names, right? Um, I, I, I, I, I, I actually don't like the developer productivity name, right?

I, I know why, why it's there. And I think we are on an efficiency plane, uh, uh, play across the world, and no doubt, we, we are spending a lot of time questioning productivity, right? I, I actually think that it's more related to, um, the experience, right?

What experience we are giving, the actual people that is growing the business with technology, this is the most important people that is actually helping the business do more, uh, recombine, uh, find new avenues for revenue. These are the people that are going to deliver that. Because every single business is, is a technology business these days, right?

So if you're not thinking about how they perform their work, the experience that they're facing, are they actually being effective? Can, is anything coming across their way if you're not spending and funding these things? Well, we as executives, and I can say that I'm, I'm an executive with my own organization, right?

Well, we are not doing our jobs. Mm-Hmm. We are not doing our jobs.

I'm a, a, a huge proponent of the topologist concept, right? From Manu PIs and, and Matt Kel, right? Um, and, and, and, and, and they figured out exactly that.

If you don't think about the actual structure, team structure, people structure, you are going to ship your inefficiencies. And those efficiencies will come your way, one way or another, one way or another, either because you, you have a two centralized, uh, uh, old model that is just slowing you down, or because you have a free for all where Yeah, yeah. Well, here, everybody has the, uh, uh, uh, allowance to do whatever they want.

Well, guess what? They're going to come up with 20 different languages, 20 different database types, no security standard whatsoever. Now, maintain that thing, right?

So finding that balance and focusing on how we actually work and obsessing why in improving the way we work is an executive big problem that that person needs to solve, right? And communicate back to the business, because the hard part is selling back to the business why we should fund these teams and, and, and being effective in showing, Hey, listen, yes, guess what? That's how leading organizations do.

And not only because of that, I will prove that if we invest on these things, we are actually improving our processes. And guess what? We are shipping faster.

We are shipping more predict with more predictability. To your point, how do I make this transition? Because so many organizations have invested in their existing CI/CD platforms for years.

They have customized them to no end. Um, do I need to throw the baby out with the bath water and start over again? Or is there some other way to get at this that maybe doesn't require as, uh, drastic a step?

Yeah. Yeah. I, I think all drastic steps are very problematic, right?

Uh, people usually backfire those, those initiatives, right? Uh, it's, it, it, it should be incremental. I think, I think, I think the incremental mindset was a big leap for us as, as, as as subject practitioners, right?

So I would say, uh, start small, right? Start small and, and think about, I, I think this is the whole concept of a minimal viable platform, right? What is the minimal things that you need to do that will already give and bring a lot of value?

And these minimal things might be, well, we do have A-C-I-C-D tool chain already in place, but maybe we are exposing too much of that complexity to our developers, and they don't need to understand all that. They actually don't care. So why don't we add that as an automation principle?

So with the push of a button, they now have everything in their, um, next environment, right? So may maybe start with those things that are taking a lot of time today. You, you will, you, you, you, you're keeping the investments that you did, you're just abstracting that away with a platform, right?

But you are improving the experience, so you're not exposing the internal details. That's why you should invest in platform engineers, because those are the people that are going to think about those things, right? They're not just there to ship or to get the new tool, the new shiny tool.

They're actually product minded people that have internal, uh, customers that they want to improve their work. I care about them. My success, that's what I tell my platform teams, right?

Your success is actually having the other team success, right? Once you improve their words, once you enable them more, you are actually doing your job, right? So, so, um, I don't think we need to rip and replace.

I don't think we need to start from scratch. I think we can actually leverage what has already been done. It's actually a consequence of doing DevOps well, right?

But now adding more layers that are actually improving the way people work, right? You need to think about more things, right? So if you look at the spectrum of what an internal developer platform do, it's a lot, right?

And it can do a lot. So it might feel overwhelming. Start small.

Figure out the top five things that are slowing you down as as, as a develop development team and focus on them. Start with that. All right, folks, you heard it here.

Perhaps it's simple. Find out what brings you joy. Start there, define it, and start working backwards from there.

Hey, Peter, thanks for being on the show. Thank you so much, Mike. All right, and back to you guys in the studio.