Kustomer’s Engineering Values

One of the biggest challenges a fast-growing company faces is finding ways to continue building great things and maintaining a positive culture as a continuous stream of new faces joins the organization. At Kustomer, we’ve faced an extreme version of this as our company evolved from a mostly colocated team distributed across two offices to a team where almost two thirds of our teammates have joined as remote employees during a pandemic. This didn’t happen through hiring clones of our original team; we’ve needed new perspectives and skills as we’ve grown. Instead, we’ve been able to scale by keeping a consistent view of the behaviors and beliefs that make someone effective at Kustomer. Our company has captured these in our Krew Values, but we also recognize that there are behaviors that are specifically important to our engineering team. These beliefs help define our identity as an engineering team, and create a template for new engineers to follow.

We recently went through a process of distilling a set of Engineering Values from the patterns that already exist in our work today. We gathered ideas and feedback from a variety of engineers, engineering managers and senior leaders and then debated the results at some length. The results capture what makes our team different, and what behaviors help new members of the “Krew” be effective. Like any meaningful value these are tradeoffs, and when we choose them we choose not to do something else of value. Our belief is that embracing these tradeoffs as a team will be worth it. We asked a few of our engineering Krew to explain what these values mean to them, and we’re excited to share them with you.

Trust

Our customers’ trust is integral to our success; We prioritize building trust and work hard to maintain it

By Jeremy Suriel, Co-Founder & CTO

Trust has been built into our engineering culture from day one. It is an integral part of every engineer’s onboarding at Kustomer and is baked into our organizational design and team processes. To be specific, there are seven Trust principles that our team applies during the design, development, and deployment of our application: security, privacy, scalability, availability, Reliability, performance, and observability.

Why is it so important to us? Trust in our platform is critical to our success and has a material impact on the success of our customer’s business operations. It is something that is typically earned over time, can quickly disappear if not prioritized, and is very difficult to regain. Our platform is an extension of our customer’s products, services, and user experiences. And our customers invest time and energy into our platform to handle their customer data and provide rich experiences to their employees and users.

To this day, our team has done a fantastic job ensuring Trust in the platform. It’s reflected by our amazing customers and their continued investment in our service. I often hear how refreshing it is for new hires to be part of a team that is committed to Trust with every product release and every line of code we write. Each day offers opportunities to learn and improve our tooling, processes, policies, and procedures that directly translate to more trusted software, services, and support. I’m excited to continually invest in Trust as a core Engineering Value and witness the positive impact it will have on our employees, the success of our company, and the success of our customers.

Optimize For Impact

We will always have more opportunities than resources, and we want to spend time where it will impact our customers the most

By Joey Lappin, Principal Engineer

Startups have no shortage of awesome ideas for enhancements, features, and functionality. Along with all of those exciting ideas are the inevitable bugs, product gaps, and requests to extend the product that we did not originally anticipate. Even as we’ve grown beyond an early-stage startup and more than doubled the size of our product and engineering teams, the list of things to do continues to outpace our capacity to do them. That’s why one of our Engineering Values is Optimize for Impact. For engineers, Optimize for Impact means finding solutions that strike the best balance between the amount of effort involved and how far the solution goes toward solving the problem.

As engineers, we are passionate when it comes to contemplating the perfect solution to a problem. It’s in our nature to aim for flawless architecture or plot out the most elegant implementation. However, this approach often conflicts with the realities of a small engineering team with an abundance of things competing for time and attention. In most situations, customers cannot see behind the curtain, and are therefore only concerned with the end product; does it work reliably as expected?

Thinking of engineering problems in this way is exciting. It allows for something a bit like movie magic. When George Lucas was grappling with how to portray an intergalactic civil war in Star Wars, he didn’t try building actual spaceships complete with artificial gravity, laser guns, and engines capable of faster-than-light travel. The production would have gone over budget before a single scene had been filmed. Instead he had the special effects team build scale models of spaceships that were then filmed on a set. When those models were seen on the big screen coupled with distinct, if not completely scientifically implausible, audio effects of roaring engines and laser blasts, moviegoers saw what could be real spaceships fighting a real intergalactic civil war a long time ago in a galaxy far, far away.

Software works much the same way. Optimizing for Impact is about achieving a result that is a joyful experience for customers using the product, without committing to building an actual spaceship.

No Ego

