From Machetes to Bulldozers
I'm a very visual person, and we use a lot of analogies within the teams I lead. The way I used to think about platform engineering is that we would build the golden path for the majority of users, the old 80-20 rule. If you want to get from point A to point B, whether that's CI/CD systems or mailing systems, we'll build the platform that allows you to decouple your thinking. You can just think about the product, the customer. You don't have that cognitive overhead of maintaining everything else down to the nuts and bolts.
The analogy is that we're there handing out machetes to people so they can beat their own way through the bush if they want to, but the majority of people are just going to jump in their car,, andjump on the highway. It's a nice, signposted highway. We maintain it very well. If you want to go and do your own thing, we'll give you a machete, but you're on your own. We're not going to support you. If you get lost, you have to find your way back.
Now with AI, it's not really a machete that you're giving people. You're giving them bulldozers. They can go off with these highly powered bulldozers and really beat a pretty reasonable representation of a road themselves. If we have a rainstorm, it might wash away a bit. It's not going to be maintained to the same standards. It's not going to have lighting on it like a highway would. But the problem is that now there's just all of these pretty good dirt roads going all over the place.
The barrier to developing your own platforms, your own frameworks, your own tools has dropped to near enough zero to make no difference. We were seeing people vibe coding their own solutions to things that we weren't able to move fast enough on.
Going Down a Layer
The position I've taken is that instead of fighting that or trying to pull everyone back onto our highway, the better position is to go a layer down in the stack and think of what we're offering as more APIs. Allow users to have a set of blessed tools that they can go off and build pretty good roads wwith—dosome paving, add some lights, some reflectors.
Instead of fighting it, we're giving them a better class of bulldozer. We're giving them road-laying machines that they can go and pave their own roads with. We'll still offer a highway in a bunch of places.
It's an interesting mix now because we're offering platform products, but more and more we're offering much lower -evel interfaces into the building blocks, the Lego pieces that allow you to go and build your own road through the bush.
The primitives look like things such as standardizing on observability patterns, standardized gateways or routing layers, security and authentication, or a standardized set of MCPs and tools that you want people to use rather than going and doing their own thing. And then giving a bit more flexibility in terms of how people actually get from A to B.
Observability has always been important, but now with being able to feed that back and close the loop and have these flywheels: you observe patterns of behavior, you can feed that data back in, you can make your model or your harness or your system better overall — it makes it even more important to have that built in and baked in from the get-go.
The Load Has Changed
Where we focus and where our efforts need to go is shifting. Platform engineering is, in some places, going down to a lower level. I always think of platform teams as levels. There are the actual infrastructure teams—the real base-level platform teams working with the cloud, provisioning things—and then layers built on top. I'm just seeing things maybe move down a few levels.
I don't know that it's reducing the load. I think in some ways it's increasing what I'd call stakeholder management load.
Platform teams stereotypically have been quite inward-facing. We haven't been known as the most extroverted teams in terms of having lots of stakeholder relationships.
Now, you have to try and understand what the customer's going to do—because they're not going to do it over six months anymore. They will do it over maybe six days. If you can't help them straight away, they're just like, well, we can just do it ourselves.
Everyone Is a Builder Now
There are so many more people that we consider builders. You don't have to be a developer to be a builder.
Internally at Canva, within our AI platform group, we've always had this concept of personas that we serve—researchers, MLEs—and more recently we've been referring to them generally as AI builders. It's a much broader customer base.
It makes sense for a company to say, "Okay, we might actually need a platform engineering–shaped team or role,that is moving earlier.
When Multiple Teams Build Their Own Tools
We're absolutely not against people doing their own thing. If you need to go and build that dashboard, that interface, that framework, unblock yourself. We'll support you where we can, but you should move fast, do what you need to do.
Where it becomes more generalized is when we start seeing three or four teams doing the same thing. Maybe we see the one thing you've built that you own is now being used by four or five other teams. That's the point where we at least ask whether we should start discussing some sort of graduation process. We can graduate that out and start providing the additional lighting on the highway—the checks and balances that make it a bit more of a productionized, hardened service.
When a significant portion of a product team's time and effort and cognitive load is spent managing the things that they use to build the thing — that's when it's time for them to stop and think: this isn't the best way for us to spend our time. We should actually get someone else to do this for us.
It's not a new problem, but the scale and the pace that it's occurring at now is the thing that's changing. One of the levers we're playing with is how early we can start that engagement with the stakeholders. How early can we have that engagement and try and preempt what they're going to go and do on their own? Even if they end up doing that, at least if we know about it, we can start slowly steering the ship in that direction. It might take us a few months to catch up, but then there's a clear point where we can say, okay, we do what you need it to do.
Inner Sourcing
Ownership has forever been an issue: who signs off on PRs, people stepping on toes, and making architectural decisions that other devs don't like. That's still a problem ttoday,and it's only going to get worse.
The tack we're taking is trying to encourage this inner source model — your open-source contribution model, where technically we own the codebase and we're on the owner's file and we sign off on PRs, but it's not a blocking action. We don't gate things. It's more a collaborative environment where you're almost contributing to an inner-source open-source project.
In terms of velocity, we can rely on other teams to come to us and say, "We need this dashboard to have this new metric on it. And we can say, well, we don't have time to do that. It's not on our roadmap, and you're the only team that wants it. If you want to make the change, you can go and add it. And if you commit the change, we'll approve it.
When Vibe Code Goes Mission Critical
I have personally created some dashboards, just thrown together in a couple of days for an exec who wanted to see some specific view on some data. And the next thing you know, that becomes mission critical. I shut my machine down and go home, and the next morning the execs are hitting me up about how they couldn't access the thing from home and this is unacceptable. All of a sudden it's become a 24/7 expectation.
I've seen how quickly that can tip over. And I think that's part of that stakeholder engagement—we need to front-foot that, get ahead of it and understand that this framework, this thing that they've vibe-coded, is now used by three or four teams. It's maybe even underpinning some development that's on the critical path for some vital feature.
We need to forcefully go in and have conversations about, "Look, if this goes down, these are the implications." Let us at least take on some part of it so that we get to know the codebase, we understand it, and we can support it for you.
Intent Debt
I've seen various people try things like having early-stage artifacts—whether those are PRDs or specs—discussed in the codebase somewhere, having those as the artifacts that are reviewed. But I see too many issues with that.
Having purely gone the other way and saying we don't read code, we're just going to read the spec, and that's going to be the PR process, a human reading the spec—you're just shifting the problem somewhere else. The spec and the code diverge straight away.
Companies Becoming Dev Tool Companies
It's a meta version of this whole platform engineering problem. At an inter-company level, there's no platform team helping solve the problem at a centralized location. Everyone's doing their own thing.
We've done some really cool stuff internally at Canva, but I've heard of other examples from friends who have gone through the pain of developing a fully featured thing—whether it was building their own versions of coding agents before Codex and Claude Code were what they are, or even more sophisticated tooling to do the full end-to-end PR review, spinning up multi-agents. And then realizing that they're just now a platform company maintaining a platform instead of their actual product.
Outcomes Over Output
Lines of code as a measurement was kind of laughable, we threw that away decades ago. And it feels like we've gone full circle again, in a bad way. There was the whole tokenmaxxing thing, which hopefully has gone away and died somewhere. There were folks in the industry trying to come up with clever ways of measuring the complexity of a PR, how much engagement your PR has had with agents and humans, even weighing those differently.
Even something like how many PRs a developer has pushed oout—ifone developer's pushed out 10 PRs in a year and another one's done 500, there's something interesting there. But if someone's done 500 and someone's done 520, that's irrelevant. It's a very indicative, high-level metric, but I see too many people focusing on that as a core metric. I prefer to focus on the harder-to-measure things.
I'm a fan of DORA metrics , and I quite like SPACE as well. It's got a bunch of stuff that's very measurable, with a lot of overlap with parts of the DORA metrics, but it adds on the pieces we're missing: that less tangible stuff, the developer experience piece. We're doing some of it internally—having regular developer surveys trying to measure the developer experience overall.
In a nutshell, it's just focusing on the outcomes rather than the volume-based measures. The volume-based measures are gameable, they're less relevant — a race to the bottom. Your outcome measures are much harder to quantify, much harder to measure, but they're the ones that actually provide value.
I think you have to boil it down to: what is a PR for? Is it for you to go and read the code and make sure the indentations and the linting is the way you like them and the function names match your preferences? That can all be automated. You go back decades—there was no linting, there was no automatic code verification. And I think this is the next iteration or evolution of that. We need to rely on solid validation rather than solving how people just review more code.