Transcript: David Ben-Basat | Fireblocks | How Do You Build Winning Teams?

Eyal David: [00:01] Hi friends, it's Eyal. You've reached Product Builder, where you can listen to the most interesting product conversations. My journey began in 2012, when I learned what product is at my own startup. Since then I've worked in the industry, and since 2017 my company has been advising a wide range of companies. My drive is to help all of us get better as product people. And before we start, if you enjoy listening to Product Builder, please rate us five stars on Spotify. It gives me great feedback that the podcast is giving you value, and it would make me very happy. So yalla, let's start. Hi David, how's it going? How are you? So great that you came. My pleasure. So right after Rosh Hashanah we have David Ben-Basat from Fireblocks, VP Platform Engineering. Tell us a little, a little about yourself, who we're talking to.

From QA to development: a holistic view and owning code in production

David Ben-Basat: [00:50] Honestly, I've been in the industry for a long time. I started out in 2002. I started as a QA guy, and then came the 2002 crisis, for those who remember, when every job in high-tech was a blessing. And in hindsight, I'm glad I started that way, because a QA person's view is supposed to be holistic, and that's how I saw the product and the ecosystem I was working in at the time. On one hand, on the other hand, when I moved into development, which was the next stage, something like a little less than a year later, I very quickly became responsible for what we called support, or second level, which, continuing that holistic view of the whole product and everything we do, also brought me very close to the customers, to what they feel, what they experience, to whether the code or what we, our deliverables, were easy to debug, easy to find the problems in and give better support. And really, in those first years, I think that's essentially what shaped me later on, and to this day I strongly, strongly advocate a holistic view. That's also how I grow the next generations, and it makes you a tougher programmer, if you like, because you're no longer looking only at the code you deliver, but at how it will be consumed and how you'll know how to deal with it the day after. It also creates a lot, a lot of accountability, but today I'm very, again, that's another topic that's critical to success: ownership and accountability of development, of developers, over their deliverables. The moment something goes to production, that's actually where the work begins. Okay, that's what's sometimes missed: I wrote something, it's in production, I can move on to the next thing. I can move on to the next thing, but my responsibility for that deliverable that went to production has only just begun, in terms of monitors, in terms of whether it's doing its job, and whether, and this is maybe the next thing I came to understand later, whether it makes the difference, or whether it moves the needle, or in slightly more professional words, whether it advances the KPI, the Key Performance Indicator, that we as an organization wanted to advance.

Eyal David: [03:20] Look at that, one second, I'm listening to you and I'm really enjoying it. We're actually talking with an R&D, or Engineering, hat on, you, right? And you're actually talking to me in product terms. Right. In business terms. Right. The closeness of R&D to product,

Product and R&D as one entity

David Ben-Basat: [03:38] I'd say it needs to be very, very high, very tight, but maybe the more accurate phrasing is that there really are no boundaries. I believe product and R&D are really one entity. I remember, again, in the first years of my career, it was like, okay, product defines what needs to be done and R&D executes. And when it succeeds, kudos to the product manager, or maybe to R&D too; when it's less successful, the product manager is to blame, he didn't define it right, okay? That's fundamentally wrong. We're all in the same boat, we all need to think about things together, there needs to be a deep understanding of the business. It's true that in the end someone is more responsible for the domain they own, absolutely, and there's also specialization you build over the years, over time, but things need to be shared, and everyone needs to share in the success or carry the responsibility and improve. That's a much, much healthier approach and ultimately it leads to success. Like, it's also, we all have a shared goal,

Eyal David: [04:48] And also, when you eventually leave some workplace, you want to walk away with some success you brought, that you worked on. Is that something, say, you ask candidates who come to you now,

The one interview question: what impact did you create?

David Ben-Basat: [04:57] what did you move and so on? Actually, I tend to ask candidates who come in just one question, okay? I start from one question and then we develop it in discussion. The question is: ultimately, at the place you worked, at the places you worked, what impact did you create? That's the interesting question, because ultimately that's what interests the workplace. The workplace is a business, it wants to advance its business, and to advance its business it needs to employ people who will advance it. That's what we look for: to move the needle in the organization, to create positive impact on those KPIs the organization wants to move. I have to say that not every candidate understands exactly what I want from them at first, and then we go into more detail and I explain more about the goal and what's behind it. But in the end, that's what interests organizations. An attractive developer or engineer is one who knows how to create impact where they are, to understand what the required KPIs are, okay? What, where the organization is aiming. It could be a velocity KPI, it could be an availability KPI, it could be some product KPI or another. And then to actually implement things behind it that move it forward, and measure them of course. Measurement is a critical element: start with measurement, create some baseline, deliver something, and meanwhile measure it all the time and see that it really changes things, that it moves the needle in a positive direction for that KPI,

