Deciphering the R&D Operations Manager Role, Nofar Ben Kereth

In this episode, Nofar Ben Kereth R&D Operations Manager at Cloudinary helps us demystify this emerging role...what it even means, who it's suited for, and why every engineering organization will need such a function eventually.

Episode Transcript תמליל הפרק

Hebrew, then English בעברית ואז אנגלית:

(Opening music)

Dev Interrupted with Yishai Beeri and Nofar Ben Kereth

Yishai: Welcome to Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's successful podcast for engineering managers. Here we will talk about everything that hinders engineering managers. I am Yishai Beeri, CTO at LinearB.

With the announcement of our big fundraising round, we are excited to bring you the podcast in Hebrew. We will host leaders from the industry to talk about everything that hinders engineering managers, those who work with them and those who want to one day manage an engineering organization.

In this episode we are happy to host Nofer Ben Kereth, R&D Operations Manager, at Cloudinary. Hi Nofar, nice to have you here.

Nofar: Hi Yishai, nice to be here.

Yishai: Great. So as usual, we'll start by asking you how did you even get here? Tell me a little about your journey throughout your career, which led you to become an engineering operations manager.

Nofar: So this is how - I started industrial and management studies at Shenkar, I studied there for 4 years, and actually I started working in the field of operations and project management there. That is, not yet in the high-tech industry. During my studies I managed the operation of the student union, which actually included working with external suppliers. I managed the position, the union’s budget, I produced the union’s job fairs. I continued this at the same time as working a regular day job, later I continued in the union. I held a significant role, albeit for a short time, but I really learned a lot there. And from there I continued to a consulting company called Simple - where I held two positions, I started as PMO for one of the clients - where I really got educated on the job. Both at Simple in general and at this client specifically, I also learned a lot about how the organization actually works. What does the organization need? How do you identify the challenges of an organization? And after two years, I was promoted to be a team leader, managing PMOs and clients in all kinds of fields, which was very, very interesting. From small start-up companies to very, very large organizations. But I was also in the areas of hospitals and health funds (edit for clarity: Israeli health services). So I really saw a lot and it was very, very interesting to see and also to compare the organizations and to understand that we actually didn't invent problems, we all have the same problems, even in Low Tech, in a hospital, and in high-tech companies.

״R&D operations management is first and foremost a matter of character."

Yishai: This role of PMO, and the management of PMOs – did this already involve teams that develop software or is it more in areas that are Low Tech?

Nofar: Both, engineering teams and entire engineering organizations, and also an area of ​​project managers in the field of implementations, of new tools in health insurance funds, this has always been in the software area. I've also done things that are less technical, it was really very interesting to see some sort of spectrum of areas, and that everyone ends up encountering the same problems whether it's software or not. After almost 4 years I decided to move to the next level. I started working at Cloudinary, where I became the R&D Operations Manager. I ended up in one position and it developed and changed completely and my responsibility increased. Over time I started doing more and more things and touching more areas. And today the role really dominates many areas within R&D.

Yishai: Yes, we will talk more about this in depth, about both how this role evolved and how such roles develop in the industry, but tell me about when you came to Cloudinary, how did you make this transition from a consulting company? I mean what did you see, what were Cloudinary looking for? And how did it suit you? How was that transition?

Nofar: So first of all I was looking to be in one place. A consulting company - this means that I am on the road all day, physically, but also all the time among clients and I wanted one place that is mine, where I grow, in a specific area. That doesn't actually change, every second. This dynamism, I really liked my time consulting, but at some point it was already a bit too much and I was looking for one place. I specifically wanted a product company and I came to Cloudinary to really manage the operation. It started from managing the tools, managing some processes like Agile, Scrum all kinds of buzzwords like that.

Yishai: How many people were at Cloudinary then?

Nofar: So when I arrived there were almost 50, today we are 130 which is our growth over two and a half years. It is a very, very big leap and we continue to grow and this is really one of the challenges of the position.

Yishai: Is it just the size of the R&D?

Nofar: Yes, that is just in the R&D. The company itself has doubled, we were 200 or so, and today we are 500.

Yishai: Wow. So you come to a company with 50 developers or an R&D organization of 50 people. And who do you report to? Who put you in the position? Who did you work with?

Nofar: So Uri is the VP R&D, he has been my manager from the beginning.

Yishai: Great, so tell us a little about what the role is. What is operations management in R&D. What was it like when you arrived and how has it changed - then we will be asked a little about what it means today.

Nofar: Usually when I am asked what the position means, I say that I am responsible for all processes that are not production. All short-term, long-term planning processes, quarterly planning, sprints, methodologies, work. How do we implement this within Cloudinary? There are many methods. Excellent methodologies, but we cannot take it as is, and apply to our organization. So really see what our flavor is at Cloudinary. 

