Breaking Down ‘Move Fast and Break Things’: Valiantys’ Expert Philip Heijkoop

Hey everyone. Welcome back here to Techstrong tv. I'm happy to introduce you to my next guest.

It's his first time on, so let's, uh, hear what he has to say. His name is Philip Haku. Uh, Philip Phil.

Phil. We're gonna call him Phil. Phil is the global practice head of developer experience at a company called Valis, and he's gonna tell us all about that as well.

But first, let's welcome Phil to the show. Phil, nice to have you on here. Thanks so much.

Thanks for having me, Alan. Appreciate it. So, Phil, you know, we're gonna talk about ti, we're gonna talk about move fast and break, but before we do that, let's, let's hear Phil's story a little bit.

Sure. My name's Phil Haku. Uh, I, uh, I went to school for mechanical engineering and then I spent 10 years in robotics.

So I tinkered with, uh, all kinds of tools to avoid talking to other people. After that, I moved into software engineering and then realized that helping people is actually a lot more interesting. Um, after that kind of progressed over to kind of more of an agile role, uh, worked through the Atlassian ecosystem first on the product side, then onto the consulting side.

I've been there for the last couple of years, so that's been kind of the short version of my history. Very cool, very cool. Um, and Phil, you know, I, I'm, I'm, I think I'm speaking, I'm, I'm not gonna say anything you don't necessarily don't know, but a lot of folks in our audience may not be familiar with Valis.

How, how would you describe that to 'em? So, I think Valis is a, um, I think we've, we've long been a big fish in a small pond, so we are one of the platinum solution partners in the Atlassian space. Mm-hmm.

We span the globe, but obviously once you look at it from a globe perspective, we're, we're really more of a boutique consulting firm in that sense. So we focus a lot on the tooling and process around the Atlassian stack. So a lot of it is software development.

Uh, a lot of it is, um, service management now, obviously over the last couple of years. So we do a lot of work in that particular space. Uh, outside of that, you know, you can think of us as a value added reseller or GSI, maybe not so much G as si.

Right. So we're a services integrator, value added reseller of the Atlassian stack. And then everything from a process perspective that comes around that, I think of it as like layers of the onion starts with the Atlassian tools.

What do you wanna do with it? Setting it up, and then obviously optimizing and going fast with them. Excellent, excellent.

You know, uh, I'm trying to think. I think, uh, some of us were over, not me personally, but some of my crew are over in Barcelona just a few weeks ago for the Atlassian, uh, user conference there. Lot going.

I was there too. You were also there. Yeah.

We couldn't done this in person with you there. Uh, next time, Absolutely. Make sure we're gonna hold you to that Phil, though.

I don't know where the next one is off the top of my head right now, but they, they usually reach out and we send, uh, a crew over and some of our writers and content folks. Um, so, you know, the Atlassian channel, of course is one of the great success stories I think of the, in the DevOps and space. And I mean, it, it's, it's almost legendary if you will, right?

When you, I mean, you know, you look at Atlassian versus let's say, uh, like A-W-S-A-W-S is a hyperscaler, it's an 8,000 pound gorilla. But from a channel point of view, Atlassian from, from day one has always done a great job of integrating their partners and allowing their partners to have some meat on the bone, if you know what I mean. Do, right.

There's, there, there's things that you need an Atlassian partner to do. Atlassian themselves doesn't do it, and so it, it, it's a great thing. Um, Phil, before we jump into our topic of discussion, maybe people who want to get more information on valis and how to, you know, how to engage, what, what would you suggest?

I think there's, there's probably two common channels that people can reach out to us. com. Um, there's a good amount of content and there's a contact form there, obviously.

Um, if people want to dive into any of the conversations that we bring up today, um, I'm pretty active on LinkedIn, so if they can figure out how to spell my last name, I'm probably the only one that has it that way. So they could always reach out that way and have a slightly more informal conversation if that's what they wanna do. Absolutely.

And, and Phil, you don't know this while we're recording it, but in the finished version actually, your name and Valis and your title will be, uh, underneath you on the lower third of the video. So people, you can see it right there. It's H-E-I-J-K-O-O-P.

The I and the J make the y, so it's Hey, Kup. That's right. But, uh, people will see it there, Phil, if it's all right.