Eyal David: [06:30] In the end that's what matters to organizations. Is there, for example, some answer you remember that was really good? For instance...

David Ben-Basat: [06:38] Um... I remember that developers tend to talk about the... to focus on their technical abilities, and the whole business side, the impact on the organization, on the business, is simply not there. Um... and we're talking about very, very smart people, with a lot, a lot of experience, with a lot, a lot of technical ability, but in the end without that there's no impact, and if there's no impact it doesn't advance the organization, okay? So that's what organizations are looking for, and that's also how I build the developers I lead, or that I have influence on, in... in... no... I lead them toward that orientation. Okay? That's the orientation we expect developers to have.

Eyal David: [07:23] So look at that... well, anyone coming to interview with David, you've already got a tip. Uh... a great tip. So let's run quickly through your career. We talked about Dell, and you worked at Quest, and Fanbox, and that's also how we got to talk in the elevator. Yes. And now you've been at Fireblocks for almost two years. Right.

What Fireblocks does and its scale challenges

David Ben-Basat: [07:44] Tell us a bit about Fireblocks in a few words. So the idea behind Fireblocks connects the worlds of security with the worlds of blockchain. Fireblocks' founders understood that the blockchain worlds are more sensitive, and they came up with a solution, uh... that enables, uh... security, end-to-end security, uh... for customers. For larger customers, really. Right. It's true for all customers, but it's certainly much more critical for larger customers, for enterprise customers. Uh... for example, one of Fireblocks' customers is Bank of New York. Uh... basically customers who manage, uh... uh... digital assets, uh... whether that's, uh... storing digital assets or transferring digital assets, and that whole area has to be very, very secure. There are customers, uh... who do it... for themselves, there are customers who essentially manage it for their own users, uh... and there's obviously, uh... a matter of reputation and of the businesses, the business they run, and the... security is critical in that context. Maybe we can give a small example here, just, if I'm now, uh...

Eyal David: [09:02] an organization of the size you mentioned, and I now have, I don't know, I have, uh... I have, I don't know, a billion dollars in crypto, I can't have one person in the organization hold the key to that thing, right, I need a much better solution for it. Right.

David Ben-Basat: [09:17] So Fireblocks provides that solution through MPC technology, Multi-Party Computation. We won't go into the technique behind it, but in the end it lets those organizations sleep soundly at night, knowing they're in safe hands. And in fact, today Fireblocks has over 2,000 customers, including large enterprise customers, as we mentioned, and more than six trillion dollars have moved through Fireblocks so far, so I think the numbers speak for themselves, a truly leading company in the field. And today we're already talking about, we're aiming at much more significant scale, both in terms of availability and in terms of throughput. We're talking about, there are very advanced blockchains today that aim to reach as far as numbers like, say, Visa's, in terms of transactions per second. So the numbers are very challenging, definitely feasible, but again, it requires a lot of focus,

Eyal David: [10:29] And we're on our way there. So tell us, there are probably also challenges with such a high growth rate, you can feel them inside the company, inside the organization, and that's actually what you came to talk about: how to build a scalable organization or a scalable group. But one second before that, just tell us, what does your day-to-day look like? Great question, because the day-to-day really reflects your paradigm, right? Your credo.

A VP Engineering's day-to-day

David Ben-Basat: [10:58] So if you peek into my calendar, you can see it's made up first of all of one-on-ones, whether those are one-on-ones with my direct reports, the people who report to me directly; I have skip-levels I do all the time, okay? With employees across the organization, peers, lots and lots of one-on-ones with peers and others, various stakeholders. That's an essential part of my calendar. There are of course the technical discussions, all over, on different topics. It's important to me to be involved in them, to connect things to the business, as we said earlier, to see that things make sense, to give my two cents where needed. And a lot of listening and learning, okay? Status meetings, I believe in them very, very much. In general, the whole matter of sticking to deadlines is something I strongly advocate. There's, and it creates lots and lots of accountability. When an employee comes, when employees come and essentially define for themselves, okay? What their expectation is for the coming week, say, or for the sprint, right? The next two weeks. They define it and they explain whether they met it or not, and why. And in most cases, the delays, if they happen, are completely objective. But it's important that we understand what's behind them, so we can improve as an organization, okay? Versus just explaining where I stand and what I did, with no commitment, okay? That's less effective. And there are also all kinds of events we like to do, less frequently. It's very important to me to keep up that kind of team building. For example, we recently had an offsite for all the leaders in my group. A leader means someone people want to follow, okay? Not necessarily a people manager. There's a chief architect, he's a leader, he leads the architecture in the organization. A data architect is the leader of the data worlds in the organization. And team leads, other managers, they both lead a domain and are also people managers. The human capital is entrusted to them. So it's important for us to meet to discuss and talk about topics more related to leadership, because to me that's the foundation of everything. I very, very much believe in leadership. And that's essentially what helps us create the impact we talked about. Yes, totally, you know,