Team results come before individual contribution; We can learn from everyone, and we prioritize unblocking our teammates

By Kathy Chang, SDET

As a test engineer, I’ve always had a front-row seat to the ego show. My most frequently sent Slack message is: “It failed” or “It doesn’t work”. In my early days at Kustomer, I clicked that send button nervously because I didn’t know what kind of drama would unfold. Would the developer ignore me? Doubt me? Rage at my audacity?

It turns out that there is no drama. No one even ironically responds with “It works on my machine.” Instead they ask for mundane things like request payloads and error messages. The biggest drama that ensues is the Holmesian kind as we Sherlock our way through the mysterious bug.

The same holds true when there’s a critical bug. Ideas, not blame, get thrown across squads as volunteers rally together to set things right again. After the dust settles, engineers share a report that details how we can take the lessons learned to improve going forward. Whether the issue stems from internal app code or external vendor outages, the prevailing attitude is that even when it’s not our problem, it’s still our problem — because customers trust us to deliver a seamless experience.

This kind of outsized ownership and openness isn’t possible with outsized egos. How can we learn from our mistakes if we don’t own up to them? Or innovate creative solutions if we’re not open to change? Of course, none of this is easy — everyone encounters imperfect circumstances every day. These circumstances can act as excuses to shield our egos. But at Kustomer, they’re opportunities to contribute and help each other build better software.

Believe We Can

Assume there is a solution; Look for things to build on in each situation and suggestion; Offer options and tradeoffs rather than refusals

By Oren Bukspan, Sr Engineering Manager

If you’ve had the chance to work on a rapidly-growing product, you know that delivering software rarely goes as planned. Even if you anticipate that surprises will happen, it’s hard to predict the exact hiccups along the way. To counter this uncertainty, engineering teams often develop a guard to minimize scope or complexity, which might mean frequently having to say “no”.

At Kustomer, we know that the best ideas can seem ambitious and difficult at first. Rather than letting that reality become deflating and lead us to say “no” and move on, we push ourselves to Believe We Can. By making this a part of our culture and identity, we commit to injecting a moment of optimism and intentionality before abandoning an idea.

Importantly, Believe We Can includes the word “we”; it is not focused on individual heroics, but rather on our collective ability to do something amazing together. For example, when dismissing an idea, it’s common to highlight what getting to “yes” might look like and why it is difficult, costly, or risky. By spelling out the challenges, we create space for our teammates to transform the request so that it becomes feasible or for others to suggest ways around those obstacles that we did not see.

Similarly, we keep this value in mind even when a request feels ill-advised or out of place. Rather than simply decline, our engineering team often talks directly to customers and stakeholders to better understand the underlying desire or pain. By framing the challenge as broadly as possible, we increase our odds at finding a solution (whether technical or otherwise).

While our team still looks for ways to cut complexity and ship more predictably, by pausing momentarily to Believe We Can, we build on each other to ensure we do not close the door prematurely on innovation.

Do What You Say

Follow through on commitments; Don’t say you’ll do things lightly; Be proactive about addressing obstacles, don’t wait to offer excuses

By Blaga Lund, VP of Engineering

Do What You Say — it sounds easy, but the natural flow of startup life fights against it. In a fast growing startup, everything moves at lightning speeds and requests come at you from all directions, no matter what role you play on the team. It’s easy to give people the answer they want, it’s easy to say “yes,” “sure,” “I’ll take care of it” at every ask. But as they say, talk is cheap. Do What You Say requires effort. You have to think carefully about what you can realistically deliver, set boundaries to protect your wellbeing, and do the work to understand what timelines are realistic. Then you can truly commit to accomplishing something.

This is important for personal integrity and accountability, but it’s even more critical as part of a team. Working on a team means that we all have to trust and rely on each other to do our part. If we don’t follow through on our responsibilities and commitments, that trust starts to crack and the impact ripples throughout the team. Not doing what you say has the obvious consequences of a failed delivery date or a dropped piece of work, but the less obvious impact is the one to the team culture. When there is a culture of accountability, we all trust each other to meet the expectations, values and goals that we commit to — it pushes us all to succeed together. On the other hand, it’s hard to move the needle when that trust is not there. Our goal here at Kustomer is to build the best product that we can, together. To accomplish that, we put focus on doing what we say and getting things done.

Do these values resonate with you? We’d love to hear from you.