What suits us within our culture? I manage all the tools and the implementation of new tools, everything related to dashboard indicators, everything that comes out of the monitoring of the dashboards and basically also drawing conclusions from these metrics, and understanding what we need to do to improve. Basically a lot of different projects are derived from all these indicators. And if I already said projects, then also management of all projects. We have extensive cross-team projects, both the methodologies and project management, what is project management in Cloudinary R&D, i.e. what tools do we use? How do we manage the project itself? In terms of communication, stakeholders, everything related to this and in general the optimization of the processes and the effectiveness of the engineering. It's a bit up in the air, but it really includes a lot of things, and again it starts from knowledge management and Jira, and work methodologies through  on-boarding courses for new employees. which is really very, very great versatility in the role.

Yishai: So you also say "how do we conduct ourselves on a daily basis"? But also how do we train new employees to be productive in Cloudinary?.

Nofar: Completely. Not only productive, but also how to become familiar with our culture and how we do things and not just what tool I use and what work environment.

Yishai: Okay, so you're talking about how we learn, how we improve, and where they meet. I don't know, people like Scrum Masters or similar positions that are actually accepted today to think that an engineering team learns on its own, that's part of its essence, they do retros. It's learning to improve.

Nofar: It's teams - of course they learn on their own, and this is also our guideline. They need to learn, they need to improve, they need to understand on their own where they need to learn, to improve. But my job includes two things, first of all to enable them to do these things. How to direct them, how to do a retro correctly, and with what tool to do the retro, how to draw conclusions from it and how to make sure that things happen and at the same time also connect them to some uniform line across the entire R&D. I mean, we are indeed 20 teams. We really want them to run autonomously and for them to be independent, but we do need some kind of line that connects us, we still have dependencies. We are still one organization. We are still, everyone still works at Cloudinary and it is important to have some kind of connecting line, which everyone understands and connects, and from this line any team can do anything. I don't want to say everything they want, but everything they want that is within the framework.  I work well and I deliver well and I also deliver the right thing. And not only not only effective.

Yishai: So what, how do you choose, or how did you choose? What goes into the uniform line, versus where do I have freedom? For example Kanban iterations or each team works in the format that suits them.

Nofar: Yes, so I don't have black and white here. To me, it is very important that we speak the same language. Let's understand together where we are going, that this quarter will not be completely disconnected from other quarters. We have the joint Cloudinary story that stems from the product. We work on this a lot together, but what objective do we have in general for these two organizations of product and R&D? And how does the team fit into this thing? So it is from this point of view in terms of the processes. So again this common language of the same rhythm and the same tools and the same methodologies, for me personally it is very important. That is, for example, it is important that sprints are the same length so that we all finish and start at the same time, and we can also adjust the organizational processes to this objective. That is, if we are now planning a quarter so that we know when everyone can deliver. It could be that it is a dependency that everyone has to delve into at the same time, so that it will be at the same rhythm, they are working at the same rhythm.

Yishai: So what example is there of something where each team chooses and has some independence in the area of ​​the processes?

Nofar: So I will give a very small example that is significant for teams, for example with our daily (edit for clarity: daily standup). We put emphasis on the content of the daily, but everyone will do it as much as they want and in whatever constellation works for them. There are teams that do it every day because it's important to them. Some teams do it 3 times a week and some teams do it as needed every week. So there is a lot of room to play around in what we define, but there's still that uniform line of what we want to come out of that meeting or from that process.

Yishai: Ok as far as your team is concerned? How does it work? I imagine you have your VP R&D, who else is on your team? In your first team? How does it look?

Nofar: So there is one employee under me right now who is basically wearing two hats. One, she has her teams, teams that she specifically came to help in their day-to-day, right in the sprints to see that they take the methodology in the right configuration, that they are effective, that they understand how they enter into R&D work. So it's actually some kind of hat that is more specific to the teams, and also it has the wider hat, which is wide projects with implementations of things. Management of engineering tools. So right now I have one employee, we will expand soon and we are going in the direction of more guilds. I mean, we really try to make the groups and teams independent. That is, end to end in terms of the roles, DevOps go into the actual teams, automation and all of it is really end to end. So are project managers. Soon there will be PMO and program project managers within the groups themselves and there will be some sort of horizontal guild that will help communicate.

Yishai: So the PMO, will be in teams and you will be a kind of head of the guild

Nofar: Yes there is also a team…

Yishai: So you help them.

Nofar: Exactly there will be both a core and a guild.

Yishai: Got it. But in terms of your team, I mean the team you report to is then you, VP R&D, and the heads of the groups is the forum?

Nofar: Yes

Yishai: Got it. Tell me a little about what. What do you think in your experience is needed to be successful in such a position?

Nofar: All operations and project management roles, to me, require a lot of  strength of character. I mean we - yes you have to study, and yes, you have to have the technical knowledge and the tools and the methodologies, but you will see in this field people who know how to close things, get things moving, take something and do it from start to finish. Even if you don't fully understand the field. I mean, you have to learn a lot of things, but not be in the details of everything, and apply this with people where this affects their day to day. 