Eyal David: [13:46] I'm listening to you and it takes me back a bit to the conversation we had earlier. You're basically a coach, that's what you do. And a big part of the time you set goals, right? You help set goals, and basically, what does it look like? So you joined an organization that was probably growing very, very fast, that didn't really work with defined goals and defined short-term goals, because that's what I heard you say. And you started instilling that. Now you also say, I do lots of meetings with peers, with stakeholders, with whoever, so you're also bringing that approach in there. What does it look like? Like, with your employees versus the people who aren't under your supervision, what does it actually look like? First of all,

Choosing a team lead: a passion for growing people and a trial period

David Ben-Basat: [14:26] I try very, very hard to influence across the board. I really put the good of the organization before everything and look at everything holistically. Because only when everything works does it succeed, okay? Any niche topic on its own doesn't really help. On the other hand, I very much believe in creating effectiveness in the organization through building teams. You create one team that works right, and then you create another one like it, or grow another one like it, more accurately, and so on and so on, and then it spreads through the organization. That's scalability. Exactly, that's the scalability we're talking about. It's essentially human scale, team scale. And there's a whole doctrine behind creating an effective team. It starts first of all with the team lead, okay? How do you actually choose a team lead? Many times we tend to grab the best programmer on the team and tell him, you won, you've been promoted to team lead. So first of all I don't believe in that word, because going from IC, from individual contributor, to manager is not a promotion, it's a different role, okay? That's important. Because there's promotion in all kinds of aspects. As an IC I can advance my whole life, and that's excellent. Okay? But it's actually a different responsibility. The responsibility shifts from responsibility for work, which as an IC I have directly, to responsibility for people who are themselves responsible for the work. It's important to understand that not many people understand this transition, not many are capable of making it, and not many even want it, okay? But people don't always know that. So we need to sharpen it and explain it. So when an employee comes, there's always some team lead who comes and tells me, someone on my team, X on my team, wants to be a team lead. So the first question is why? Why are you interested? Why do you want to be a team lead? And that question has only one answer. You can phrase it in all kinds of ways, but the answer is: because I have a passion, I have a need to grow people. That's the answer. Okay? You can say it again in lots of variations, but that's what's behind it. Answers like because I want to create bigger impact in the organization, because I want to have more influence, because I want to make decisions. Excellent. All those answers are excellent, but you can reach them as an IC too, you don't need to manage people for that. In fact it's even wrong to manage people. If I don't have the passion, it's not right for me or for the organization that I be a manager in the organization. And once there is the passion, that's the first thing. The second thing is to start the process as an experiment. That's very, very important. What, so you run a pilot? What does it look like? You run a pilot. Just like you do a POC on technical topics, here too you define some period of time, say three months, some kind of evaluation, an assessment period. Which is mutual. Right. You as the manager support the employee, define for them exactly what the goals are, are there for them. At the end of the three months it's okay to fail, because it's an experiment. Okay? If it were a technical experiment and it didn't succeed, fine, you move to another POC, you test another technology; same here. And then it doesn't create that same feeling of failure, of "I started as a manager and didn't succeed," and it also builds confidence and trust on both sides. And when it works, great, we move forward, and we already have that designated team lead and we start the journey. How does it work? One second, I'll take you there. So basically there are all kinds of petri dishes where you can actually run this experiment.

Eyal David: [18:15] That designated team lead isn't necessarily a fit for every team, so you actually add them now to a team that fits them, a team that has a gap. What does that look like?

