“Everyone is running Faster in a Different Direction”, Braze’s Francisco Trindade on the Outdated Habit AI Is Exposing

AI has made it easier than ever for a single engineer to ship more code, faster. Francisco Trindade, VP of Product Engineering at Braze, thinks that’s exactly why alignment now matters more than it ever has, not less. Having led engineering across consulting, a founder role, and now a platform that dispatches billions of messages a day in real time, Trindade has built his leadership philosophy around a simple, hard to execute idea: teams get better when they stay tied to the customer value they’re delivering, and worse the moment that connection breaks.

At Braze, that discipline shows up in how the company evaluates every engineer, designer, and product manager on customer outcomes rather than output, and in how it builds guardrails to catch misalignment before it becomes rework. In this conversation, Trindade discusses why engineering metrics are becoming noisier in the AI era, why quality and speed reinforce each other rather than trade off, and why he believes the real test of any new technology isn’t whether it’s new, but whether it changes what the customer can actually do.

Across your experience as a consultant, founder, and engineering leader, what is the one lesson that most changed how he thinks about building products and leading engineering teams?

The lesson that has held up across consulting, founding a company, and running engineering teams is also what one might expect: everything gets better when the team stays focused on the customer value it is delivering, and worse when it does not. This is simple in theory and often hard to execute in practice. As work is divided across people, teams, and now agents, it is easy to miss the perspective of what you are trying to achieve.

In engineering, for example, it is easy for engineers to fall into the trap of seeing their work as the execution of a technical task that is decoupled from its objective. That often causes misalignment, both in small and large ways, leading to rework, delays, and issues in execution. This is becoming more critical as agent execution brings more entropy to the development process, given that one engineer might be running multiple streams of work at the same time.

Effective engineering leadership, for me, is creating a working system that brings misalignment to the surface early, making teams faster and minimizing rework.

How does Braze make a platform spanning customer data, cross-channel engagement, orchestration, and AI feel seamless for customers?

We build Braze with a strong focus on who is using our product, the marketer. This discipline starts in UX and research, with our teams constantly talking to customers about their needs and challenges when using Braze, as well as testing ideas and concepts with them. It continues throughout our product teams, which are focused on particular areas of the product and have in-depth expertise about customer needs within that area.

The autonomy we provide to teams is balanced by accountability systems that keep them aligned. In other words, while a team might be focused on a particular channel’s experience, the marketer uses that as part of a workflow that involves other product areas. We need the experience to be cohesive as they move from one team’s area of ownership to another. Expertise in an area is what makes each surface good, and it is also what can pull those surfaces apart, which is why these alignment systems need to exist.

In practice, we do that with review systems that follow teams and projects through execution. From a design and product perspective, critiques and reviews ensure that team direction doesn’t diverge from the rest of the product. From an engineering perspective, we use technical design review processes early in the initiative timeline to align on architectural direction, and we have performance and quality checks that help ensure the product maintains a high standard as it is iterated on.

How do you ensure Braze's engineering roadmap stays focused on solving real customer problems rather than chasing every new technology trend?

We stay focused by starting from the problem and making technology decisions from there, rather than the other way around. Every idea gets the same two questions: which customer problem does this remove, and how would we know it worked?

And that matters more now that building is getting easier. The industry moves quickly, and AI, both as a development tool and as a product capability, is the latest and most significant example. We should not dismiss that, as some shifts genuinely change what a customer can accomplish. But the test is not whether a technology is new; it is whether it changes what the marketer can do. Whether a feature uses AI is far less interesting than whether it makes it easier for our customers to reach their objectives. It doesn't matter how many advanced capabilities a customer engagement platform has if it can't deliver messages reliably.

What holds that line is what we measure. Every role in product development at Braze is evaluated on customer impact. Engineers, designers, and product managers are evaluated based on the customer outcomes they and their teams deliver. Once that is true, it becomes easier for everyone to focus on real value rather than technology trends.