So I think that first of all it requires a lot of character and how you approach things and how open you are, and how well you know how to push things. Of course. A lot of patience. But some kind of adaptability and dynamism which is very, very important and of course there will be the right foundation in terms of what I know, and what I bring to the position. Industry and management in my opinion can be very suitable. But what is anything…that is, of course, we are talking in the field of the high-tech area, so everything is a little more tech oriented. This is important, because you have to actually understand the other side. During the last few years it was very important for me to understand the programmers, so I went and studied a little SheCodes, it really helped me understand how they think. Although I will not sit down now and code something, absolutely not, but it really helped me to understand how they think and what problems they encounter on a daily basis, and not just in theory.

Yishai: And do you see that this understanding enabled you to do something differently in the conversation with the developers and the team leaders?

Nofar: Absolutely absolutely it allows me to understand what they say completely, and what  they mean, and sometimes what it is based upon. Of course, experience is also evident, you see more and more, and every team leader works a little differently and every team leader manages a little differently. But yes, it really helped me understand.

Yishai: If you had to think - what is the hardest part of the job? In the end, there are things you do and are used to and it flows, and there are things that are more difficult. Does it feel like this, "fighting uphill"?

Nofar: Right

Yishai: So what is the most difficult, what is the most annoying?

Nofar: So I think that matrix management is like that, because it's a loaded title, that’s the hardest thing. In the end, you are not really the manager of these people and you have to drive an organization of - I have 130 people, in another place it will be 500 people. And all…

Yishai: So you need to be a little bit afraid of Nofar...

Nofar: It's true, it's true. Some say they are afraid. So yes, it is motivating so many people, each one has an area that is important to them. The way they know how to work and sometimes there is a little bit of flexibility in what I want, in how they are willing to change the way they work. So I think that this matrixonian management draws people after you. It's a difficulty and it kind of connects me to what I said about character. You have to know very well how to connect with people and understand where their pains are and where you can help them. You can help them and that's ultimately what I do. But yes, in my opinion, this is the biggest challenge, in all positions, project management, operation. A thousand titles…

Yishai: How do I move people who are not my reports, while needing to make an impact and change.

Nofar: Yes exactly

Yishai: Tell me a little more about how you see, even within Cloudinary, this role. When you arrived and how it has evolved, but also in the industry - people you know from different companies, this world of operation management, sometimes it's called project management? Sometimes the truth is - it has a lot of names, but they are all in the same area of ​​how I, on the one hand, direct the executives to deal with strategy and there is someone here who takes care of delivery and moves the entire organization in the direction of delivery. This role has been changing in recent years. Has it evolved at the industry level, what do you see, both at Cloudinary and in general, of how this position has grown?

Nofar: So first of all it's a relatively new position. I think that today most organizations already understand that it is needed no matter what the title. Although maybe we need to put some order in what each title does. But yes, it is a role that has become quite, I don't know if to say it is required more and more, but more people understand over time that it is needed. 10 years ago you would not have seen this in any organization. 

Today, most engineering organizations have at least one such person, and in my eyes it is also starting, there is also starting to be a trend of this happening earlier. I mean, even small startups, bring someone who has control over the entire organization, and sees some kind of overall picture, and not just the picture of the code and the technical parts, and the production, something that is more holistic. And this position also gets more and more responsibility over time, if we used to look only at project management and maybe someone who looks at all projects, then now we also look at processes and how to make the organization more effective, and how we measure this, and then also to do something with these measurements. Not only measure, but also have someone who is actually a kind of go-to person who knows a little about the whole organization, or knows a lot about the whole organization and has answers, or at least he knows how to direct the questions to the right places. 

Yes, I'm very happy that there are organizations that understand the need for this position because it's really witnessing a change in the field. You really see how the organization changes, and how the organization is helped by this function and little by little it is required more and more, and people build teams. And this is us. I also see it in the community of project managers that I manage, that really is growing. The community also talks about it, but the community is growing and you can really see that this position is becoming very, very necessary.

Yishai: And in Cloudinary you describe a process where, on the one hand, this role grows, becoming a team. On the other hand, there is some process of decentralization, of putting branches of this role into groups or teams. So what? How do you decide if it is something centralized or something decentralized? Or what do you decentralize?

Nofar: So first of all it depends a lot on the stage of the organization. If the organization is from the get-go designed as separate groups that can run ahead and is at a stage where it is able to do so. I do believe that all the functions should be decentralized, but as I said before, connect it to the general line of the organization. The very fact that a group can, in fact, have all the functions and run ahead, is something that it is, it really allows for a very, very high delivery ability. To put it into the proper framing, but on the other hand, yes, there needs to be a team at the core that sees the whole picture, because when we decentralize then everyone actually sees their own area. So yes, you need someone to see the big picture. So yes, I think this is the right direction, with the asterisk that we should always see how we connect to the core.