David Ben-Basat: [18:25] So that's an excellent question. In general, all these topics, what's behind them is really the question of fit. That's true in hiring too, obviously, in exactly the same way. There are certainly qualities that are critical for a team lead in general, but there's also fit to the team, and that's where the weight of that potential team's manager comes into the picture, and the building is done together with that employee. Okay? We steer employees to the right team, the one we together believe will be, where there can be a win-win. It always has to be a win-win, okay? A win for the employee, a win for the organization, okay? That's the point, and we'll do everything to create that fit. There's also a matter of timing; it may not be relevant right now, but it will be relevant in three months. Once I've built trust with the employee, which we'll talk about in a moment, and I know what their aspirations are, okay? The employees'. We're in close contact, so we'll know how to find the right timing, it will be top of mind for us, we'll know how to find the right timing to take the employee to that place, to the new role. Again, it's not a promotion, it's a different role. It's a promotion in the sense that, maybe from the employees' point of view, their career, it's their next step, they believe in it, so for them it's an excellent promotion. But they need to understand the whole doctrine behind it, they need to get the support, the guidance, to carry out the process correctly, as we said. And again, once that employee becomes a team lead, it doesn't end there, that's where it only begins, and we keep working together.

Eyal David: [20:09] Gorgeous. So one second before we continue, I'm hearing something else here that's probably interesting for listeners. Basically what you're saying is, first of all, if I want, if I now have an aspiration to be a team lead, or to be anything really, then first of all say it to the organization, don't keep it to yourself, because there will probably be either the opportunity, or there will be that champion who hears it. I have to say this: there's a line I used to say when I was a young manager. I'd always tell employees at the end of every meeting or every pitch of one kind or another, always remember that my door is open. And one day I read an article that talked about exactly that point, and said it's not necessarily a good enough line, because some employees don't have the courage to walk through the door. And then I said, okay, so I'll make sure to always approach the employees. That's what you described earlier, all the time. Right, all the time, building trust with them. So let me bring you back to where we were. We talked about the team lead; maybe let's talk for a second about team structure?

Team structure: seniority first, juniors in measured doses

David Ben-Basat: [21:13] Yes, so team structure also needs to match the nature of the organization and the timing the organization is in very, very closely. I can say that an organization in growth must have a high level of seniority in its teams. When I say seniority, people tend to think of the technological aspects, which is true, but I'm talking about the whole package, I'm also talking about soft skills. Employees who know how to communicate, employees who know how to ask the questions, employees who are proactive, employees who know how to take things end-to-end and make them happen, and who are KPI-oriented, whose goal is to create impact. Once teams are built over time from employees of the character I just described, alongside direct technological experience of course, people who've done a thing or two in their lives and know how to move things forward properly, both professionally and in the softer skills, the company reaches a point where, now that the teams are stable, it can hire younger employees. It's also important to hire younger employees at a certain point, because, as they say, you say, I want to start building the future generation. But even then it's important to hire them in the right dose, okay? Many startups say, okay, it's time to double ourselves. Okay? That, by the way, is one of the lines that today signal... they come back to bite them, yes. Yes. That's not a healthy approach. The healthy approach, after you have, say, three team members and the team is stable, is to hire the fourth.

Eyal David: [22:51] And not to hire another three. That's how you build a machine. Exactly. And today you, you're hinting, are you actually hiring more junior people? Not yet today.

David Ben-Basat: [23:00] We're still in the phase of continuing to raise the seniority level. Also because today we're required to hit very challenging numbers in everything related to availability, throughput, latency. Which is one of the challenges you mentioned earlier. Right, and here you need people who've done it, or at least done similar things.

Eyal David: [23:21] Okay? But again, alongside soft skills. Without that it's not worth it. Okay, fine. So I have a team that knows how to work like a machine, I have a team lead who has led it. What does it look like day-to-day? Are there routines? So that's it, so basically we

A measurable strategy for every squad instead of a shopping list

David Ben-Basat: [23:39] in the different teams, okay? Work with the product people. The first aim is to build a strategy for the team. That's the key. Often both product people and engineering people tend to define some tactical list, a shopping list. No, they're for the tech. Exactly, not only, but a list of things they believe need to be done, and then explain why it helps the organization. But really, the orientation should be the opposite. For each area, domain, okay? Let's say squad, there needs to be some strategy that's aligned with the organizational KPI. And it has to be measurable, okay? If it's not measurable, we'll never know if we improved it; it must be measurable. There are definitely topics like velocity that are harder to measure, you need to find the way, and there are topics that are easier to measure, like availability, okay? Or some telemetry that lets you know whether the feature I shipped is really moving the needle on the business side. Things that are measurable. You have to measure it. And then build a roadmap or a tactical list of items derived from that. Okay? That's the way. And again, once you deliver something, really measure whether it had an effect; if you can do it during development, great, if not, then after the fact. Sometimes it even takes a bit of time until it catches on in the market, depending on exactly what we did. But you still have to do that loop of releasing, measuring, drawing lessons and improving all the time. So that's essentially the routine; it needs to be KPI-oriented, be very, very strict about that. And also, you know, also from a place of pushing something all the way to moving the needle, okay? For example, just an example, we're building, we have some capability for setting up a development environment for developers, which has proven very efficient in terms of its maintainability, and we want, as an organization, most developers to use it. So we saw there's a set of features missing there, and if we complete them, we believe most developers will really use it. The measure of success for the team developing it isn't whether every feature has a check mark, but R&D's usage of that environment.

