Get started with Onna today
Our mission to make proprietary information accessible, useful, and private is a lofty one, and requires a team of smart, driven, and passionate people to make it happen. From San Francisco to Barcelona, Onners come from all backgrounds, identities, and creeds — and that’s where the magic happens. In our Ask an Onner blog series, we’re putting the spotlight on them. First up is Pavel Pratyush, Engineering Manager.
Pavel: My name is Pavel Pratyush and I’m an Engineering Manager at Onna. I’ve been in the software industry for almost 10 years now and with Onna since March 2020. It’s been an incredible journey so far.
Pavel: I wasn’t really looking for an exit from my previous company. But while talking with Onna, I realized that the projects and product itself are great and there’s lots of potential.
Other factors were the multicultural and diverse work environment, as well as the very talented people I now work with.
Pavel: Yes — it’s not every day you get the chance to work on a product that is so unique. You might work in fintech or in ecommerce, or even in the gaming industry, but the product that we’re building here, our Knowledge Integration Platform, it’s one of a kind. The challenges you get working on such a new and disruptive product, as well as the opportunities, are just amazing.
Pavel: Lots of different things, especially because I was the first Engineering Manager based in Europe. With a growing team we’ve also had to adapt how our processes are laid out and tracked, including upgrading our interview and onboarding processes for engineers, and setting objectives for individuals and teams.
Pavel: The engineering flow at Onna resembles a pretty standard product development flow. We have a team of seven product managers who are looking at various aspects of our product development so they can come up with the roadmap. Once they do, they discuss with senior engineers and the squads, at which point the roadmap is refined and delivered through sprints and iterations. Regular scrum, basically, with sprint planning retrospectives, daily stand ups, grooming, etc.
We also have chapter alignment meetings, which happen once a week to go over technical debt, design review, post-mortem solutions, etc. That is then transferred to the individual squads to get the job done.
Pavel: Onna has always been a very flexible company when it comes to working hours and remote options. We try to center our efforts on communication across teams, just to make sure we preserve our global work culture.
Pavel: When Covid hit, our homes became our offices, which makes it harder to maintain work-life balance. We tried to be supportive by looking at individual challenges and seeing how we can provide solutions across the board. For example, we realized that people were spending probably a bit more on utilities than before, so we added an expense allowance for that every month. We also realized that not everybody had a proper work setup at home. So there was an expense allowance for that equipment, too. We want to make sure we’re assisting Onners as much as possible, wherever there is a need.
Pavel: The main things I’d say are the scale at which we’re operating and the integrations we’re dealing with.
We are working at scale, meaning we have large customers who index millions of GBs of data every day. Thus, we need to make sure our systems are resilient, working 24/7 without downtime, and more. So there’s a huge scalability problem that we are solving here. And we are gathering data from a lot of different sources, which is where integrations come into play. We are getting data from Slack, Dropbox, Microsoft Teams, Jira, along with other external systems.
Each of these systems are worlds of their own — they have their own data structures and model their data in different ways. We bring in data from these different sources and standardize it, then we build a knowledge layer on top of that data. That integration itself, pulling diverse things into one single model, is very challenging.
So it’s not about the tech stack. I think the work we’re doing is a huge software engineering challenge, we’re just using the right technology to get it done. We use the latest versions of Python for our backend systems, the latest versions of Angular for our frontend development, all our systems are in Kubernetes clusters, all deployed automatically using CI CD, machine learning, etc.
Pavel: We always want to ensure equal distribution of seniority across the team, because as much as we need senior engineers, we also want to find and develop talent.
That aside, we are big on open source at Onna. We use a lot of open source components and we contribute to them as well. You can visit github.com/onna to look at all the open source projects we’re currently contributing to, including Python, Consumer for Kafka (called Kafkaesk), Node.js, and some of the senior developers are contributing to important projects like the GRPC, etc.
We are big proponents of contributing to open source and we value the involvement of our team members, whether they participate in the context of their work at Onna or in their personal lives.
Pavel: At the team level, there are sprint demos/reviews, where people are mostly celebrating the good work they did during that sprint. That’s the first stage. Then from time to time we do internal demos for all the projects and products that we’re building when we reach important milestones. First we’ll share within the product organization, then demo with sales, success, and others. That’s a way of celebrating success.
We also mention people directly in our #kudos Slack channel, where we recognize people and teams for achievements big and small. At the end of every Onna All Hands, we love to dedicate a few minutes to read through these kudos and celebrate together. And that’s awesome.
Pavel: It’s a very exciting time to be part of Onna. We raised our $27 million Series B in June 2020 and are continuing to grow considerably. We are going to be very ambitious on what we are building and our targets. Onna is also growing immensely on the go-to-market (GTM) side. If you look at our recent hires, we have ramped up our GTM team. This means we’re going to have more and more customers, and that means we will have even more usage of our system, and even more opportunities to work at scale.
The focus will then be scaling our systems with the influx of new customers we expect, and maintaining the engineering culture that we have and are so proud of. In essence, we want to make sure we are growing scalable processes, people, culture and everything along the way.