Let's transition now into what our topic of discussion here is. You know, uh, a mantra in Silicon Valley for a very long time has been move fast and break things. But, you know, it's not, it's not that we're bulls in China shops or something like that.

The idea is that we know in moving fast things that aren't enterprise ready, things that aren't scalable are gonna break. And if they're gonna break, let's find out that they break and, and fix 'em and make them more scalable and more resilient and, and not breakable. Right?

It, so the idea is, you know, kind of go fast as you can and, and we just keep rebuilding stuff this way and rebuilding. It's kind of, it's part of that DevOps agile culture, I think too, which is iterate and reiterate feedback, loop iterate, feedback, feedback, iterate. Yep.

That's true. I, yep. So, but now, you know, look, AI has changed a lot of things, obviously.

Has it changed the move fast and break things mantra? I, at least at the enterprise level, I, it may have helped it. I think it was already changing.

I think there's two parts to consider. There's the, the learn fast aspect, which was the original, uh, impetus to moving, uh, move quickly, break things right as you want to fail quickly, learn what didn't work as part of that, that kind of feedback loop. Um, I think that is probably more the case now than it was before, right?

We wanna learn quickly, market test, get it validated and all that stuff. What I think has, um, often been overlooked and it's easier to overlook and get away with when you're a smaller company, is not regressing to a point where things become unusable, right? So a good example would be AWS's recent outage from a couple weeks ago.

Like, you don't want to get to a point where you are effectively publicly embarrassed for a little while because you've moved fast and broke something. And so I think there's a balance that needs to be found when it comes to trying new things. You can absolutely still get away with going quickly, trying new things, seeing if it works and pulling back.

But your core value prop should always still be accessible. And I think that that's where a lot of the, um, the literalism sometimes bites it when it comes to this particular philosophy. It's a move fast, try new things, absolutely.

But don't break the old things like, don't break what got us here. Don't break the core platform and above all else, don't break customer trust. Because I think when it comes to moving fast and trying new things, if the functionality that you said, and it's got a big banner that says this functionality's in beta, people have their expectations managed.

If people can't reach their bank accounts because you're trying something new, you have a whole different level of problem. And so I think that that's where enterprise in particular, have to have a different trade off because their core value proposition, the legacy framework is everything they like. That is effectively a commitment to their customers that that will be available and they'll get better at it, but they cannot, like their floor of behavior and delivery has to be maintained at all costs.

And you could think about it in the DevOps and agile space as like, you need to have regression testing and everything else in place because you can never get worse as you try new things. And I think that that's the philosophy that needs to find a balance with, with customers. Fair, fair enough.

Uh, so how, how's this kinda manifesting itself, like at your, at the Valley Valis level where, you know, how are you seeing this kind of play out? I think there's, there's two main things we see a lot. A lot of people want the shiny new toy.

Uh, they wanna vibe code their way to new functionality. They wanna get through their backlog, they want to try all the cool new things. They also have to add AI on top of and into their tool.

Um, a lot of people are still bolting it on as opposed to making a core value prop. Um, and so there's a lot of demand for help us do these things, help us accelerate what we're doing. And we're seeing that in most places.

They don't have the foundation in place to go faster because they're just not doing the basics right. Um, I, I think I've turned into a bit of a curmudgeon at this point, but if you don't have a lot of the basics, right, in terms of having security in place and you have QA systems and you're monitoring everything, like none of the AI tools are really gonna be helping you because you're just building a taller tower that is going to fall over, um, the other side, the J good game, right? Oh, absolutely.

There's just a lot more holes than I think people are cognizant of because they just mm-hmm. Again, not a lot of tools, also not a lot of monitoring, so you don't even know how bad things are sometimes. Um, the other side that we see a lot of this coming in is obviously just we are being mandated to do this stuff.

So it's a less of a, I want, and it's a lot of it I must, and then we're trying to figure out how can they balance this out? Because in most cases, there's the technical, tactical implementation that people are, are stuck with. You must start using ai.

You need, you need to increase your throughput, your volume, et cetera, et cetera. But it doesn't always correlate correctly to business value. So in most cases, we're trying to help 'em understand that bridge before they do anything.