Yishai: And you mentioned a bit about the community that you are helping to create. Soon we will dive into the story of the community itself. But what do you hear from the people there about how this position has evolved? How is it, what do they see or do they see in the industry in terms of challenges, say, do you see a lot of decentralization, like what happened in Cloudinary? Or do you see that it is still centralized?

Nofar: So I think the majority right now is centralized, from what I see. In general this role looks very different in each organization. Myself included, when I arrived at Cloudinary, I came to position A, and it expanded over time and really changed, and I was given more and more responsibility, so every organization sees it differently and every organization has its own needs. It really depends on the culture, it really depends on what the managers are capable of doing, or what the organization has defined for managers to do or not do. How tolerant the organization is to accepting change and implementing them as well. So right now I don't think the trend is necessarily decentralization. I hope it goes there. I also believe that the teams and all work methodologies will move in that direction. And I believe that the same will go for us.

Yishai: So this situation, where this role is very different between organizations - is this part of the definition of the role in your eyes, or is it a symptom of the fact that this is a new role, there are still no mature and orderly definitions of what I should expect in the role?

Nofar: I think this is somewhat the essence of the job, because really every organization has different needs, and every organization works differently, and every organization has a different culture. And what I said about the managers, I mean really every organization has a different management culture and everyone knows how to do things in a different way and there are organizations whose teams will find it very easy to implement work methodologies like scrum or kanban and there are organizations that will need the help. Precisely in this area I can say, for example, that when I arrived there were no cross-departmental projects. That is, there was no need for proper project management, and today we have this need. So I think that this versatility, and among companies it is very much the essence of the job, but you will hear that in the end the job comes down to helping engineering teams by assisting them and being more effective and paving the way for them to do the work they know how to do.

Yishai: Got it. Then the question arises of someone who specializes in such a position in company X and then moves to a new company, and in fact the position is completely different. How do you take experience and knowledge and methods gained when it is different at every company? So how do we progress or how do we transfer this knowledge from one position to another position?

Nofar: So first of all I see it as an interesting challenge. And there is no one thing here, that is, what you did. If you did apply scrum methodology, so you go and learn kanban and you read and you understand, you try, and you change. There is no, there is no answer for how to do that. And that's how you'll succeed, I think it also has a lot to do with character and dynamism and the ability to adapt and the ability to learn new things, and also go and assimilate them. An interesting challenge for me.

Yishai: Tell me a little about the topic of managing up. At the end you have a boss, VP R&D. How do you conduct yourself and manage towards the boss in this position?

Nofar: So I think the first thing is to demonstrate where the organization can be helped, and where are the areas that the organization needs to improve and can be better. And why should it get better? I mean, it's not only here that needs to be improved, and here and there, why? What will this give us? And how will it help us and how will it help the VP R&D personally? And it also depends a lot on the other side. I mean, it's clear that the job is also one of the responsibilities, it's to be able to show these things and to be able to sway the management after you. But on the other hand, organizations that bring this role, these roles need to really understand that they need to be open to change, that they need to be open to see where we are wrong and where we can be better. So it lies on both sides. I think it's mostly, show where the engineering organization could be better and why.

Yishai: So this means that part of the requirements of the job is to look for what else I can or should do, and not necessarily what they defined for me because the issues that were defined for me have gaps in them and are not always known or very transparent to the management.

Nofar: Right. Sometimes, these positions also don't come with any kind, for the most part. Sometimes there are the problems that the organization knows it needs to address, and they don't come with some kind of grocery list of where the organization needs to improve or what needs to be done to improve it, but really it's the ability to see the places those hidden ones, the places no one gets to and they can really move the needle.

Yishai: You have, on the one hand, a place close to the ear of the big boss or whoever runs the engineering organization, and a lot of power that also comes from this definition of the role of let's find out how to improve, as well as a lot of initiative. On the other hand, you need the trust, the trust of the developers and the team leaders. How do you do it without being perceived as the "long arm of the management", and it always creates or can create some kind of situation of someone else from above and imposing things on us?

Nofar: Right. This very much connects to the matrix management I said earlier. But I think it's a role where you have to be a people person. It's a bit cliche to say, but you have to get along with people. And again the role is not only top down, at least with us. I strongly believe that at Cloudinary, in general the culture is very much to share with everyone. So, yes, there will be things that in the end we will decide and do, but it is very much in cooperation and very much in explaining to the teams why we are doing them, and giving them the space to express their opinion and what works less for them and what works better for them, and let's change, and let's adapt to a specific team. And it's a lot to show where it helps them. One of the first things I did at Cloudinary was to automate all of the work in Jira withGithub and Jenkins and this also “bought me” personally the open door to the developers.

