What It’s Like to Work as an Engineer at KUBRA: Ownership, Experimentation and Cloud-Native Tech

What It’s Like to Work as an Engineer at KUBRA

KUBRA’s engineering culture is built on trust, autonomy and impact — and according to Director of Product Engineering Evan Ezewski, that combination is what allows teams to turn complex challenges into meaningful, customer-focused solutions.

“I’m not sure you can measure it, but that quiet satisfaction and confidence that comes from achievement, the feeling of knowing that the teams have successfully navigated many challenges to create something of real value — and that they know it, too,” he said. 

At KUBRA, a customer experience management solutions provider, Ezewski is responsible for the design and delivery of services on the KUBRA HQ platform. His day-to-day work involves guiding the engineering teams, giving them the right amount of support and knowledge so that they can create impactful solutions more autonomously.

According to Ezewski, engineers play a direct role in shaping KUBRA’s product roadmap, primarily through the bottom-up scoping and shaping of new feature efforts.

“This goes beyond a simple estimate; it’s a vital process where teams define the expected technical effort and complexity, thereby establishing the necessary resource requirements and dependencies,” he said. 

Relying heavily on cloud-native technologies and strong cross-functional collaboration, KUBRA engineers build products that are “technically sound, user-centric and strategically aligned,” Ezewski said. But ultimately, the engineering teams’ success hinges on having the freedom to “fail small,” which he considers the catalyst for unlocking true innovation. 

Below, Ezewski shares more about what it’s like to work as an engineer at KUBRA, including a recent project they tackled, the principles that guide their work and how they stay ahead of emerging trends like AI. 

Evan Ezewski

Director of Product Engineering 

How KUBRA Engineers Influence the Product Roadmap and Delivery

Describe your role and responsibilities. How long have you worked at KUBRA?

I’ve been with the company for seven years. During the last five years, I have been responsible for the design and delivery of services on the KUBRA HQ platform. Over that time, my focus has shifted from personally designing robust, scalable solutions to instead developing the engineering teams so that they can design and deliver such services themselves with ever-increasing autonomy. As teams demonstrate proficiency and ownership, I step back into a review and approval role, concentrating my efforts on strategic oversight, architectural guidance and ensuring alignment with the guiding principles and broader technological vision for the platform. This model allows me to focus on future-state planning and fostering technical excellence across all of my teams.

How does the engineering team directly influence the product roadmap each quarter?

The foundation for the product roadmap each quarter is built directly upon the hands-on and active involvement of engineering teams in the bottom-up scoping and shaping of new feature efforts. This goes beyond a simple estimate; it’s a vital process where teams define the expected technical effort and complexity, thereby establishing the necessary resource requirements and dependencies. This essential input creates a foundation for informed decision-making. 

By defining resource realities from the ground up, leadership can safely determine how many major or minor features can realistically be integrated into a given quarterly cycle. This directly leads to better, more pragmatic decisions concerning everything from adjusting the product roadmap to strategically applying additional internal teams or hiring supplementary resources. Ultimately, this deep, hands-on involvement ensures that the product strategy remains firmly grounded in technical feasibility, mitigating the risk of overcommitment and fostering a more predictable and successful delivery cycle.

“By defining resource realities from the ground up, leadership can safely determine how many major or minor features can realistically be integrated into a given quarterly cycle.”

A Recent Engineering Project at KUBRA: Generic Payables and Cross-Functional Collaboration

Name a recent feature or improvement that originated from an engineer’s idea, and describe its customer impact.

The Generic Payables services initially presented a significant challenge, particularly in managing dynamic lookup and extension properties of varied types while maintaining strict adherence to the OpenAPI Specification. The initial design proposal was complex and failed to offer an elegant solution. One of our back-end engineers stepped forward with a compelling alternative: leveraging polymorphic types with type discriminators that were added in OpenAPI v3. A proof of concept was quickly approved and delivered. The resulting proposal proved to be precisely the solution we needed. It established a common, standard base structure for all payable types, which is essential for our core payment systems. Crucially, it also enabled the dynamic fields that allow us to seamlessly look up payables in our unenrolled EZ-PAY+ experience, but also display relevant payable information provided by our clients, and capture consumer data. This fulfilled the complete requirement with a modern, spec-compliant design that supports API client generation.

