Episode 10: How to Build Impactful R&D

Hey listeners, welcome to SphereCast, a podcast all about technology, technology advice, technology inspiration, and how real entrepreneurs have used technology to build their businesses from the ground up. If you're wondering how technology can support your business goals, rest assured, our guests have been there and done that.

Everybody hates change. Indeed, there's nothing more comfortable than the status quo. But what happens when you and your organization are change agents, literally the ones in the company keeping a finger on the pulse of the market, tracking industry headwinds, trying to stay ahead of the game, recommending company pivots, and, well, change? Welcome to research and development, or R&D for short.

Hey, it's Lukasz Neja from SphereCast, and this week Isabel speaks with Boris Korenfeld, Director of Engineering over at Waze and Carpool products at Google. Yes, Google, you may have heard of them. Prior to his run with Google, Boris held various executive leadership roles within research and development. Korenfeld's R&D experience began at Hewlett-Packard, and eventually moved to an Israeli transportation startup called Gett, where he was tasked with tripling the size of the R&D organization. At Gett, Boris held both Chief Technology Officer and General Manager roles before eventually taking his director role at Google.

Having architected and led a handful of R&D organizations, Boris has now become a wealth of knowledge around the best ways to construct and run research and development. On the podcast, among many other things, Boris speaks to the ideal R&D structure, if an ideal even exists, explains whether R&D is possible at small- and medium-sized companies, shares some lessons learned from having to triple his R&D staff at Gett, and even goes step-by-step on how to build a successful R&D organization for any business. So without further ado, here's our conversation with Boris Korenfeld.

Hi, Boris. It's great to have you here. Thank you for accepting our invitation to speak at our SphereCast.

Hello, Isabel, and good evening from Israel. Thanks for having me in this podcast.

Thank you. So, Boris, you've had a really very exciting career working for some great brands, which we're going to talk a lot more about. But let's start with your journey. How did you get started, and how did you get to where you are?

Okay. I will start from the beginning. I was graduated bachelor in computer science in 2000, and I started working in Comverse. It was quite famous company back then, building product and solution for telco companies like voice mails.

I worked there as an engineer, developer, C++, Java, stuff like this. After that, I moved to Mercury. It's also famous company in the whole engineering world. I worked as an engineer as well. And after that, I was promoted to team leader, and did two roles of team leader. During this time, HP acquired Mercury, and we all became HP employees.

And some time, I was offered to actually build new product for very interesting innovation, because HP has an innovation console, and everybody can come with some idea like a startup, and if it's a good idea, HP funds it. And this was the case. So I built from scratch R&D team for such startup. And it was quite successful. I was offered a new one, and after that, another one.

So overall, yes, it was very interesting for me to build new products and build new R&Ds. I liked it very much. And just in the last innovation, we all tried to use our private connections, and sell this product. And I actually connected Dave Waiser, CEO of Gett, and scheduled the meeting to show the demo of our product. It was product for real user monitoring for mobile applications. And it was a good fit for Gett. And after this demo, I was offered VP R&D role in Gett.

So this is how I moved to Gett for the VP R&D role. And after three and a half years, we did some R&D reorganizations, and I hold two roles. One was CTO of Gett, and another one was general manager of one of the business units, B2B business unit.

And after some time, I decided to do the next step, and I was actually offered to lead big group in Waze in Google, Carpool and Waze Core Applications, and this is where I am now.

Wow. That's quite amazing. You must be super, super creative. By the way, I love Waze. I think I was one of the first adopters when I told everybody, "You have to download Waze. I don't go anywhere without it, even if it's the same place as I go." I love that they tell me if there's traffic lights, or police, or anything. So you have a very, very cool job.

It's a great application and it's a great community behind this application. So I'm really lucky and happy that I joined this great team.

Yeah, I can only imagine. So you obviously had quite a successful career, especially leading R&D organizations. So tell me more about that. What's an ideal R&D structure for you? How do you build it?

This is actually a great question. Many people also ask me what's the best R&D structure. And do you want a scoop?

Yes, I do.

Research and development is not about some sort of ideal structure. It's about what's ideal for you and your company. You have to analyze many aspects which will lead you to the optimal org structure for your company. But if you do it right, it will take your company to the next level.

So, I think I need a little bit more information there. So how do I go about doing that analysis? What are some of the triggers that would help with R&D org changes?

