From Customer to Employee: My Journey to Joining MongoDB

In this post, you will hear from Boris Bialek, who was a MongoDB customer before joining MongoDB as Head of Innovation in EMEA. Boris will walk you through how he began his career in the database industry years ago and what his journey has been like growing his career in a new direction.

After working with MongoDB for several years in my previous company as a customer, I became passionate about helping others embark on the same journey and assisting them in their implementation. The more I was able to work with MongoDB as their client, the more intrigued I became with their work culture, product, and career opportunities.

In my previous role, I focused on delivering a new product release every six months. This process began to feel like a repetitive dance and, after a while, I knew I needed a career change that would be more engaging. Moving into a client-facing role at MongoDB, as the Head of Innovation, was the perfect fit for me. Clients can benefit from my experience and I love the opportunity to showcase MongoDB, which I am very passionate about.

My first experience with a database

I was a student at the Karlsruhe Institute of Technology — the oldest technical university in Germany — when the move from the “mini computer” as the Digital VAX were called then to the PC was just happening. The latest craze at the time, was the news that Microsoft may come out with an operating system for 32bit. We were the first generation of Computer Science Masters graduates who would spend way more time on software than machine design, hardware, and chips. Relational databases and SQL were the database standards — actually the only databases really discussed. We even got a copy of Oracle running on our SPARC cluster. Building a sample SQL system that had airport codes and flight numbers was the intro assignment I received and I was instantly hooked. Databases are actually quite cool and you can do crazy things with them. Even today, I am still fascinated with moving data around and constructing complex solutions on top of data engines.

Over the years, I did a lot of benchmarking on distributed systems and the tuning and deployment of the database was always the linchpin of every project. You could scale any application server instance (even for monolithic applications), but the database was singular and anything related to availability was considered rocket science. Later, availability became a bigger issue looking for resolution. The setup of a failover cluster, replicated logs, and alike always had the chance of failing — especially in production. There was a wide group of “High Availability products” from various vendors out there — we fail to mention their names to protect the innocent here — and they claimed to make it “easy,” but true availability was not achieved and even today, the most advanced appliance systems are brought down completely for maintenance at lower levels or operate without a true three-node concept (unlike MongoDB).

Working with MongoDB as a customer

Over time, a number of other database concepts appeared but nothing really worked, and so the technology of relational databases continued to be it. Fast forward a few years, and I began working for a very large banking software provider, and we were sitting on a legacy stack with SQLServer. The data was divided into hundreds of tables to account for different data types and structures. Each time an upgrade had to happen, update scripts needed to be applied to fix even the most minor changes to the database schema.

A new data backend for a number of applications was designed and the idea to continue with the same concept and simply doing the same painful approach again was horrifying. I had done some experiments with MongoDB, reviewing how a document-based database compared to relational concepts. We decided to try a POC and were amazed — instead of using hundreds of tables, we ended up with one single collection of diverse financial instruments. The beauty of this concept is that you have instruments like bonds with dozens of elements and then orthogonal instruments like swaps with complete different elements and included sub documents describing the “legs of a swap” (and hereby we close the financial excursion).

Representing a financial instrument as a document is much more natural for any developer to use too. Instead of breaking the data into pieces and stashing it via Microsoft LINQ and Microsoft Entity Framework into a SQLServer structure, the MongoDB driver took care of taking the documents and storing them nicely for us. The development team quickly got up to speed and was able to introduce new features into our new data platform that were considered too complex before. The implicit availability and scalability of MongoDB freed us completely from managing both those aspects, allowing us to ignore those subjects all together from the developer’s perspective.

And finally, we actually met with the MongoDB team in person.They were there for us, answering questions and spending a lot of time to understand our requirements and direction and then guided us to major improvements along the way. The result of the joint journey was a product released with a 5X better performance versus the original SQLServer setup with 25% of the resource need! Development was accelerated on top and our mission of building a new data backend for our risk software solution suite was accomplished.

Joining the MongoDB team and growing my career in a new direction

After being a customer for three years with MongoDB, I happily shared our development journey with other prospective users. I also met more and more MongoDB employees who were all very personable and always focused on helping their clients and each other. After seeing this amazing environment and culture, I decided to apply for a role at MongoDB in Europe and had a large number of discussions with various employees. These discussions didn’t feel like interviews since they were very bi-directional and allowed us to identify the right role that was actually a fit for me. Nobody tried the “round peg - round hole” exercise that often happens in the IT industry. After several discussions, I became more and more excited to join MongoDB, and we finally landed together on the role of Head of Innovation, EMEA. In this position I am engaged with our enterprise clients and assist their data journey to ensure their executive development and operations teams have the same great experience with MongoDB that I had when I was a customer.

Even in my short time with MongoDB, I keep discovering that there is so much more to MongoDB that we did not exploit in my development days before. The amazing training schedule that automatically appeared on day one of my life at MongoDB helped me to understand why and how the folks I worked with were operating and how I could maximize my contribution to the team.

Four weeks into my role, I attended MongoDB’s sales bootcamp where I had the opportunity to hear from various leaders about how they do things and what works best in the context of MongoDB. Everyone from engineering to marketing to sales is always very friendly and was willing to spend time with new hires so that we could adapt and succeed in our roles. The bootcamp was so helpful that I am also planning to attend MongoDB’s New Hire Technical Training soon.

MongoDB is an exciting place to work, but what excites me even more, are the people I get to work with every day. Plus, MongoDB has a flexible PTO policy, which matches perfectly to my mountaineering and scuba hobbies!