Yishai: Because you saved them time and made their lives easier?

Nofar: Yes, but this is an example that shows them very much where it helps them, but as soon as you show why they do it and what the reason is, then I think you sweep the people after you. Sometimes neither. Yes, there is nothing to be done, not everything will be accepted and certainly not by programmers.

Yishai: There is also a situation where you know how to represent the needs of a team or a certain group, if something hurts and there is some need, that through you they manage to raise it upwards or get more resources to make a change in some area because there is a conversation with you, there is actually a way to promote their needs ?

Nofar: Totally, totally. And also - over time I became that persona, and this is something that is very, very important to me.

Yishai: So a little love and a little fear.

Nofar: Yes Yes Yes. Maybe we should have gotten them to talk.

Yishai: We will do another episode...

We mentioned a little about your activity in the community. Tell us a little more about how you started doing it? How did you get to that? What does it give you?

Nofar: Yes, so actually I manage with 4 other amazing women, a community of project managers. Today we are already 2000 project managers in the community which is amazing. 2000 in Israel - we haven't expanded abroad yet, we'll get there. Yes, that just shows how crazy this field is, so I've been there for a year managing the community. The community was established 3 years ago. I joined, I was very active in the community and they contacted me to ask if I wanted to join. Really amazing community, there is a lot of support and help and sharing, and it's like this field because it's still new. It is new... not new, it is still emerging. So there is really a lot of common thinking and we do a lot of meetings and meetups and a lot of content, and really help each other.

Yishai: If this is a 3-year-old community, then most of the metups have been remote until now.

Nofar: It's true that they were remote. We also try to meet now in this period and a little before COVID. So, yes, a lot remotely, but connections were made there that are really hard to explain. We also have all kinds of mentoring programs that have created a lot of connections. We also have meetings that are just over coffee in the morning, and then we get to know the women in the community as well and very, very interesting connections are made there. So yes, it's a truly net community. A kind of house for project managers.

Yishai: And can you put your finger on what kind of content or questions or sharing happens that are technical questions about how to do something in Jira or how to deal with a boss who doesn't understand the role? What, what, do you see drawing them...?

Nofar: That's it... that's it. It ranges from how I do this in Jira to how you implemented this process, or how you manage quarterly planning, to fundamental questions about the role itself, and how I build a role from scratch. Many women build this role from scratch. I say women because this is a women's community.

Yishai: This is true, but to say that this position has some kind of bias or attraction to women, that there are more women in it than other similar positions in high-tech?

Nofar: The truth is that I have also seen many men in the field, because I am in the community, so I mostly see women, but also many men in the field. Also in my previous position at Simple, so I saw a lot of men in the space. So I don't know if it is unambiguous.

Yishai: Okay. So you say, the community also talks about the technical aspects but also about the process aspects?

Nofar: Yes, we also try to have our meetups - where there are also talks but also a lot of debates, yes, there is always the content and also there is always someone who will come to lecture. But for example our previous physical meetup, we started in circles, we brought essential questions about the day-to-day life of the position, starting with what are the challenges in your day-to-day and all kinds of questions like that and we started with half an hour, each circle discussing these questions and it was a resounding success. And we also try to do things that are fundamental to our region. In this area, for example, we are going to map all the roles and what they do, and make some kind of definition of each role. It's very, very hard work. We really want to lead this field and change it and be part of how it shapes and changes.

Yishai: I think that such definitions help a lot in the maturation of a field as a field of occupation. In the end, the management of some start-up sits down and says "We feel we need *something* in this position." Wait, is it a release manager, is it a project manager? Is it developer experience? What, what do you even need to bring? And in Israel, quite a few managers in these fields are doing this for the first time, so they have never recruited or managed someone from this discipline, so I think it will be very helpful.

Nofar: Completely

Yishai: Setting expectations, what skills are needed for everything, when do you need it? When do you need it–yes, so you really intend to publish some kind of guide of what this job looks like?

Nofar: Yes. Yes. completely completely. It is a very difficult job because it has to be both very precise and a lot of information has to be collected. I mean that's what we know. It's not necessarily what it should be, we should really do some research and something else that is an example of the "essence of the job" area we'll call it. What we are doing now is dealing a bit with salaries, and we did a very large salary survey. According to positions, according to years of experience, according to the size of the company, which will really help people and people in this position, to understand what they should demand in which position. Something that is not yet established enough for anyone to know what to ask for or what. What is right for the field.

Yishai: So it also makes it possible to talk about the engineering of a career, what does a career mean in the world of R&D Operations or any of the different names for the positions.

Nofar: Totally… there are so many names…

Yishai: Yeah, so it sounds like a need. It sounds like people are looking for this knowledge to know where it's going.

Nofar: Absolutely, these needs arise in the community in a genuine way, not needs we invented - it arises.