Like, if I'm gonna do this, it's gonna generate 10,000 lines of code, potentially. Why? What is the business value?

What is the purpose is? And that helps them make better decisions at a time, because you want to actually go in and still have that experimentation mindset, but have a bit of a credible hypothesis in terms of like, well, if I do this, these are the trade-offs that I'm explicitly making. There might be a couple I'm not aware of, that's okay, but it is all in service to this end.

And if I can't make that chain of thought, I'm just experimenting for the sake of experimenting, that's also great. But that's what sandboxes are for, right? Like, if you're doing this in production, you have to have that credibility towards a, I'm doing this in the service of this business value that I want to achieve over here.

Excellent. Very cool. Um, you know, Phil, I, I, this isn't, is this an enterprise specific thing you think, or does it apply to SMEs as well?

I think it applies to both in different ways, though. Um, one of the things that you see just company dynamics are different at different sizes. Um, there's a lot of uncertainty frankly, in, in enterprise, especially with that layer of middle management where they're starting to look at the Salesforce and AWS and, and meta plays in terms of like basically shoving out whole layers of management because they don't think they need them anymore.

Um, and you can see people saying, like looking at that anxiously and saying, is that the future? Do I need to prepare for that? Um, SMBs don't really have that problem in the same way.

They have a slightly tighter line of sight between leadership decisions, obviously, and the tactical, uh, individual contributors. Um, but a lot of this is still a question of if we can't, like, of that uncertainty from a do this to get to this business value, I think is the core of, of what this goes on. And it just becomes more complex at enterprise levels because there's a lot more dependencies between software systems.

You have to collaborate between more different teams. You have a lot more legacy, um, not just code, but also commitments to customers and services that need to be maintained. So it just becomes a slightly more complex version of the same challenge.

Agreed. Agreed. I I, I don't disagree there at all.

Um, let, let's look specifically with AI, Phil. Sure. Right?

Does it Take it away with it these days, right? Don't even get me started. Um, but, but, but seriously, you know, and, and, and I'm talking specifically like with digital twinning and the ability to do this sort of in a, in an AI environment, if you will.

Does it give us a way out here like having our cake and eating it too? We can build systems that last by going fast and breaking things, but in a virtual environment with AI simulation or what have you. And, you know, I think it is very likely.

And this on a cheery note. Yeah, yeah, yeah. No, I, I would say yes, that is the very likely end state.

I don't think most companies are there yet. Uh, oh no, from a process perspective, but I think that that is absolutely the, the next step. We, we've seen a lot of conversations in AI around that early build plan, like make the thing, a lot of the conversations I think have started to move towards the next stage of that, like the traditional waterfall element, right?

Like you need to check your requirements, you need to make security a priority, you need to make sure QA works and everything else in production obviously is stable. Um, I think it's inevitable that you get to that particular stage. I think that you can absolutely go faster and prototype things.

I think the table stakes obviously, that have been pretty high before are obviously just gonna get higher when it comes to enterprise software, which will be great because users want better user experience and user interface and things like that. I think, however, and this is a challenge we've seen a lot, this only works when you're doing it with people who understand both the problem domain and the craft that they're working on, right? Uh, we see this in every element.

If you don't understand the question that you're asking from ai, you cannot correct it as well as you can. That's one of the challenges I see in vibe coding is senior engineers experience people getting tremendous value out of it. Juniors aren't because they don't have the experience.

And that kind of understanding intuitively of like, oh, I skipped a step here. And that's where the veneer is, is often the challenge, right? Like, you'll get the working piece of software, but a working piece of software on my computer is not the same as an enterprise level working grade of software.

So once we have the rest of the process infrastructure and guardrails in place, I think we absolutely get there, but I don't think we're quite there yet. That's, that's basically what we do day in, day out, is help build that particular state that we're working towards. Agreed.

I love it. Bill, we're about added time. com.

Check it out. Phil, thanks for coming up on here. I appreciate it.

Um, I, I, thanks for having me. You could reach, thank you. com website.

But, um, look, you know what, sometimes you can't teach old dogs new tricks and maybe, maybe, uh, we are moving past, move fast and break things to build systems that last you're watching text on tv. We'll be back in a moment.