Meet Our Engineering Team: A Q&A With Matthew Kerle, VP of Engineering

Get to know our Engineering team in this Q&A with Matthew Kerle, VP of Engineering at Benepass.

As the builders behind the platform, the Engineering team plays a crucial role in scaling our product, supporting our customers, and driving innovation across the business. With a new VP of Engineering recently joining the team, we’re excited to give you an inside look at how this team operates, what’s ahead, and who’s behind the code.

What drew you to Benepass, and what excites you most about leading the Engineering org here?

What drew me to Benepass is the opportunity to work with an exceptional team that has already built a thoughtful, scalable product in a space crowded with legacy technology. I was impressed by how much the team got right early on—investing in the right systems and architecture to solve real, long-term problems. That strong foundation, paired with the chance to help lead the team through our next stage of growth, is what truly excites me.

What’s your vision for the Engineering team over the next 6-12 months?

My vision for the Engineering team over the next 6-12 months is centered on strengthening our fundamentals and doing the simple things exceptionally well. I believe that excellence at the small things compounds into excellence at scale—and that’s exactly where we’re headed. As we prepare for our next chapter of growth, we’ll be investing in the maturity of our systems, processes, and supporting functions to enable that scale. I also see an exciting opportunity to thoughtfully integrate AI into both our internal workflows and our product, unlocking new levels of efficiency and intelligence across the board.

How do you think about balancing speed and quality in a high-growth startup?

I believe speed and quality aren’t opposites—they reinforce each other when approached intentionally. At Benepass, we move quickly by setting clear, time-bound goals and focusing on iterative delivery—feature flags, fast feedback loops, and a bias toward shipping value early. But I’m also a believer that going slow in the right places—building resilient systems, addressing tech debt, investing in observability—actually accelerates us over the long term. It’s about knowing when to push and when to pause, and building the judgment as a team to make those tradeoffs well.

What are some foundational values you’re bringing to the team?

One foundational value I bring is a deep belief in ownership—that engineers should feel real responsibility for what they build, from system design to user impact. I care a lot about clarity—in how we think, plan, and communicate—because clear expectations unlock fast, aligned execution. I believe in excellence in the fundamentals—clean code, good documentation, and tight feedback loops—because doing the small things well is what earns us the right to scale.

I’m also excited about responsible AI adoption—not just chasing novelty, but finding real leverage points where AI can make our team faster, our product smarter, and our customer experience better. As a leader, I aim to build a team culture rooted in trust, high standards, and mutual support—where people feel safe to take risks, raise concerns early, and grow. Ultimately, I’m here to build a team that’s not just productive, but proud of how we work and what we ship.

What’s your philosophy around cross-functional collaboration with Product, Design, and other teams?

My philosophy is that great engineering doesn’t happen in isolation—it happens when we’re deeply aligned with Product, Design, and other teams around a shared understanding of the problem we’re solving. I believe in tight collaboration upfront—shaping ideas early, asking good questions, and making tradeoffs visible—so we’re not just handed specs, but actively shaping the solution together.

I care a lot about clarity and accountability—everyone should know what we’re building, why it matters, and what success looks like. And once we’re aligned, I think the best teams operate with a high degree of autonomy and trust, moving fast while staying tightly looped with partners. Ultimately, we all succeed when we’re solving the right problems for the business and our users—and that only happens when collaboration is a first-class habit, not a checkbox.

What’s something you believe is misunderstood about engineering teams at startups?

One thing I think people get wrong about engineering teams at startups is assuming we’re just here to crank out code as fast as possible. Speed matters, but blind speed creates chaos. Real velocity comes from clarity, ownership, and having engineers who understand the problem deeply enough to challenge the plan when it doesn’t make sense—not just build what’s handed to them.

Another big misconception is that engineering is just execution. At a startup, the best engineers are problem solvers, not ticket takers. They’re in the room early, shaping the approach, collaborating cross-functionally, and thinking about how to deliver outcomes—not just output. When we treat engineers like strategic partners instead of a feature factory, that’s when we really start to fly.

How do you approach mentoring or developing engineers on your team?

I start by setting clear and realistic expectations—based on where someone is today and where they want to go. From there, I work with them to break that down into tactical, achievable steps so they can make steady progress over time. It’s a collaborative process, tailored to the individual, not a rigid path.

A big part of it is communication—giving feedback early and often, but always rooted in care. Feedback, to me, is a positive thing. It’s how you show someone you’re invested in them. And that kind of feedback is much easier to give and receive when there’s a real relationship there—built on trust and mutual respect.

Ultimately, I want every engineer to feel like they’re supported, challenged, and growing—and to know that I’m in their corner, helping them take the next step.

What types of engineers thrive at Benepass?

Engineers who thrive here are problem solvers at their core. They’re not just writing code—they’re thinking end to end: What’s the problem we’re trying to solve, what’s the best way to deliver that value, and how will this solution hold up at scale and in the hands of real users?

They care deeply about the why behind the work, and they take ownership— whether that means digging into a gnarly bug, proactively improving a system, or shipping something that makes a customer’s life better. They don’t wait to be told what to do—they bias toward action, but they also know when to slow down and dig deep to get it right.

They also work hard. This isn’t a clock-in, clock-out kind of environment—engineers here bring real effort, focus, and care to what they build. It’s not about long hours—it’s about showing up with intensity, taking pride in your work, and pushing for excellence because the mission matters and the bar is high.

How do you think our Engineering team will evolve as we scale our customer base and product lines?

Right now, we’re a small but mighty team—tight-knit, scrappy, and operating with a lot of ownership. As we scale our customer base and expand our product lines, I think that will naturally shift. We’ll need to add more supporting functions and specialized roles to own specific domains—whether that’s infrastructure, QA, developer experience, data, or domain-specific product engineering.

At the same time, I see us evolving how we work, not just who’s doing the work. We’re really interested in embedding more intelligence into our engineering workflows—things that improve our efficiency, quality, and speed. That could mean smarter tooling, better automation, or leveraging AI to take friction out of the day-to-day.

And beyond that, there’s a huge opportunity to bring intelligence into the product itself. We sit on a lot of valuable insights, and as we grow, we want to surface those in meaningful, intelligent ways that genuinely improve our customers’ lives—whether through smarter defaults, proactive guidance, or entirely new product experiences.

Lightning round! What's your favorite tool, favorite programming language, and your go-to debugging snack?

Favorite tool? Cursor. It took a bit of adjusting in how I work, but once I landed on some solid workflows, it’s massively increased my efficiency writing code. It’s become an essential part of my development process.

Favorite programming language? I’m a huge fan of Elixir—I love functional programming, and Elixir is just fun to write. It’s incredibly readable and that simplicity allows you to build very quickly without introducing a lot of bugs. My second answer would be full JavaScript stacks—especially because they pair really well with Cursor and AI agents.

Debugging snack? Lesser Evil Cosmic Interstellar Space Balls are my favorite snack while I’m writing a lot of code.