Back

Explore Topics

Subscribe

Stay up to date with
Bizzabo's latest

Follow us

Bizzabo news | 31 July 2017

BizzaValues: How the R&D Team Dares

Noam Whartman

At Bizzabo, we put people first. That’s why we launched the BizzaValues program to help us further cultivate our company values and culture. Here’s what Front-End developer Noam Whartman has to say about “We Dare,” our value for July.

Now that’s Daring !
When you look up the dictionary definition of daring, you will find a description of a bold act, an attempt to take on a challenge that takes courage, or to walk bravely into an unknown venture. What you won’t find in the dictionary is what gives us the confidence we need to dare.

Our surrounding environment is what triggers us to break through the barriers of our comfort zone and translate our “What if…” exploration thoughts into “I’m going for it!” daring acts. In a workplace environment, the ability to take that next step initiates from a special mind-set. On the one hand, it requires self-confidence in the ability to pull something off, and on the other hand, it requires the encouragement of our colleagues and a rock-solid trust of our supervisors.

At Bizzabo we take pride in our culture of encouraging daring initiatives, whether they come from an employee from R&D, Customer Success, Sales, or the Marketing Team. We understand that being afraid of change or failure will leave us standing still in an ever-changing environment. We always push ourselves to be better and to think outside of the box, which is reflected in our “We Dare” BizzaValue:

“We encourage ourselves to dream big and swing for the fences. We dare to fail but always fail forward. We question the norm and embrace change. Who dares, wins.”

R&Dare
As a small R&D team, every working hour is extremely valuable. Any time spent exploring initiatives outside of our quarterly work plan could delay the delivery timeline of a new, long-awaited feature. This means daring comes with a cost: Is this adventure worth it in the long run?

It’s easy to avoid taking risks, to let the company’s leadership make the decisions for us and have them be accountable for any bad calls. But that means new initiatives would always come from an overview/macro perspective rather than a more on-the-ground/micro perspective.

We spend our days writing code, planning and engineering the structure of our product. We know the technical point-of-view better than anyone. Thus, it is our responsibility to raise a flag and to lead a change whenever our technology becomes outdated, when there are better solutions for our problems, or when our working procedures become inefficient.

Our R&D Team is based out of our Tel Aviv office. The Israel Team

The trust of our supervisors and colleagues is earned by hard-work, professionalism and transparency—and is crucial for building the confidence we need to introduce and stand behind our initiatives.

When a team member wants to promote his or her idea, the company’s mindset will alway be:

“If your proposal can bring value to the company and you think you can pull it off, who are we to stand in your way? Dare and Own It !”

React is here, time to make our move
One of the best examples of a daring move was shifting our front-end JavaScript library from our legacy Backbone to React.

React is an open-source JavaScript library for building user interfaces. React was developed by Facebook for internal uses, and eventually contributed as an open source. Nowadays, React has a thriving community of individual developers that contributes and improves different aspects of the library. React aims primarily to provide speed, simplicity and scalability.

About a year ago, we came to a crossroads with our front-end library, Backbone. We’d been using Backbone since the beginning of Bizzabo, but it was losing popularity among developers worldwide. The industry’s focus shifted to Angular (by Google) and the newcomer – React. For our R&D team it was clear that we needed to come to a decision, and the sooner the better.

The R&D Team goes out for a food tour.

We also dare ourselves to have fun.

After weighing in our options we decided to go with React. The buzz around the new library was undeniable, the ideas behind it and the high performance made it seem like it was here to stay. On the other hand, the new approach and coding style that comes with React, meant that there was a significant learning curve for the developers. But that wasn’t the only challenge that would come with migrating the Bizzabo platform to a new JavaScript library such as React.

We would also need to integrate Backbone and React code throughout the process of the gradual migration (no small task). Above all, there was always the risk that React wouldn’t catch on and would be replaced by the new best thing before we even got the hang of it.

Taking all the risks into consideration, we evaluated the long-run benefits of the move and decided to use the redesign of our Community feature as a pilot for switching to React. Writing a large feature with React gave us a better understanding of its advantages, and the scale of the task we were up against. After a successful pilot, we convinced the company’s leadership that we were capable of handling all of the challenges that would come with this decision and that this would eventually lift our abilities to a higher level.

Today we can look back with pride and compare ourselves to other companies that were in the same position as we were, and have just starting their migration. While they are still suffering from growing pains, we are swimming deep in React. Our product performance has improved, our time to delivery is faster, and our developers are up-to-date with the latest technologies. The end result: Happy programmers and a more attractive pitch for recruiting new front-end developers.

(Interested in joining the Bizzabo team? Click the button below to explore our open opportunities).

As a bonus, our long awaited mobile app upgrade is on its way using React-Native. With React-Native we can write a mobile app with the same coding language used for our web app, and then translate it almost seamlessly into native Android and iOS apps. This is a huge win for us since there is no need to develop two separate mobile apps and we can use a lot of our existing code base for the app.

None of us were here last time this happened
Here’s another example. A few weeks ago the whole R&D team took a week off from our everyday product tasks and focused on much needed maintenance tasks and infrastructure upgrades.

Bigger R&D teams usually have a dedicated DevOps (development operations) engineer in charge of infrastructure set-ups like these. For smaller R&D teams (like ours) these kind of procedures are part of the routine and the required skill-set for every software developer. So while we often have to make infrastructure upgrades, it’s not often that we have to make one that is this huge.

In fact, we realized that the last time the R&D team led such a big infrastructure change was more than 3 years ago—and none of the current R&D team had a hand in it.

The main task was to move all our servers to Amazon VPC (virtual private network) to make our servers more secure. This would in turn help us with security compliance—a concern for our rapidly growing company—and give us access to Amazon’s new features from now on.

In the end, we built all of our servers from scratch and took the time to write manuals to serve us for the next few years.

Needless to say, these types of maintenance procedures are extremely sensitive and if not done properly can lead to significant system downtime and customer churn. Therefore an activity of this scale must be well-planned, structurally executed, pre-tested and created with a fallback plan for each step.

Getting the product managers and company leadership to prioritize maintenance tasks is never easy, especially when there are severe risks involved. But it is our responsibility as the R&D team to promote and highlight the importance of these tasks, while ensuring that we take all the necessary safety precautions to minimize downtime experienced by users. Causing an unexpected downtime scenario is a programmer’s worst nightmare, which often results in the “if it works, don’t fix it” mindset.

Pull-up break.

Taking necessary risks is all part of the game when you have a live system with active customers. Our job is to reduce these risks to a minimum and prepare for any scenario.

I dare you to dare
Two years ago, Bizzabo took what may be our biggest daring decision ever. We pivotted from being a mobile networking app to an all-in-one event success platform. This dare ultimately became a huge turning point in the growth of the company and always serves as an inspiration for us to dare and to trust our instincts while moving forward as a company.

Our mentality as a company to encourage daring is a huge part of our success, and definitely something that I don’t take for granted.

Every employee here makes it their goal to create an impact so that they can say: “Hey, that awesome new initiative? I did that, that was my idea!” It makes us happier and more productive to know the we are challenging ourselves and trusting our ability to do so.

Of course, when you dare you sometimes fail. But If you give it your all then there is no reason to be hard on yourself. Learn from your mistakes and come back better the next time around.

Encourage your employees and colleagues to dare, I dare you!

Click the button below to explore daring opportunities at Bizzabo. 

Stay up to date with Bizzabo's latest.

You may also
be interested in