I lead Weaviate’s Solution Engineering team. Right now, we’re only four people. Still, we combine a broad knowledge of different types of software, different domains, and applications, and we use that knowledge to help customers get the most out of Weaviate. We’re also responsible for running Weaviate in the cloud for customers who would like to have a managed service.
About Solution Engineering
In a way, we’re the storefront. At this point, most customers want to use vector search for something but don’t know how to get there. Others are fascinated by vector search but don’t yet know how they’d use it; they’ll ask us to suggest use cases. So, we begin with discussions about what kind of data they have, what they want to build, and how Weaviate can help them. Next, we build a proof-of-concept or create a small version to demo and establish a business value. The final step is getting something into production and customer-facing.
Along the way, we often share customer feedback with the Weaviate core team on features we should add or enhance to Weaviate. So, we interact with customers, the developer community, and people on the technical side; we’re a transit point for a lot of information and ideas.
So, we’re that feedback loop for the core team. We share how people use Weaviate and pass along feature requests. We also work with the research team when customers request a novel feature. Finally, we even work with the DevRel team, informing them of new use cases they might want to blog about.
Since solution engineering is heavily dependent on interaction and effective communication, you might think that it would be hampered in remote-work situations. I must admit that I sometimes miss meeting in front of a whiteboard or covering a wall with sticky notes as we work things out. But an unexpected benefit of Covid-19 was that it showed us new ways to do solution engineering by forcing us to work remotely and by pushing the adoption of remote tools and workstyles. And those new ways have their advantages, both for the people doing the work and the work itself. In the remainder of this post, I’ll explore some of the tools and processes we use to perform effectively in a remote environment and even turn our remote-first working style into an advantage.
Working with customers
Whether customers come to us with a specific request or are just curious to learn more about vector search, the first thing we do is plan a meeting with our Customer Success team. As the head of Solution Engineering, I try to be in all those meetings, along with at least one other team member. If that meeting is productive and we schedule a follow-up, for example, to define a proof of concept, sometimes we set up a private Slack channel, so that users or clients have a direct line of communication with us outside of email. Some clients, such as government agencies in the Netherlands - where I am based - aren’t permitted to use Slack, so we set up a Teams integration for them; we try to be flexible because every company has its own preferred method of staying in contact.
Providing responsive service across all time zones remains a challenge. Right now, I have one solution engineer based in Australia, who is well-positioned to cover Asia; I’d like to find another person on the U.S. west coast.
There are three of us on the Solution Engineering team here in the Netherlands, but I’m the only one born here; one is from Turkey, and the other is from Moldova. Because we’re a small team in constant contact with customers from all over, it’s crucial that everyone is proficient in both spoken and written English.
How we keep in sync
We typically have a 15-minute stand-up meeting every morning at 10:00 a.m. CET, which is 6:00 p.m. for our Australian colleague. We use Jira to keep track of what people are working on. Miro’s “mind mapping” software is excellent for collaborative ideation. We also use Jamboard and of course we use Slack amongst ourselves. Another tool that’s useful for asynchronous communications, especially with clients, is Calendly. That also can feel a bit weird at first; it feels as if you’re saying, “Find a slot on my calendar and figure it out,” but I try to use it more like, “Let’s find a date that works for you; here’s my calendar.”
We are here to help
The Solution Engineering team does not do any heavy coding. We don’t build the solutions for customers, but we create bits of code to load a data set or send x number of queries to figure out how fast Weaviate works on the customer’s data. In addition, we do remote coding sessions, including pair programming. Being able to work on things at the same time helps reduce any sense of isolation.
In a remote setting, you must be intentional about maintaining team happiness. In my previous job, I worked with several search engineers, and we had a short stand-up meeting every morning. So, if someone had dark circles under their eyes or their body language slumped, I could immediately see something was wrong. At Weaviate, we build team spirit with hackathons; we log in to a three- or four-hour session—people can drop in and out—and we build something outside our normal work scope. Recently, we tried out a competitor’s product to see how easy it was to use it and whether it had features worth adding to Weaviate.
One thing on my to-do list is to hire a solution engineer who’ll be dedicated to our open-source community. But for now, my team shares that responsibility. We have a Slack public space where anyone can sign up for free to ask questions. As solution engineers, we see the community as a source of information and treat it as we would a client.
Our goal is to make Weaviate the de-facto standard in vector search. The Solution Engineering team contributes to that goal by nurturing our community and ensuring clients get maximum value. The CEO of Elasticsearch was my boss at my first internship; it started out in Amsterdam, and I worked in the same building. I saw it grow from nothing into a big company. I have the same feeling about Weaviate.