Eyal David: [26:15] Okay? Tell me, and how much do you really, so I'm reading between the lines, but how much do you encourage team members to be active and take, in this case they're probably also a persona, right? It's very easy to connect it, but how much do you encourage this, for instance?

David Ben-Basat: [26:29] We talk about it all the time, we guide people around it all the time. Look, on one hand it's explaining, okay? Education, there's a lot of education here, but in the end it also connects to their performance. They probably have a very strong desire, like anyone working in some organization, to make the organization better. So that's it, when you also understand the point I talked about earlier, that you essentially become attractive in the industry, okay? I never tie it to the organization we're in, because it really belongs to the employee. We create the incentive in employees once they understand that it makes them attractive in the industry. They say, okay, so if I really create impact, tomorrow another organization will want me too, and another and another, I need to be attractive. So you always need to find the line between the employee's personal growth,

Eyal David: [27:25] that balance, and the organization's success, the win-win, and that also connects to personal growth. Yes, we talked about you being a coach, so okay, come on, tell us for a second how you actually help, now an employee comes to you,

David Ben-Basat: [27:38] how do you actually help them figure out how to take their career forward? So first of all it's important to understand that caring for an employee's personal growth, or their trajectory, is not a project. It's not a one-off thing you do, I'm done, that's it, I've checked the box, I move on to the next employee. No. It's a routine, okay? Now, we said it starts with building trust, because employees need to believe that you, as their team lead, as their manager, truly want what's good for them personally. Once trust is built, they're with you. The next thing is to align on some area that both of you, both sides, believe is that employee's big rock. What does that mean? It means that, we all have strengths and weaknesses, but there's probably some weakness where improvement will create the biggest impact, okay?

Eyal David: [28:31] We need to choose it together and then start working on it. And usually they come, they come baked enough for that. Not always, not always. Do you do some, is there some process where you identify strengths, how does it work? So it's basically, we're already drifting, but that's actually the essence of the one-on-one.

One-on-ones, the big rock and leaving the comfort zone

David Ben-Basat: [28:48] It's actually the foundation for building trust and for the employee's personal growth, and for that win-win we're talking about, which is also for the good of the organization. That's the foundation, that one-on-one. That's where we build everything, so that one-on-one is critical. It starts with building trust, it continues with explaining and guiding, and pretty quickly we, at some point we reach some agreement on an area we want to improve. There are also those performance reviews companies usually do every six months or a year; for me that's just a formalization of those one-on-ones. There's nothing beyond that, because everything has already been said and discussed. Another nice thing about the one-on-one: after we identify that weakness, agree on it and start working on it, the weekly one-on-ones talk about that weakness in a weekly context. It has to be connected to context. Like stop, fix? Stop, look, fix? No, it means, it means, it means: take the work we did, say, in the last week or two, and let's connect it to your personal improvement. That's the point, exactly. And not something out of the blue, something very connected. Feedback that comes in context is real feedback, it's different feedback, it's feedback that actually manages to change things. Because then the employee understands what you're talking about, and also knows what to do with it, because you're talking to him or her in context, and that's the big difference. Just out of curiosity, how do you manage this whole thing? Do you have a separate Google Doc for each employee? Yes. We have, we try to keep it up, but broadly in the one-on-ones with each employee I have some kind of document, which also helps to look at what happened last week or two weeks ago, and by the way it's give and receive, right? So I get feedback from employees, and I also need to do something with it. And that's part of my role in building trust; beyond being good for the organization, it's also building trust with the employee. So I usually take things and act on them, and I also expect the same from that employee accordingly. And again, we're talking about something like, say, once every six months, defining some area we want to improve, and it's there, it's on the agenda all the time, and it's brought up in the context of that week, okay? Say, for example, working with peers. Some employees struggle with working with peers, but in their day-to-day it's a must, and every week there's at least one topic that requires working with peers, and then I talk with that employee in that context, and say, okay, so how did you run the conversation this week with X, and how do we improve it in the next conversation next week? We really go down to that resolution, and if the employee is, as they say, with us, with me, we're aligned, and he understands that it contributes to him on the most personal level in the world, great, there's a huge gain here, and guess who else gains from it? The organization, or the people around, right? That's what I'm talking about.