Okay. There are plenty of possible triggers, and I can actually name a few of them. And one of them also worked for me.

Common triggers are that there are significant changes in the company mission, vision, or strategy, or company decided to pivot. For example, pivoting from B2C to B2B can be a trigger. It's also happened in Gett.

Significant growth or scale of business can be a trigger. Changes in the competitive landscape or loss of competitive advantage. Scaling R&D organization. For example, for me, it was the first trigger for reorganization. CEO of Gett asked me to triple R&D from 70 to 200 people after we got $400 million funding.

Not an easy one, but a good problem to have.

Yeah, it's a good problem to have, but it's not simple task to do. But this is definitely a trigger for reorganization as well, because organization of 200 people and 70 people is completely different organizations.

Another trigger can be low productivity or efficiency in R&D organization. For example, many cross-teams dependencies, bottlenecks, etc. Or you are just a new R&D executive, and it's always good to examine the current state.

And of course, there are many others that it's not so important to mention right now.

Okay, so those make a lot of sense. So what happens next? Let's say our company or my organization gets to one of those trigger points. How do I act when that happens?

At the end of the day, the mission of R&D is to empower the business, right? And first of all, stay calm. Big change, stay calm, and always keep in mind that the mission of R&D is to empower the business.

And you should start with understanding the business goals. So just deep dive and understand very well the business goals of your company for the mid-term and the long-term. Now understand how R&D can help in achieving them and how R&D can give competitive advantage to the business.

Another consideration, or aspect, that you should actually learn and understand how it impacts the org structure is type of service and product. Is it a software as a service or on-premise product? It impacts many things like frequency of releases, for example, continuous delivery versus a release once in several months. It impacts the quality of product when you release. When you release on-premise, it's very, very important to do the best testing you can before the release.

Another aspect is competitive landscape and the market. Are your market needs changing rapidly? Do your competitors react faster to these changes than you? And so on. So always assess business aspects before making plans to change an organization.

That makes perfect sense. Can you give me an example of maybe how one of the triggers at one of your organizations caused you to make changes?

So we talked about the triggers, so in my organization, I was asked to scale R&D from 70 people to 200 people, and that was the trigger, but we also had a pivot in the company focusing from B2C to B2B. It's also was a trigger for reorganization.

Okay, well, that makes a lot of sense. So how do you act when you identify one of the triggers?

When you identified one of the triggers I mentioned, first of all, stay calm. It's going to be a big change, and you have to be calm when you plan it and execute it.

But first of all, start with assessment of the business aspects. At the end of the day, the mission of R&D is to empower the business. So you have basically three main aspects to understand.

The first one is the business goals. You should understand very well the business goals of your company for the mid-term and for the long-term. Now understand how R&D can help in achieving them, and how R&D can give competitive advantage to the business.

Another aspect is type of the service and the product. Is it software as a service or on-premise product? It impacts many things like frequency of releases, continuous delivery versus a release once in several months, quality of product, etc.

And the third aspect: competitive landscape and market. Are your market needs changing rapidly? Do your competitors react faster to these changes than you? And etc.

So once you analyze this business aspect, you will understand better what's your business goals as R&D manager.

That makes a lot of sense, too. But then, okay, so I go about that, I understand what are my business needs, and then what happens next?

Okay, so now you understand better your business goals for the long term and the mid term, and this is actually the time to define or derive the goals for your new R&D organization, and what you want to achieve as an R&D executive.

So I already mentioned that R&D organization is to empower business, and you have to define the goals for your organization, how will actually it empower the business.

I can give an example in Gett. So after analyzing the business of Gett, actually it's very similar to Uber and Lyft. Gett is a mobility company with professional drivers offering taxi services for B2C and B2B markets.

So I defined seven goals for Gett R&D organization. The first goal: shortest time to market. Gett has a highly competitive and dynamic market, and it's changing rapidly. So it means, actually, I have to think about how to reduce dependencies between people, teams, minimal number of people to take decisions, continuous deliveries, etc.

The second goal for Gett R&D was highest velocity. We should deliver more business value with the same number of people. R&D is very expensive organization, so you cannot afford expand it without limits, and you have to think how to bring more business value from the organization you already have.

The third goal is end-to-end ownership to improve quality of service and increase engagement. Same team should be responsible for design, development, quality, development of the product stability, performance, and monitoring in production.