How KUBRA Chooses Its Tech Stack: .NET, Java, TypeScript and AWS

What guiding principles or decision criteria drive your tech stack choices and architecture updates?

Our engineering teams have the full authority to select technology for our products, a decision rooted in their deep understanding of product needs and business context. While cost is a fundamental consideration, it is secondary to technical and strategic factors. We require new technology to align with our existing platform patterns and be compatible with our predominant languages: .NET, Java and TypeScript. We strongly favor cloud-native technologies, either as robust SaaS or manageable within our AWS platform. Teams must strike a balance by choosing technologies that are maintainable, extensible and well-understood, fostering innovation while avoiding unnecessary complexity or “janky” solutions. Finally, given our business’s focus on payments, any technology chosen must offer strong reliability, durability and a high degree of observability.

“Our engineering teams have the full authority to select technology for our products, a decision rooted in their deep understanding of product needs and business context.”

How do engineers collaborate with product, design and other functions to balance speed with quality?

KUBRA employs a dynamic, collaborative structure centered on cross-functional product teams. These core teams include back-end, front-end and QA engineers, along with a team manager and a product manager who guides vision and prioritization. This foundational unit actively engages with a rotating cast of specialized members and stakeholders, including UI/UX members for design, business subject matter experts for domain knowledge, operations members for deployment and maintenance insights, and leadership for strategic oversight. This collective undertakes the bottom-up shaping of projects and products, valuing ground-level input. Their methodology is iterative and transparent. They proactively invite comment and critical feedback on the design from all engaged parties and solicit formal approval from business stakeholders and leadership to ensure alignment with strategic goals and market needs. As soon as practically viable, they transition to development, iteratively building, thoroughly demonstrating, and rapidly changing the product based on continuous feedback. This systematic agile approach ensures products are technically sound, user-centric and strategically aligned.

Related ReadingEngineers Share The Projects They’re Most Excited to Tackle in 2026

How KUBRA Builds an Experimental Engineering Culture 

Which cultural practice best reflects your engineering values?

It’s a toss-up between the platform demos and the guild meetings. The platform demos offer a high-visibility stage for teams to showcase tangible progress on the core platform and its products to the entire department and key business leaders. These events are critical checkpoints for celebrating technical achievements, demonstrating delivered value, and aligning stakeholders on the future product trajectory. In contrast, the guild meetings — back-end, front-end, quality assurance and DevSecOps — are more intimate yet equally crucial. They provide a platform for engineers to propose, debate, and demonstrate new tools, techniques and emerging technologies among peers. They are the primary venue for presenting and vetting sophisticated solutions for cross-cutting architectural or procedural challenges that require department-wide consensus. The guilds are where grassroots innovation flourishes, technical standards are forged through peer review, and individual expertise shapes the collective technical roadmap, empowering engineers to influence strategic direction from the bottom up.

What metric or milestone tells you the engineering team is succeeding in both product and cultural goals?

I’m not sure you can measure it, but that quiet satisfaction and confidence that comes from achievement, the feeling of knowing that the teams have successfully navigated many challenges to create something of real value — and that they know it, too. I guess the best indicator is seeing other behaviors like stress abate as the team and its members begin to move and operate more purposefully. This increased focus and deliberate action is a clear sign that they trust their process, their skills, one another and leadership, which is ultimately what we’re striving for.

How does the team stay ahead of emerging technologies like AI or automation? Can you share an example of a recent innovation or tool your team adopted?

I strongly encourage my teams to actively engage with and play with new tools, technologies and innovative methodologies. This is best done through the development of proof-of-concept projects that are specifically designed to demonstrate how these new capabilities can be applied to solve real business problems. This structured engagement is crucial because it helps to unlock deep-seated creativity, build genuine technical resilience within the team, and develop sharp critical-thinking and problem-solving skills. Moreover, affording teams the freedom to experiment and “fail small” in a controlled proof-of-concept environment provides the psychological safety necessary for true innovation, allowing them to iterate quickly and discover better, more efficient solutions without fear of large-scale failure. This culture of playful, low-stakes experimentation is the engine of skills development. Most importantly, leaders need to give teams the patience and understanding they need to get through that awkward phase of being bad at something new in order to achieve proficiency.

Frequently Asked Questions