Eyal David: [31:55] Gorgeous, so let me sum it up for a moment. What you're doing is really a coaching approach. You're saying, we do weekly retros focused on the employee, we define the goal beforehand, and all kinds of examples that we're on the right track, and you're also constantly taking him out of his comfort zone, or her, right, in order to grow, yes, but all of that happens because at the start you defined something that she or he probably really wants to work on, and that's why they're willing to leave their comfort zone. True, and you said it exactly,

David Ben-Basat: [32:23] and I really connect with your saying about leaving the comfort zone, getting out of the comfort zone, every relatively short period of time. And I say it from personal experience, because I made a lot of mistakes in these contexts and learned from them: you have to leave the comfort zone. When you're in the comfort zone, by definition, you're not developing. You can do good work, but you're not developing. When you leave the comfort zone, that's where you start to grow. So for example, we recently made a change in the DevOps group, which had matured enough for that change. What's behind it, and by the way it's based on feedback that came from the field, what's behind it is essentially taking the DevOps engineers out of their current comfort zone into a new world. And there are concerns, excellent; if there were no concerns, it would mean we're not really creating change here. Change brings concerns with it, change also takes you out of your comfort zone. Of course we believe in the change, and everything has pluses and minuses, so we'll know how to deal with those minuses and manage them so that we really get the best out of it. But there's amazing personal growth here for those employees. A manager constantly needs to challenge their employees by taking them out of the comfort zone, and everything we're talking about, notice, is routine, and it's personal growth. Really, and actually also what you're saying,

Eyal David: [33:50] to make this machine very scalable, I also need to instill this whole thing in the employees under me, who will actually take it on downward. It can be cascaded to the whole organization. Gorgeous. And you feel it's actually spilling over to other departments too, that's what I understand. It's spilling over all the time, but it takes work.

David Ben-Basat: [34:09] It doesn't spill over by default, because there are barriers that need to be untangled, where, again, there isn't enough maturity. People who are young team leads, amazing. With huge potential, but in the end it takes time. And these things, these topics, I won't say always, but in the vast majority you learn them on your feet. There are no shortcuts, and with lots and lots of mistakes, and you need to let people make mistakes and learn from them. And we give the guidance and the direction, and also, again, we tie it to each employee's personal performance, so we encourage it faster and in a very focused way. But it takes a bit of time, it also takes patience, and yes, it seeps in. It seeps in, and in places where it seeps in less, we help it seep in. Help it seep in. I'll tell you about my team,

Eyal David: [35:02] that I work with in a very similar way, and one of the things that keeps people from leaving the comfort zone is the fear of failure, and then the moment has to come where you help measure the risk and also find remedies for it. How do you deal with that? That's an excellent question.

David Ben-Basat: [35:20] It depends, it very, very much depends on that failure, what its magnitude is. That's where we are as managers: we do need to let people make those mistakes whose damage probably isn't big, but which have a very, very big impact or contribution to their personal growth. And as long as there's no, you know, nobody's taking down production here, for instance. So we're constantly in that positive tension.

Eyal David: [35:49] So it really requires a daily view, as we say, but that's the goal. Totally. I also try to do that risk management together with the other side. Basically to flip the concerns a bit: okay, the best that can happen is that it'll be a success. What won't? Let's list them, and then we actually start managing those risks. I assume you do that too.

David Ben-Basat: [36:11] And that actually lets you get going much faster, at least in my experience. Right, for a company to be truly resilient, it needs mechanisms and processes. And we're constantly instilling more and more of them. Also at the... you know, we talked about production, so everything related to production monitoring: we have an SRE team that just keeps getting better, and there are elements of education here, what's called the shift-left of SRE toward R&D, toward the developers, all the time. So everything related to monitoring these things, we keep improving the processes inside the organization, in terms of ways of working, work within R&D teams, work with product. We keep raising the bar, okay? That's very, very important. When an employee reaches a certain bar, the first thing to do is simply raise the bar. We monitor these topics in the various status meetings I mentioned, of one kind or another, like a mini oversight meeting. We want to see that things are progressing, but also connecting holistically, okay? When an organization is big, we didn't talk about this, silos can easily form, which sometimes has an advantage, because it also kind of, you know, advances the velocity of each area nicely. At the same time, you need to make sure everyone in the end is aligned with the KPIs of the whole organization, and that things connect together in all kinds of aspects: the organizational aspect, the product aspect,