The fourth goal I defined was how we can balance between flexibility in resources and stability of teams. And I think the main dilemma of the R&D manager is maintaining flexibility and stability. It's all about balance. You can't maintain both 100 percent. And in this case, squad models, that I will talk about later, can suggest a good solution for that.

And the next goal I defined: career path development for employees. There are many professions in R&D organizations: backend, mobile, web, QA, data science, project management, etc. All employees want to have somebody who is an expert in their profession and can mentor and coach them in their career path development. And it's in conflict with the full-stack teams, one manager leading such a team, because it's extremely hard to find a team manager with expertise in all these domains.

The next goal I defined was effective and productive collaboration with product organization. If product and R&D organization are not aligned with the structure and domains, it will create a big mess and inefficiency. For example, for each R&D manager, it's crucial to have counterpart with the same area of responsibility in the product organization.

And the last goal that I defined for myself was scalable structure. If you plan to grow, it's important to build the structure for scale, even though it's an overkill in short term, in order to avoid restructuring by adding several tens of people.

So these are the goals that I defined for myself before I started planning restructuring R&D organization in Gett. And once I finish the plan of restructuring, I have to verify that all my goals are actually achieved in this new organization.

Wow. That sounds impossible. That sounds pretty unachievable, so kudos to you. I imagine you were successful and you were able to achieve those goals, all seven of them.

Lucky man, obviously. Yes, we achieved all these goals, so it was a teamwork. It was very hard. It was long-lasting journey. It took several years, but we did it, and we had a very good R&D organization in Gett.

Wow. So, yeah, that explains why you were so successful. Now, gravitating a little bit or switching a little bit here, a lot of our listeners are more in the medium-sized enterprises. So do you think that R&D is also feasible for a mid-sized company? Are there some playbooks or some models that will work well for a mid-sized company?

Okay, as I already said, there is no such a thing like best R&D org or some model which will work perfectly for mid-sized organization or in other size of organization. But once you have defined the goals to be achieved, we can look at several existing models and adopt them partially or fully to your specific organization.

I strongly recommend to look at the squads model invented by Spotify. To my mind, it has the optimal balance to achieve all goals that, for example, I defined for Gett R&D. All these seven goals that I defined, they can be achieved with the squad model of Spotify.

That's interesting. Are you able to describe briefly how the model works?

To describe it in details it will take time, but I will do it briefly.

So first of all, squad model invented by Spotify is heavily based on agile methodology, and actually it's some kind of evolution of agile.

The squad model has a number of organizational building blocks. Some are more important than others, and some less. Let's start with the squad. It's a basic building block for the rest of the organization. All of the development work is done in squad, and it should be 5 to 10 people.

Tribe is a collection of squads that own a domain and is self-sufficient. The size should be 40 to 80 people. And very important aspect in the tribe is that it should be very low dependently between the tribes. How you check it: if 80% of the features are developed inside one tribe, so the division of your organization to tribes is successful. It will never be 100%, never, because if you have one product, it's impossible. But if you achieved 80% independency between tribes, it's a great result.

And the last basic building block in squad model is a chapter. It's about 5 to 15 people size, and it supports career development, personal growth, and happiness of people. So chapter is actually built per technology. It can be chapter of backend, chapter of mobile, chapter of web, chapter of QA, and chapter of data science, etc.

So the squad model has a few prerequisites that help ease the adoption: org-wide agile literacy and acceptance, daily standups, work visualization, work in progress limits, agile planning, retrospectives, and tech infrastructure standardizations: CI/CD, automation testing, AB testing, code reviews, code style enforcement, etc.

So why this model actually works for this seven goals that I defined? We have actually good balance. On one hand, tribe is independent unit, so 80% of the features are developed in the tribe. All chapter leads, they report to tribe manager. Squad are comprised of chapters, and squad is something which is flexible.

Okay. What is squad? This is the main part. Cross-team dependencies are complex and difficult to manage, so the best way to avoid this is by doing work in autonomous teams called squads. And they have clear vision, mission, cross-functional, system ownership, it's a two-pizza team, and the squad leadership is product owner, chapter lead, and agile coach.

So I mentioned the dilemma of R&D manager: how to be flexible in resources, on one hand, and have some stability, on the other hand. And this is actually what this structure gives us. Squad is something flexible. You build squads from chapters, and actually employees, individual contributors, always has one manager, it's a chapter lead. And this manager is responsible for their development, career path development.