Yishai: Okay, and if you need to know more about your position, also as your experience in general in Cloudinary in the role and in the community. Anyone who wants to enter this field? Wants to build a career for herself. What, what should they think about, what should they emphasize, how would it be best to prepare for it? By the way, where do you come from for such a position other than, as you described a course of studies and consulting, where do you see entrances or transitions to such a position?

Nofar: So. Even people who are from engineering often make this transition. It's not super common, but they do it too I think...

Yishai: Really developers and team leaders?

Nofar: Yes Yes Yes. The team leaders usually don't, usually not because they already have some kind of path that they have paved for themselves, but with us recently someone from QA became a project manager right here in our company, so I also see such changes, and I think that again this story of character connects to me . A person who likes to lead, likes to change. They like to look at the challenges and solve them and not only in the technical area but very much in the personal area, and the effectiveness of the organization. So I don't think it's strange to come, with a technological degree for this field - it will be a more difficult job. So anyone who is project management oriented we’ll call it, they can totally do it.

Yishai: Tell us a little about the interaction with people outside the engineering organization or different departments: sales, marketing, customer success and others. Where does this role meet them?

Nofar: So the strongest relationship I have is probably with the product team. I talked a little about the fact that we do the quarterly planning and the sprints, so the work is very, very close, I personally work closely with the VP Product and now a product operations function joined us, so these are such roles. We work closely to define things together. I mean it's very nice that I will define how quarterly planning is done in engineering, but where does the product come in and what emphasis should they give and what preparations should they make. And us too of course. After we plan, we do some kind of transition on the plan and challenges. So my work is very, very close to the project.

Yishai: Can you give us examples of what falls in your place versus what falls in product operations? Sounds like close areas to the point of overlapping.

Nofar: Yes completely completely. Then for example, in sprints. So in the sprints I will put more emphasis on the work methodologies and how the team should implement and how we can be more effective and the product operations will put more emphasis on how to bake the stories in a better way. How do we write requirements and how do we create acceptance criteria more correctly, and how do we also make sure that the engineering works on the right things and not just writes cool features, but how it connects to the overall picture. And how do we give the greatest value to our clients, and how to really, how to write an objective correctly. If we look at the picture of the quarter. So yes there are areas that overlap, and there we will work very, very closely and in the rest we will communicate more. And of course product operations is also responsible for the entire area of ​​betas, and what is alpha and what is beta, and what is early access, and how we release things and how we do training for the rest of the company. Yes.

Yishai: So, with some examples I understand the world of needs, of R&D, versus a product in the areas you mentioned - if R&D wants more time for non-functional and wants to invest in non-functional. Are you their representative in front of Product Operations? To say "come on guys, in this sprint we need to produce more non-functional capacity". Or is it R&D directly in front of a project?

Nofar: So the dream, and the truth that happens with us in most teams, is that this R&D pair of an engineer and product manager will know how to work together so well and communicate so well that they know when the R&D agenda is needed and when a product is needed. So most teams really know how to do it, we'll be more specific. Is there a fixed capacity that we want to leave for this as an organization? Is there any specific quarter that we now say we are focusing on separating into microservices. I don't know, I'm just making it up - so really it's the ownership of the teams. We are the enablers of this thing.

Yishai: Got it. And with some attraction to the bigger or generic things. They are now making some significant change - let's create capacity for it. And you describe that in fact product operations is a new world in Cloudinary, it is not something with a similar seniority to yours. So what? Were you involved in the construction of this, or even in the understanding that product operations should be produced?

Nofar: Yes yes I was first of all involved in the entire construction of the position itself and how we are, as well as in recruitment, and also probably in on boarding. So it is absolutely something I would be a part of. And it also made me and our project operations function to work... It hasn’t been a long time, yes, but already we work very closely and well. And even before I worked with them, I still worked with our VP Product, this gave the best example of how to work properly together. So I see that this is also our connection and how we will work together in which we will present things, it will greatly benefit you that the teams will work in the same way and learn the ways of communication.

Yishai: And is product operations something that also falls under the umbrella of Women in Project Management? Is this to you part of this basket of roles and jobs that your community is talking about?

Nofar: Yes - some of the roles, yes? The rest probably, they may not receive sufficient value. Although there are people who do both roles at the same time, meaning it can be one role.

Yishai: True, there are also organizations where product and R&D are together.

Nofar: So yes, there’s a lot of people like that––that will be in our community. They just won't get the full support. It could be from other women who do, but it's not something we're putting emphasis on right now, maybe more so later.

Yishai: Okay, so we talked about the strong relationship with a product. What about other parts of the organization, even more distant?