Eyal David: [37:44] the architectural aspect. Right, that's probably risk management that worked well after you came back with the conclusions. I want, one second, you've really been through a lot of organizations, I'd like to ask, a question we usually ask here: what, in your eyes, are the most important product skills in a product manager?

The most important product manager skills

David Ben-Basat: [38:03] So okay, first of all we talked about product and R&D really sitting together, being engaged and working together, even physically sitting together, you know, in the same room.

Eyal David: [38:15] That's the first topic. I think what you mean here is basically the way of working and the communication,

David Ben-Basat: [38:22] and really that feeling of pushing this cart together. But also at the level of accountability, okay? The success is all of our success. That's what I said, pushing this cart together, really. Exactly, exactly. Visibility, okay? There needs to be very, very high-quality visibility, from the product side too; product also demands it of the team it works with. I call it continuous visibility: all the time, communicating all the time, because, you know, there are things where I don't know how to estimate the timelines, I'll give a rough estimate now, and over time I'll keep updating it. That's fair, it's simply fair. Exactly. Strategic thinking, as we discussed: the idea is to start by building a strategy, okay? And not from a tactical list, a shopping list, but from building a strategy that's truly aligned with the organization's goals. The second you have that, from there it's easy. From there you can derive the features or capabilities that will move it forward. Each time we'll take another bite of that strategy. We'll eventually get, even if it takes a long time, to the farther place. And also, you know, there's the matter of short term versus long term. We always used to say, okay, let's give some short-term solution now and do the long term later, with no connection between the short term and the long term, right? And of course in the end we're left with the short term. So that's thinking that's a bit archaic today. The more effective approach says you need to think only long term, but deliver value incrementally. Meaning, each time another chunk and another chunk that delivers value, even business value, right? And still advances that long-term vision, even if it never gets to 100%, it'll get to significant percentages, and each time we'll advance it a bit more. That's a much healthier, much more correct approach. Because we didn't define the long term for nothing, there's a reason for it, it touches our strategy, okay? Working with KPIs: product needs to be strict about working with KPIs, needs to champion it, and that way educate the engineering team too. That should be the orientation. Nothing else is interesting. Another thing that's important to me on the product side is also looking at the non-functional requirements. Not just the functional ones; we often miss this, but in the end, if the feature I delivered isn't available enough, or isn't resilient enough, or isn't scalable enough, and in certain situations doesn't behave the way I'd want it to behave, then we missed the goal. Okay? Everything has to come bundled together. You need to look at all the components and make sure the team advances them. In that context I'll also say: be very, very attentive to the team. The team is not a contractor. Remember? We're in the same boat. Teams usually, okay? Have technical debt. There always is, because it's something that naturally forms, and you need to see how we weave that tech debt into the product roadmap. Every employee in the organization needs to create impact. To create impact they need to look holistically. It's not just the feature, it's also all the technical debt that in the end sometimes slows down the team, and then it'll slow them down from developing the next feature, or hurt monitoring or debugging of problems in production, and so on and so on. So pay attention to that too. Planning, planning is the key word. I'm a big believer in planning. We have, for example, a Slack channel for every initiative in the organization, with the whole group working on it, and I always look at the bookmark at the top of the channel to make sure there really is some plan, ideally even at the level of the Jira board, which again, is up to date. Knowing where we're going. Knowing where we're going, everything's planned; there are definitely unforeseen things and you update it on the fly, great, as we said, but there's a plan, you work by a plan. If you don't work by a plan, you won't get anywhere. Exposure to the business, we talked about that too. I'm convinced that the product manager is very exposed to the business, but is their R&D squad exposed? And if not, they need to do something about it, both from the angle of exposing them, and again from the angle of giving the incentives, explaining why it also advances them personally. A product manager, I didn't say this, is a leader, okay? I'm sitting here really dwelling on it, so most of the things you said really paint a leader from all kinds of angles,

Eyal David: [42:52] and it seems that's an important thing, that's a great answer. And tell me, do you have, now, today, work at the interfaces with product managers? Is that basically the conversations you have with other stakeholders?

Infra teams, incidents and 'production is a reflection'