So on one hand, we have stable organization and every employee has one manager. On the other hand, tribe manager can actually jungle with the resources and build squads according to the business needs.

That sounds like a really flexible way to go about it when an organization doesn't have the resources or the amount of employees that someone like Gett would have. So thank you. It definitely piques my interest, something I want to learn more about.

And maybe going back a little bit to your experience, I'm interested in what you mentioned earlier about a reorganization in Gett that led a triggering of a tripling of your R&D staff. What did you learn from that? What were some of the main lessons from that?

There are many lessons learned there, because it was a long-lasting process, and it was very valuable and educational for me. But if I would choose three main lessons, I would choose this ones.

Planning an R&D reorganization is generally a big and painful process. People don't like change, by definition. And this is maybe the most painful process for them.

So my lesson learned is that you have to invest appropriate time in building the change plan. Deep dive into details. Small details are very important. Don't leave it at a high level. Okay? Just run in your head how it will work in the end, and find maybe challenges, issues, problems in the new structure, and fix them in the planning stage.

And most importantly, invest in building the communication plan. It's a key success factor. When you communicate this change, it's extremely important how you are doing this.

So for me, 4P model was a very successful approach to communicate the change. And 4P stands for purpose, picture, plan, and part. I will not describe this communication model in details because it will take a lot of time, but I recommend to Google it and read a few articles regarding this model.

I've heard of the four Ps, but they were different Ps. I'm definitely going to check this one out.

Yeah, there are many 4Ps models, and they are different. So I'm talking about the 4P stands for purpose, picture, plan, and part, and it's a model for communication of changes.

Perfect.

The next lesson that I learned maybe is usually leaders invest a lot of efforts to explain why this change is good for business, but ignore why it's good for the employees. Because you do this change for the business, right? To empower the business, to align with the business. And in many cases, R&D executives forget about the employees, the purpose of employees in this change.

During R&D reorgs, it is critical to communicate to employees what is in it for them. What do they gain from this change? And if that is communicated properly, it's a big push for success.

And the last lesson, and maybe most important: you should have on board a very strong management team, because this is actually the team who will lead the changes in the field. It's impossible to run it alone.

So these are the three lessons that I can share with you, the most important lessons.

Yeah, I feel like I could spend the next three hours asking you for a lot of details and examples and questions. But we're getting to the end of our podcast, and the last question I kind of want to ask you is, what's the last thing you want me to ask you to wrap up this podcast? What is one thing we haven't covered that you think is important for our listeners?

If I have to wrap up, I would like to leave you with one last thing.

Be listening to the triggers and adjust your R&D organization to your evolving business needs. I listed a few of them, but don't miss them, because business is relying on you, and trust that you as R&D executive will be listening to these triggers, and adjust your R&D structure to the business needs.

Be brave and lead through the changes. It's not an easy thing to run changes in your organization. People don't like changes, as I already mentioned, and you have to be brave leader to engage them and lead through all these changes.

And be managing. Perform analysis, build the right change plan, align all stakeholders in the company, and build outstanding communication plan. Obviously, it's not easy. It's a big risk, but if you are listening, you are brave, and you are managing the change, then the reorg of your R&D can give an immense value to the company and create lots of opportunities for your people.

That's perfect. That's an amazing wrap-up. I would say those be listening to the triggers, be brave, and be managing, I think those are characteristics that we should all be looking for. But I can see how for an R&D organization where you're constantly bringing new ideas, new change are so much more important.

So thank you, Boris, for joining us today on SphereCast. I think our listeners are really going to enjoy it. I think there's a lot more that we could unpack, so maybe we'll invite you to episode two at some point. But it's been wonderful to spend some 30 or 40 minutes with you. Thank you so much for that.

Thank you again for having me, and I will be happy to join to the next episode. It's very interesting for me, and I think I can help other R&D executives to sleep better at nights when they're running the change, if I share my experience and my lesson learned.

A special thanks to our podcast guest this week, and once again to our sponsor, Sphere Partners, for bringing this episode to life. If you enjoyed this episode, drop SphereCast a five-star review on iTunes, and share this content with your network.

For any relevant links or notes from this episode, check out our podcast website at www.sphereinc.com/spherecast. And always remember, when you think you can't, technology can. See you next time.