Every engineering team wrestles with the same balancing act: shipping fast without compromising quality or piling on technical debt. How do you navigate those trade-offs at Braze?

We value the quality and stability of our product as a first-class priority at Braze. And like most companies, we constantly evaluate where to invest, from product opportunities to stability improvements. We do that by establishing guardrails and acting when they are breached.

From the volume of support tickets on a specific surface to the number of incidents or escalations in a product area, we have expectations for how the platform should perform, and we reallocate investment as we see more friction in a given part of it. We also have extensive observability across our systems, allowing teams to detect anomalies and take action before they impact customers.

However, we also believe that quality versus speed is not a trade-off, but rather a system where positive results in one area reinforce the other. A team that maintains higher quality will also move faster because it carries less reactive work in its backlog. And the effect compounds, because a team spending its capacity on interruptions falls further behind one that isn't. As an example, we recently made a meaningful investment in improving the product using support tickets as our guide, incentivizing teams to make changes that would reduce or eliminate certain types of support issues. As a result, we improved the experience for our customers, who can now operate more independently, while also improving the speed of our teams, which spend less time responding to support issues.

As customer engagement becomes more connected and data-driven, how is Braze's engineering mindset evolving to build platforms that are both scalable and adaptable?

Braze’s systems have always been built with a great focus on scalability and adaptability. We dispatch billions of messages per day in real time and have built our product with a multi-channel perspective from the beginning, which is what has allowed us to keep adding capability without rebuilding the foundation. In that sense, our mindset has not radically changed. What has changed is what customers expect from our product.

What keeps a system adaptable at this scale is coherence. A codebase is a bit like a city: you decide where the avenues go and you set the construction rules, but you never review every house. The real measure of an architecture is how much coherence survives thousands of decisions and changes over the course of the product’s evolution. This is an example of how strong engineering fundamentals and practices pay off. Small, frequent integration is what keeps a system flexible, and that is an engineering practice as much as an architectural one.

That fundamental work is what lets us move quickly now that our customers are becoming more sophisticated and want far more access to their data, both for people and increasingly for agents. The Braze Data Platform was a significant step in that direction, and we are extending our APIs to support customers in an agentic future. The roadmap has changed considerably. The principles underneath it have not.

Which engineering leadership principles have become more important in the AI era, and which outdated habits should be left behind?

In terms of what has become more important, it is interesting how with the rise of AI we are in some ways seeing a return to the existing principles of effective product development: faster iterations, clearer specifications, and better engineering practices. That makes sense since iterative development was based on the idea that coding was not the bottleneck for delivering value, even before AI tooling. With AI, it becomes more obvious and urgent that coding is not what delays projects, raising the importance of improving other friction points, like code reviews or (the lack of) automated quality assurance.

In that sense, the principles we are seeing become more important are clearer alignment and greater ownership, allowing teams to make a decision faster. When code can be delivered quickly, every misalignment or lack of certainty becomes a bigger delay in the process. In practice, we are experimenting with team scopes, allowing small groups of people to act on a broader surface, as well as stronger alignment structures, creating guardrails that teams can move faster within.

For outdated habits, one is letting engineers run parallel streams of work without a mechanism to catch divergence. While it is clear that one engineer can do more by themselves using agents, it is also easy for misalignment to emerge, with everyone running faster in a different direction. Another issue is that engineering metrics are becoming even more opaque as high output no longer signals deep engagement, and deep engagement no longer requires high output. Managers who rely on metrics to assess performance are reading more noise than signal, which is a challenge for organizations.

If someone interviews you again five years from now, what would you hope has fundamentally changed about engineering?

I would hope that the friction we spend most of our time on today, bugs, incidents, drift, and all the reactive work that follows from them, is much smaller, so engineering is primarily about delivering value rather than keeping things running. If that happens, in five years we will be having a higher-level conversation, one about whether engineering delivered the right value, rather than how much the team shipped.