David Ben-Basat: [43:04] Yes, look, today I also lead a product group. By the way, for most of my career I led engineering groups alongside, alongside product groups, and I worked very closely with product managers. Always, always we worked together, really side by side, and gave each other feedback, yes, all the time, and that's how we built it. But I also lead infrastructure groups, where essentially we, the engineers, we're our own product, but that requires a lot, a lot of understanding of what's happening upstream, as they say, not just in terms of listening but also being involved. And that's something I push for very, very much, because the danger with infra groups, which have lots and lots of advantages, is a bit of disconnect from the business, a bit of disconnect from the R&D groups. So it's important that it not come from a place of sitting and giving advice or building some infrastructure whether it's relevant or not, but really feeling the pain. And that means participating more in production incidents, which ideally will be as few as possible, but when there are, it's important that more and more people are there. Apropos production, a line I like to say: production is a reflection. Production is basically a state of, a stress state. As we say, under stress we see the real picture. So when there's an incident, we look at how fast the problem gets solved, which is super important. We also look beyond that, at whether we make sure the problem really won't repeat itself. And there's another view, which I believe in very much, and that's who the people are who jump on that incident and actually handle the problem. And the more and more people do it, the more developers and fewer managers, or people who were at the startup from the moment it was founded, are doing it, that's a very, very good indication of an organization's scalability, of an organization that's actually becoming healthier and really leveraging all of its employees, or most of its employees. That's probably a machine that works. Right, gorgeous. This has been super interesting so far, let's close, let's move toward the closing,

Eyal David: [45:34] the wrap-up of the episode. So I ask this question too: where do you see yourself in ten years, what do you wish for yourself?

David Ben-Basat: [45:41] Really, my passion to grow people, to grow teams, to grow a generation of leaders, as we said, whether they're people managers or responsible for a certain domain, that's my biggest passion. It involves building those people on the most personal level in the world, alongside contributing to the organizations they're in at that stage or in the future. So it's really that win-win I believe in very much, and it's something I'd like to keep doing more and more, to influence more people, more organizations, to create successes; it simply gives me huge satisfaction. Alongside architectural growth, architectural scale, of a system, like what we talked about today. Only I think the bigger challenge, in the end, is really the people. In technology there are lots and lots of challenges, and of course in business there are lots of challenges too, that's another dimension. But over the years I found that the challenge truly above all is the human challenge, and maybe one of the fundamental differences is that when you deal with a human challenge, when you talk with people, you're not only talking to their rational side, as you do with technological aspects, that too, but also to their heart. And that's a skill, a skill you develop over time, and simply when you feel you have it and you're contributing, it's very hard to give it up, and it's something I'd like to keep doing.

Eyal David: [47:32] Gorgeous, David, so let's help you. If there are listeners now who want to reach out to you to, you know, consult about their personal growth, about their organization and so on, how do they reach you, how do they get in touch? You can get in touch with me through LinkedIn.

David Ben-Basat: [47:45] to send me a message, and I'd be happy to set up a short little call. I think, again, I have experience in this that's based on lots and lots of mistakes. I learned from them, and I'd be happy to give advice and guidance to anyone who wants it. Gorgeous, so to filter a bit as well,

Eyal David: [48:08] what's the minimum someone should come with when they reach out to you? What should they be equipped with?

David Ben-Basat: [48:15] They should come equipped with an understanding of the place they're in within the organization, what the organization's goals are, what the organization expects of them. I think that's homework that's important to do in any case. Every employee should strive to understand what's expected of them. Don't wait for any manager to come and define for you what's expected of you. If that happened, great. If not, sit down and define it for yourselves, and do align with your manager, with the system. Make the adjustments you need, and set goals for yourselves, okay? Don't let anyone stop your career success. It's on you. Build it yourselves. If you're getting the feedback, great; if you're not, make sure you get it, because it's your success. Okay? There's also a bit of managing up here, but it's a very, very important topic. Gorgeous. Great ending.

Eyal David: [49:12] So thank you very much, David. My pleasure. And yalla, until next time. Bye for now. Bye bye, thanks. Hey friends, thanks for listening. If you found this podcast valuable, you can subscribe and follow us, of course, for more episodes on Spotify, Apple Podcasts or any other app. And of course if you didn't find us on some app, I'd be glad if you wrote to us. We'd really love five stars on every platform and for you to follow us, so more listeners can discover us and find the podcast. You can also find previous episodes on any app or on the YouTube channel; we have links in the description. Until next time, yalla, be effective, and bye bye.