Nofar: Yes. For me personally, it is very important that we work with other departments. Support, CS' CSMs is very important, starting with the fact that we work together, and we work quite closely and also for example on call, which our developers need to solve, and support needs the developers, and it is very important to work well together and it is very important to get to know each other and know the language . So we do a lot in this area. I can tell you about something very interesting that we do with every new developer who comes to Cloudinary, they join our Support for two days, solve tickets with them. And they are always terribly skeptical at first, but in the end they really go out of there borderline dazzled, also from the level of the Support. And this also helps them a lot to get closer to the customers and to understand when they ask for something on a call after that. Or when support asks for some kind of solution, so they really understand each other, and also on a social level, they create relationships there that are really good later for work.

Yishai: Do they occasionally return to "reserves" in this matter?

Nofar: Anyone who wants to can do it. So yes they come back... and this is really some kind of the smallest process we have done and it created a very good relationship between the two departments, so it is important to me personally, also of course, also in the process area that we do all kinds of triage of important bugs for customers in such things, but it is more important to me to bring the departments closer together on the communication level. We did all kinds of things, for example we also brought in, we did some kind of process with CSM who every quarter do real life customer use cases for us. Three CSMs come and tell us about how the customers use the new features that have been released, and which use case is interesting, and this really connects the engineering to the business as well, and what the customers want, and where the customers' problems are. And that creates tremendous value in what they do next in practice. But also at the level of communication between the departments and how we are involved with everyone.

Yishai: So this sewing - of how you build relationships between the departments, and how you time both the visits or reserve duty or on-boarding service in support, and the use cases,is this your job? I mean, that's what you're saying here, I recognize a gap and offer a solution that's how it's done. We will strengthen the relationship.

Nofar: Exactly

Yishai: Which is another extension of the role of the project manager and it spills over into the issue of onboarding new employees in R&D. You mentioned a bit that this is also an area that you touch. So really what? What are you doing in this area, of  strength building? In the end, hiring managers do this work, recruit someone who is usually responsible for the on-boarding of the managers. Where does this meet you?

Nofar: We call it NHC - it's New Hires Community and actually, this need arose during COVID. I mean, it's not something new anymore. COVID is not new. It's been two years, it started with COVID. We recruited a lot, we continued to recruit during COVID, even during lockdowns and it was very difficult to onboard new people. Not at the technical level, at the ecosystem level, and how do I fit in within R&D and what is the culture here? And how do I know people and where I am even in the organization hierarchically. What groups are there around me, and we decided to establish some kind of we called it a community because we really wanted it to be something that they would also be able to go back to after that and get to know people, and it's actually on-boarding which is not technical. 

Obviously, the manager has the responsibility to do technical on-boarding and introduce the person to the areas and tools and how the team works, and here we provide some kind of solution that is more R&D inclusive and available - we'll call it a course or program that gives a taste of all the R&D, we're starting. First of all, it's 4 days. Every day we start with a peer discussion. We have the HRBP who comes to every peer discussion like this and raises some kind of a little more personal question like this, then we give a taster, each group head comes with their team members and gets to know the whole group and what they do and what they are responsible for. They put a lot of emphasis on the personal aspect. We are already a lot of people, but when we started this NHC we were 10 teams, today we are 20, we started the journey. So every team leader came and really talked about their people and their hobbies and that's really cool. Today we are no longer able to do that, so unfortunately we have somewhat reduced this personal aspect or minimized it. So group leaders, and any session that is architectural that gives, dominates the entire system and all the groups, and not just the region, and the VP Product came to tell a little about her side and how she sees the relationship with the product. There is a session that is an external function that I told you about, the CS and the support and documentation come, so really some kind of taste of our entire ecosystem. And how we work and also create some kind of community. You see these people after this, where they are each other's friends, nearly every time. A program of between 8 and ten people, they really become friends later and know people from other teams. And they know how to contact them, and it's not just another person with a picture on Slack.

Yishai: So people remember the cohort they came with? And like it's my guys, from my cycle?

Nofar: Totally, “class of…”. So yes, it creates something very, very good and also really gives them the knowledge of how to take part in the R&D, and not just the technical knowledge, which is part of when you do onboarding, it is not something that is easy to learn on your own. You need to be spoon fed it usually...

Yishai: And on the side of this topic that is related to the technical and the delivery, of following up on boarding, our efficiency in ramp up time - it is under your responsibility to help managers and group leaders know that we have an effective onboarding process that we manage to get people to function effectively in the team, Do reviews for others, participate in all the processes?

Nofar: So it's not currently under my umbrella. I say right now - because it's the responsibility of the team managers, obviously, but it's always the area where they will come to consult me ​​if necessary. That is, I am not always…it’s not something that is not under my responsibility. This means that you can come to consult and get help. And by the way, a lot of my everyday life. People who make appointments and ask to consult about some new process they are trying to do.

Yishai: But it's not a process that you measure directly and are measured on, okay.

