Sonar is a SaaS platform that enables companies to more effectively communicate with customers to drive revenue… It enables agents to respond to sales inquiries quickly; convert more users into customers by reaching them on their preferred channels; and build a closer relationship with customers by engaging with them over channels they actually use.
Each team is asked to select, explain, and rank their top 8 values in order of importance.
Customer Comes First
Our customers, and our customers’ customers, are our first priority.
Sonar was built to improve the interactions between businesses and their customers. To ensure that we are aligned with the needs of our customers (and of course, their customers), we rotate support so that everyone at the company can spend a day fielding questions and handling issues. While it can be difficult, this is how everyone can gain a true understanding of the current reality of our clients. We are close to our customers and are diligent about visiting their offices and getting feedback from the people who are using Sonar. Of course, there are various factors that shape our product roadmap but ultimately, the priority is the end product experience. Even as a small startup, we value building what our customers need over building what is easiest. For example, we never cut corners or make tradeoffs simply because of the limitations of our libraries. Instead, we’ll take the extra time to do it right.
Committed to Personal Growth
Education and learning is central to who we are and how we function as a team.
We are an incredibly learning-forward team. Everyone at the company is an avid student and together, we have created a unique learning environment at the workplace. Every other week, we have an Expert Night where we invite an expert in to teach the entire team about something. Whether the topic is sales or Elasticsearch, the Expert always teaches the entire team about something pertinent to our product.
Prior to founding Sonar, Neeharika was involved in teaching and sponsoring Rails School because mentorship holds a special place in her heart. She explains, “Neither of us [cofounders] have a CS degree and neither of us became software engineers on our own. We got help from friends and mentors and believe in learning by teaching and learning by doing. We value the fact that we don’t know everything and want all of us to be growing, improving, learning continuously.”
Whenever someone says, “I’m stuck on this,” it’s immediately followed by the sound of someone else rolling their chair over to help.
There’s a lot of collaboration on the engineering team (and team as a whole) and we plan to keep it that way as we grow. We aren’t looking for people to write code as quickly as they can. We want to build an engineering organization that enjoys teaching and learning from one another and supports one another in entering things none of us have ever done before. Whether you’ve had management experience or not, we’re looking for engineers who like to teach and take on difficult challenges as a part of a team.
Safe Environment to Fail
We ask for forgiveness, not permission.
At a startup of our size, each team member’s personality and background contributes significantly to the overall culture. Alex and Rebecca are both Hack Reactor grads and fearless, as are many people who self-select into a bootcamp without a traditional computer science education. They have helped set the tone for how we handle confusion (comfortably) and how we approach things we don’t know how to do (“let’s figure it out”). We are fortunate to have a lot of great resources beyond our team, which we frequently leverage. Finbarr (our technical advisor) and Gabe (a close friend to the company), are always available on Slack and help us solve specific, technical problems as well as review the scripts we write. Failing is very natural part of learning, and we are not afraid of it whatsoever. We’ve somehow eliminated any trace of imposter syndrome here and really love that part of our culture.
EQ > IQ
Productivity and success don’t always directly relate to technical experience.
Empathy is one of the common denominators at Sonar. After all, we were all drawn to Sonar’s mission to combine the efficiency of automation with empathy. With how much we collaborate and value learning, it goes without saying that your ability to communicate, express frustration, and empathize with customers is equally important as your technical ability. As a company, we do weekly lunches combined with retrospectives (aka our “feelings meeting”). We eat lunch together and talk about how we are. We sit around a table without our laptops and talk about anything we want to share, whether it’s about relationships with our significant others, or feeling frustration in losing a sale. Without updates or context, we wouldn’t know how else to support or celebrate you!
Heavily Team Oriented
We each have a lot on our plates but we work knowing that we have the support of the entire team behind us.
A great example of how teamwork manifests itself at Sonar is how in our internal hackathons. Once a month, we host a hackathon to allow everyone to spend a day working on something that they’re really excited about, or in some cases, something that has been really bothering them. The only rule is that it has to be something that is unrelated to our OKRs. It’s a time when everyone can work on something independently and whatever it is, you can still get help from your peers. It might not be on the roadmap and it might not be something that is especially exciting to me, but if you ask for help on a problem, I’m going to treat it like it’s my problem too. At our last hackathon, Rebecca made a translation service to translate messages using the Google translate API and Sarah, Matt worked on refactoring the API, and Sarah and Neeharika worked on calling through Sonar together.
Actively Practices Inclusion
Women make up half of our company.
Our cofounder is female. Our first engineering hire is female. Our only product manager is female. Inclusiveness to us means eliminating that hesitation for anyone to voice their opinion. As a small team, we want everyone to feel like they have a seat at the table when we discuss our OKRs or our next hire. We don’t center all of our social events around alcohol and we’ve found that conversations and discussions are richer when they include a diversity of opinions. We believe in creating a workplace that welcomes everyone, regardless of gender, age, technical background, or race.
We break every feature down into the smallest components and ship code every day.
Right now, we’re not focused on perfecting every feature and we don’t write tests for every line of code. We operate with an “80/20 rule” in mind which means, if it’s 80% of the way to what you’d consider to be perfect, then it’s already ready to roll out. We’re very conscious about how code will look to us a few months from now but we force ourselves to not obsess. It’s the balance we’ve agreed on as a team to iterate quickly. It’s well understood that if it’s 80% of the way there, it’s good enough to push. Iterative deployment is the name of the game. (We should mention though that once every two weeks, we devote an entire day (Squash Days) to fix bugs, re-write tests, or make other minor improvements.)