Get to know your design partner: Hila Mazinter, VP R&D at JFrog

Local partners and champions can help you, entrepreneurs and early-stage startups, when building your product and trying to penetrate the market. To help, Vertex Ventures is publishing a series of interviews with these Israeli executives, with unique (and exclusive) tips and insights. This is the second post of the series, featuring JFrog’s VP R&D: Hila Mazinter. You can read the first post, with Rapyd’s CISO, here.

Hila Mazinter is a person worth listening to. She has over 20 years of experience in establishing, developing and delivering enterprise software. Prior to JFrog she held several executive positions in global hi-tech companies like SuperDerivatives, SAP AG and CheckPoint.

As someone who has successfully built best-in-class R&D, operations and service teams, Hila understands the needs of a growing engineering organization and how business requirements influence the team. Last but not least, at JFrog, they eat their own dog food: the R&D are using the tools they develop themselves. This gives her some interesting insights into how she manages development.

Let’s see what she has to say:

10 Insights from the Field for Dev Tools Entrepreneurs

1.What is your top priority as a VP R&D right now?

How to execute and deliver in the best and most efficient way that will answer all business requirements. Of course, this means high-quality, speedy deliveries. I am guessing that my answer applies to all VP R&Ds.

Efficiency is a big issue. We have a constant feeling that we can always do better. There’s always room for improvement, so we work on those aspects. For example, we look at where we spend too much time and which parts of our process could be optimized. Then, we try to increase efficiency.

The real challenge is how to create accurate plans. We have six sprints in a quarter. So we have to make sure we follow the decisions we made in the planning phase, and not have reality take us in a different direction. Obviously, we change our plans from time to time, but it can’t be a regular thing. Starting something and not finishing it and constant content switching — these are all bad practices that eventually decrease efficiency.

It’s a challenge, and so we try to balance between short and long-term planning. The difference is usually in the detail level. We have deep dive technical designs for the short term, while the long term includes more loose planning, which we tighten as we progress.

2. What are your tools and methods for continuous improvement in the R&D department?

With regards to the ongoing delivery process, a retrospective is our way to get better. We keep looking back and learning. We review all aspects, starting from planning through development, delivery and production.

We mainly use Jira for our SDLC management, but retrospective is not really supported by it. We compensate for these gaps by using excel (obviously 😊), an internal BI tool, and additional internal processes.

For production quality, we use information that is collected by our BI system from several sources. These include customer tickets, production logs, failure events and more. We analyze this information to learn what areas require our attention at the highest priority.

In general, we measure all kinds of KPIs. The purpose is mainly to allow each team to make better, data-supported decisions. But we understand that we need to be very careful: each KPI has its impact and it’s not necessarily a good or expected one.

3. How do you onboard a new team member?

We created a cross JFrog R&D onboarding knowledge source that is relevant to all team members. It includes topics like architecture and fundamental issues. The content is recorded and available to all new employees.

On top of these materials, a specific plan is built per product group and the new joiner. We believe that the theoretical training must be mixed very quickly (within two days) with real hands-on tasks. Those tasks are taken from the actual backlog, though not such that are on the critical path. This allows us to quickly get to know and evaluate the new employee and vice versa. Most people want to start contributing as soon as possible. We try to make sure that they get the whole picture and are not getting too much of a micro perspective.

In addition, there is the informal process of getting to know the company culture and environment. This has obviously been a challenge in the past year, but it’s an important part of onboarding that we can’t neglect.

4. How do R&D and DevOps work together — and what can be improved?

The DevOps at JFrog is part of the R&D organization and serves horizontally all R&D product groups. The group functions and manages its SDLC the same as any other development group.

Our cloud production environments are managed by a separate group of engineers with similar skills, yet they work as part of the support organization. This is to align with JFrog’s top standards of customer support and happiness.

5. What are your main challenges with cloud development today?

Testing complexity, loud and clear. Specifically, knowing that we conducted all possible scenarios prior to deploying a new version while still allowing continuous deployments.

• Addressing unexpected scenarios — Our hybrid and universal offering creates additional complexity and enables endless use cases and flows that are hard to predict. We put a lot of efforts to identify and address those prior to production deployment.
• Integration and cross products — There are also scenarios that relate to integration and flows between different JFrog products. Both the simulation part and the cross product and integration part could benefit a lot from third party products that could help us with the ever changing and evolving challenge of testing.
• Load — In the cloud, there are many processes and services that are impacted by load. Load is diverse and can be created by many scenarios, like many customers doing something at the same time, one customer doing one thing in a high volume, and many other possibilities. So we try to simulate and predict all these cases as well.
• Vendor reliability — We also encounter problems that start with the vendor, so we must have a resilience plan to handle these kinds of situations. We have to identify what could go wrong and think about how we tackle each situation with minimum impact on the customer. This part of the testing scenarios must also take place.

We put a lot of thought into how to manage and control our quality aspects and use the gathered experience to adjust, improve and get better.

Using third party tools to address this challenge is not out of the question.

6. How do you handle production incidents? What are you still missing?

We have several channels to get alerted about and manage production incidents.

• Customers — they open tickets in SF, which automatically generate a Jira ticket that the support or SRE team handles based on severity and priority.
• Monitoring & Investigating — We use multiple tools, such as Logic Monitor, New Relic and ES, to analyze, troubleshoot, and investigate errors that occur in production.
• Analytics — Investigation and analytics take place through our homegrown BI system. It combines support tickets, usage data, product logs and different events.
• Slack — A lot of our internal communication takes place through Slack, so a lot of information resides there as well.

We could benefit from a tool that aggregates all data sources, investigates them, and gets automatic insights. However, we’re also wary of adding more and more tools to our stack. We would only use such a solution if it was integrated into our existing stack.

7. How much of the security aspect do you own?

We work hand in hand with our CISO, covering all security aspects from regulation to delivery and production.

We first use our own product, JFrog Xray, to scan our artifact repositories and builds for security vulnerabilities and license compliance information as part of our DevSecOps shift left. We commit to not releasing anything with known vulnerabilities (medium and up) and we continue to improve our own delivery and our solution by using it ourselves.

We also conduct continuous internal hacking (red team), penetration tests and threat modeling. These are run by external teams. We make sure to use different teams all the time so we get a fresh point of view.

All in all, security is a holistic process that involves many processes and we always strive to own more of them.

8. How can a founder convince you to partner with him as a designer?

Being a design partner means that we need to invest time and attention. We’re happy to do that, but we need to understand the value we will gain. So the founder needs to be specific and straightforward, understand our needs and explain how they will be answered by using their solution.

If we have a real interest in the solution, we don’t care if it is still at an early stage. We are willing to invest time and effort in building mutual vision. But we don’t want to waste our time when the solution obviously isn’t right.

9. How do you determine how much you are willing to pay for a new service?

We first try to assess the ROI: what will we gain from the tool, how much time and effort it will save us and which resources we’re investing today because we don’t have this solution.

We also look at other similar solutions that we’re familiar with and try to compare cost and value.

An important note: the pricing model must be scalable. The pricing has to make sense after taking into account that the customer will grow its number of users or services. So the price must have a reasonable curve that the customer can follow.

10. Any personal tips to founders who approach R&D?

Do your homework. Study the organization and understand all its relevant aspects: customers, its stage, location, deployment status, attention span, and more. Pay attention to who you’re contacting and what their motivation is. In other words, be prepared, just like you’d expect anyone approaching you to be.

Originally published at https://www.linkedin.com.