I want to talk to you a little bit about a buzzword that is gaining popularity and is very connected to the position we are talking about. The issue of developer experience with an emphasis on internal developer experience. That is, not the developers who work with, say, Cloudinary's API, but the developers who work in Cloudinary, and what is their experience on a daily basis? Where does it connect with you? How do you see it within the role? Both yours and the community.

Nofar: So I think that I wouldn't say "the essence of the role", but it is something that is very, very important in the role because in the end I come to optimize the engineering. If we say it in one word. And that is to help the teams work better, so that means making room for them to work and making processes that will support them, and creating processes that will save them time later on, as well as working on the right things and giving them the right tools. What I said, for example, with Jira, is something that I really connect with the developer experience. I mean, it really frees up their time. It creates order for them, for their tasks, and what they need to do, and also brings the team together around an orderly process, but on the other hand it also frees up their time.

Yishai: Your developers really love Jira, don't they?

Nofar: They are sick of Jira, no doubt…

ֿ But again the place, the area of ​​clearing the obstacles, the challenges and helping them solve them. To me, it's part of the developer experience and also helping them understand where they are in the big picture. I mean, although it's not something they will necessarily see as developer experience, but once they see the big picture and they understand where they belong, in my opinion, it greatly improves their work and helps them to be better and more accurate.

Yishai: You are talking about understanding the business context and understanding the WHY. Why are we developing this feature? Where does it help the company and customers?

Nofar: So yes, so really helping them to be better at what they are doing, not with the help of technical things but talking about the peripheral aspects, the surrounding ecosystem.

Yishai: If you have to put your finger on I don't know what it is, the one or two that you think are the most annoying or the most disturbing to the developers, obstacles that you see, that repeat themselves. What is the number one?

Nofar: So I think that many times planning is something that is difficult for developers to do a lot, and little by little they realize that in a large organization that without it they don't work on things that are meaningful. So those who learn to understand it - then they don't see it as an obstacle. Those who see it as a challenge that needs to be helped and solved, so I think that planning and tools - tools are always an issue. Also tools like Jira, Confluence and such, but I, too, feel like using this little plugin or this work environment, and that we are big enough to have to say no. So it starts to become an issue. We don't say no to say no. Obviously we say no because there is some kind of set of tools and there is already a matter of security and we are big enough not to pay for 1000 small tools but rather for something uniform. I think these are two areas.

Yishai: So the developers have found some tool or want to shorten some process for themselves with the help of a tool, and then they may encounter an obstacle or the need for uniformity.

Nofar: Yes

Yishai: I see. And you see some kind of pattern in general, the types of tools people are looking for. What do they come to solve with tools?

Nofar: I don't think there is any pattern because it varies a lot from team to team and what the team does, but it's always...

Yishai: Is it a matter of productivity? Productivity tool?

Nofar: No, it's more in the technical area of ​​I need something that will close the loop for me on the specific code now that I'm doing something that will solve it.

Yishai: Oh really libraries for the code base

Nofar: Yes, no not libraries, but. All kinds, I don't have any specific example.

Yishai: Okay. My last question will be about Cloudinary's special story in the famous bootstrap story. This is an unusual company that managed to grow quickly. At least in the first years, without external funding. Where did you encounter in your role, in the evolution of your role? Where do you see it affecting you or how you behave today?

Nofar: So first of all we didn't raise capital even at a late stage. Cloudinary is a truly amazing company. There is an extraordinary culture in the levels of transparency as well, but also in the levels of mutual help and appreciation, and we are very close-knit, and communicate well with each other. And that's also what fascinated me about the process. I mean, when I interviewed for Cloudinary, I interviewed for other places at the same time, and it's probably also the position, but this is the company that did it the most for me. I mean, they really see that this is something that is ours and that we built it and that no external help was needed and that it is really some very strong need in the market and we know how to fulfill it. It meets me mainly in the culture, in the everyday culture to say it is a role, as I said it is very necessary to sway people. And to influence people, I think the culture of Cloudinary which is... I don't know if it came from bootstrapping, but it was created from this story of this being something that is ours. It really helps me to motivate the people because there is really an openness to changes and there is some kind of transparency that we all know, at least, and for me it was very, very helpful in my job.

Yishai: And you felt, I mean, this culture was already evident during your interview stages?

Nofar: Yes completely completely.

Yishai: Nofar, thank you very much for being with us, it was great.

Nofar: Thank you very much Yishai.

Yishai: Go to devinterrupted.com to subscribe. You can also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of positions in all fields. Come to https://linearb.io/careers to find your next challenge.

I am Yishai Beeri, until the next episode

Visit https://devinterrupted.com to register - you can also find all our episodes in English there. I remind you that we are rapidly growing at LinearB, recruiting for a variety of positions. Come find your next challenge at https://linearb.io/careers.
I am Yishai Beeri. We'll meet in the next episode.

(Closing music)

Links to the awesome resources mentioned in the episode:

• SheCodes;
• Women in Project Management