#38 - The Tech Executive Operating System - Aviv Ben-Yosef

Episode Introduction [00:00:53]

Henry Suryawirawan: [00:00:53] Hello to all of you who are listening. It’s always good to be back here again with another new episode of the Tech Lead Journal podcast. Thanks for tuning in and spending your time with me today listening to this episode. If you haven’t, please subscribe to Tech Lead Journal on your favorite podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, and YouTube. And also please follow Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram. I’m looking forward to connect with you, hearing your comments and feedback there. And if you’d like to make some contribution to the show and support the creation of this podcast, please subscribe as a patron at techleadjournal.dev/patron. I highly appreciate your support and your contribution would help me towards sustainably producing this show every week.

For today’s episode, I am happy to share my conversation with Aviv Ben-Yosef. Aviv is an advisor and consultant for tech executives and leaders to help them create world-class engineering teams ranging from early startups to Fortune 100 companies. In this episode, Aviv shared with me in depth about the Tech Executive Operating System, his latest book for any tech leaders in the industry to maximize their leverage and make great impact in their organization. We covered a lot of things that I certainly believe would help a lot of tech leaders out there, who are currently leading and managing engineering teams, be it as a tech lead, engineering manager, Head of Engineering, and also CIO and CTO. Our conversations include a number of insightful things, such as what the Tech Executive Operating System is, the axioms of tech leadership, how tech executive should focus on producing Tech Capital to drive value instead of obsessing about tech debt, shifting the engineer’s mindset to create impact by adopting Coders Without Borders mentality, moving yourself up to the decision stream in order to increase leverage, the importance of product mastery, and how to approach and tackle organizational debt. Towards the end, Aviv also explained why we should not forget to put more emphasis on product-oriented engineers instead of principal engineers who focus solely on just the tech.

I personally benefited a lot from Aviv’s sharing, especially since I recently started my new role in the engineering management. And I hope that many of you could also benefit from this episode. If you like it, consider helping the show by leaving it a rating, review, or comment on your podcast app or social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners. And hopefully they can also benefit from the contents in this podcast. So let’s get this episode started right after our sponsor message.

Introduction [00:04:15]

Henry Suryawirawan: [00:04:15] Hey, everyone. Welcome back to another new episode of the Tech Lead Journal. Today I have with me someone from Israel. So he’s an author, advisor, and coach for executives. He’s the author of the book called “The Tech Executive Operating System”. So in this episode, I hope we can talk a lot about that. What is Tech Executive Operating System exactly? And what Aviv is trying to tell Tech executives in order to increase and maximize their leverage in an organization. So Aviv, welcome to the show. Very excited to have you here.

Aviv Ben-Yosef: [00:04:48] All right. Thank you. Very excited to be here.

Career Journey [00:04:50]

Henry Suryawirawan: [00:04:50] So Aviv, in the beginning, maybe you can introduce yourself. Telling us about your career journey, maybe some highlights and turning points.

Aviv Ben-Yosef: [00:04:57] Yeah, sure. So I’m Aviv Ben-Yosef. Based in Israel, like you said. I taught myself coding around when I was nine years old, and ever since I’ve been enamored with code and with creating this magical world where we can just type on our keyboards and stuff happens. I still find it magical. In Israel, you have to do army service. So I served one of the computer units. That was the first time that I actually had to code with other people, which was an amazing experience for me, and I learned so much. And afterwards, I worked at IBM for a bit. I was the first employee at a startup. For the past nine years, I’ve been independent, and that was a big change for me. After being a first employee at a startup, I realized that I want to be master of my own, and decide how I’m going to do things and do whatever interests me.

At the beginning, I was just a super freelancer. I went around a bunch of very good startups here in Israel. And I helped them with product development, coding. Basically, I call myself a very expensive band-aid, because they were engineering teams that weren’t delivering as fast as they should be, and so they had to bring someone like me. And I had a bunch of fun. I helped five or six, seven acquisitions. I’ve worked with several companies that ended up becoming unicorns. So it was really so much fun for me as someone who loves code. But after a while, I realized that I got to the company, I saw the quality become better, some even deliver faster. But when I left, things usually went down to the way it was before. And that was when I realized that my passion has shifted from actually writing the code to helping people create amazing organizations that write code, amazing code without needing someone like me to be brought in. And for the past, I would say three years, I’ve shifted and I’m focusing on helping CTOs, VPs of Engineering, VPs of R&D, to create these world-class engineering teams. So that’s the mission I’ve been on.

Henry Suryawirawan: [00:06:48] I’m sure in terms of transition from being the coder, the doer, implementer to become like a free, independent consultant, and doing freelancing maybe sometimes, and consulting people. I’m sure there’s a bit of transition there. Maybe you can share a little bit for people who are also looking to change their career from being just a doer into someone who is consulting. Maybe any tips or advice?

Aviv Ben-Yosef: [00:07:10] Yeah, I think that it actually boils down to the same things that make you an excellent executive or an excellent even engineer. And we’re going to touch on that, I think, later in our discussion. But you have to adopt the mindset of thinking what would make the client’s condition better, and what’s in the best interest of the client. If you are driven from that, sometimes that means, for example, you’re in a sales meeting with a potential client, and you realize that the thing that’s best for them might not be to work with you. When that happens, you realize that you can do the right thing and tell them, “We shouldn’t be working together.” And maybe connect them to someone else. That’s the kind of mindset that you need. Then that’s when things, actually in my experience, started working when you can allow yourself to do that. And it’s a bit scary, but with the right prep work, I believe that more people can do this than would imagine.

Tech Executive Operating System [00:08:00]

Henry Suryawirawan: [00:08:00] Of course we are going to talk a lot about how you would advise Tech executives. But first of all, maybe tell us a little bit more, what do you mean by Tech Executive Operating System? What is this operating system all about?

Aviv Ben-Yosef: [00:08:12] Yeah. So again, I’ve been working with dozens of people who some are first-timers as executives in charge of engineering organizations, and sometimes, it’s not their first rodeo. And still I saw that I keep repeating the same messages. I keep saying the same principles. When I noticed that, I know that means that it’s something that I need to share even more often. I’ve collected all of those principles under this big umbrella, which are called the Tech Executive Operating System. Because I think that there are a bunch of principles and guidelines that are incumbent for no matter if you’re a tiny startup in your first year, and if you are a unicorn with hundreds of engineers under you. I see the same messages and the same principles helping executives at all of those levels. So that’s what the operating system is intended to help my readers with.

Henry Suryawirawan: [00:09:01] So is it intended for like incumbent Tech leaders, or is it for aspiring new leaders? Maybe tell us more about this operating system.

Aviv Ben-Yosef: [00:09:10] The book is written in a way that approaches people who are currently in a role of an executive. It might be the first week and it might be three years into the role, doesn’t matter. But I’ve been getting feedback from many readers that they find it very helpful for them to decide whether they should become an executive whatever the role is good for them, and to realize what they should be working on for themselves. If they are looking to achieve such a promotion or eventually start their own startup and stuff like that. So I think it’s beneficial to everyone.

Why Does the Company Need You [00:09:40]

Henry Suryawirawan: [00:09:40] So maybe for this episode, let’s take a scenario where there’s a new Tech executive who is joining a new company, whether it’s an enterprise or a startup. Maybe you can help to choose which one in terms of context. So in the beginning of the book, you mentioned about why the Tech executive needs to understand why the company hires him or her. So maybe you can tell us a little bit, what do you mean by understanding this “why”?

Aviv Ben-Yosef: [00:10:04] Well, it might be again, intuitive. Again, if you’re a consultant, someone approaches you, and you might tell them, “You don’t need me”. It’s all stemming from the same point. Someone is hiring you. You’re going to occupy a position. That’s going to be well paid, I’m hoping. You’re going to have a bunch of responsibility. What would be considered a success? So the same, I think that for everyone listening right now, understand that when we are starting a new project, we have some sort of a success metric in mind. How would we know that we’ve achieved success? But the same needs to be applied to your position. How would you know that you’re doing a good job? And that usually means that your boss and your colleagues get what they need out of your position. So you have to understand exactly what would make you shine? Because without that, you won’t have objectives. So it’s like creating your own OKRs with the CEO or your boss to ensure that you’re going to have the biggest impact that you can on the company and the organization.

Henry Suryawirawan: [00:11:00] And you mentioned there are four responsibilities in the book. In short, it’s LEAP, L E A P. Maybe you can share a little bit what do you mean by these four responsibilities?

Aviv Ben-Yosef: [00:11:10] Yeah. Having talked to hundreds of executives and I’m saying Tech executives, because there are a bunch of titles, CTOs, CIOs, whatever. I do see that there are four common responsibilities that people usually take, and you don’t have to have all of them, but usually have at least one. The first is Leadership, of course. Being an executive means that you have to be a leader. Just as this podcast talks about Tech Leadership in general. There are usually three archetypes on the Tech executive. The E stands for Evangelism, which is the outward facing executive. For example, if you’re a company that’s B2D, business to developer, that has a bunch of APIs and SDKs being developed. You might need someone who’s very technical, who is the face of the company. Think of Stripe, for example, or the Apple executives who talk at the WWDC conference. That’s the evangelism part. The A stands for Architecture, which is the person who has the responsibility for architecture and innovation of the engineering team, of the R&D team. That might be the standard CTO in air quotes, where it’s the person who knows a bunch about the deep tech needs of the company, who has labs trying all sorts of experiments. And lastly, of course, there’s P for People, who is in charge of the actual processes, and the people delivering the work. Often titled the VP of Engineering.

Executive Leadership is Long-Term [00:12:30]

Henry Suryawirawan: [00:12:31] So you also mentioned in the book about the axioms of leadership. There are few things that are very interesting for me. The first question that I have is about executive leadership is a long-term thing. For example, in the company, right? When you hire executives, sometimes it’s for solving a short-term thing, or sometimes to gain something for short-term benefits, and sometimes even the compensation, or the remuneration is tied to a short-term gain. So maybe can tell us more, why do you think Tech executives should think in long-term?

Aviv Ben-Yosef: [00:13:01] Yeah. Well, it’s like the same annoying answer you get from coders when you ask them, “How long should it take me to write an app?” And you’re going to hear, “It depends.” Because there are a bunch of things, and we always need to think about balancing the different trade-offs that we have. I believe that executives and pretty much everyone in leadership. But especially if you’re at the executive level. You have to have a very strong discipline to always consider the long-term. Does that mean that you’re not going to look at the short term? Of course (not), there will always be fires to put out. And as you just said, sometimes there are things that have to be handled. For example, quarter goals and stuff like that, that you have to focus on.

But if you’re myopic, if you always look one step ahead, you are doing the team a disservice. Because the team deserves to have someone that’s looking ahead and trying to think how to best utilize them. Otherwise, you’re working like a greedy algorithm that’s not looking far ahead enough. And therefore, you might be achieving some local maximum, but not the real maximum this team should be striving for.

Tech Capital [00:14:00]

Henry Suryawirawan: [00:14:00] So another thing that Tech leaders should do is actually to build what you call Tech Capital. Maybe in the first place, what do you mean by Tech Capital? I’ve heard about technical debt, but Tech capital is something that is new for me.

Aviv Ben-Yosef: [00:14:13] Yeah. So we’ve all heard about tech debt, and that’s my main issue with tech debt. I’m hearing people talk about it all the time and are spending so much time dealing with that. And I always give the example, if you had a friend that’s obsessed about their debt, about maximizing their credit card, about not drinking their cappuccino because they’re trying to save those $2 a day and stuff like that. I would say that there’s a limit to how much you can gain by lowering your debt. But sometimes, you can do things that would end up creating more value to the company as a whole. Things that are not features. Tech Capital isn’t just another feature. Because a feature is like the second you purchase a new car and you start driving it, it starts lowering in value, and you have to maintain it constantly. The same applies for most features.

Tech Capital is about creating something that enables things that weren’t possible before. I can give a bunch of examples. For example, something I’ve seen recently is when at a startup I’m helping, an engineer just happened to be talking to some of the salespeople, and saw that the way they were building the company’s sales pipeline, where the money is going to be brought in. He saw that they were doing it in an ineffective way, kind of guessing. And because this is a company that sells based on geographic location, he did some thinking said, “You know, let me try something.” And he pulled data from the municipality data sources, open data sources you can find online. And he created this map tool that all of a sudden did some data science magic. And I’m talking about two days pretty much for building this. He created this tool that all of a sudden, clustered some information, helped them see how things are changing in the city they were currently targeting. The whole sales organization started being driven by this tool. So that’s Tech Capital because he created something that then enabled something no one else before thought it was possible. And those are the kind of stuff that eventually end up paying long term.

Henry Suryawirawan: [00:16:03] So you mentioned that this is different than features, right? Because in Tech, in engineering, mostly business and technology, they always talk about, “Okay, how many features can we deliver? How fast can it be?” But when we talk about this new capital, how do you actually influence business that actually this is important?

Aviv Ben-Yosef: [00:16:21] I think that, first of all, you do have to ensure that when you have these initiatives, when you’re working on Tech Capital, it has to actually be capital. Some of the time the team should be doing stuff that’s very technical, not tech debt necessarily. Some of it would be tech debt because we can’t really get rid of it. Sometimes they’re going to learn about the new Node JS package or stuff like that. But they also need to be creating stuff that matters for the business. Some more examples of Tech Capital. They can create tools that enable people in marketing to execute on tests faster without having to schedule stuff with engineering. I always see marketing wanting to edit emails, or send another email and do another test, and they see that they have to schedule it through product. So it ends up on the engineering roadmap. Then the cycle times become months. Once someone in engineering creates the CMS like tool that allows them to do stuff on their own, not everything, 80% of the work, that’s like magic for them. Marketing all of a sudden can actually do stuff rapidly.

So if you do Tech Capital, it’s actually genuinely helping the business, enabling other people in your organization. And that’s actually another one of those leadership axioms. I call it " Coders Without Borders". You want to create engineers that help, not just the direct customer of the company, but everyone in the company. So you might be helping customer support. You might be creating tools for sales or marketing and everyone else. And sometimes even tools for engineering because making engineers be able to develop faster is also valuable.

Coders Without Borders [00:17:49]

Henry Suryawirawan: [00:17:50] So I like the term when you mentioned “Coders Without Borders”. From your examples, few things that we can listen already, engineering helping the marketing or the sales team to build some tools that can help them to do more self-service task, or maybe some kind of automation that can help their lives better. But in the first place, normally when we talk about engineering and business and especially coders, right? They don’t talk to humans. Like they don’t like talking to humans. How do you create this environment where the coders without borders actually excel?

Aviv Ben-Yosef: [00:18:20] Well, we have to avoid the creation of silos. We have to avoid people pigeonholing themselves, and as leaders pigeonholing the organization. A part of that is what I call product mastery. There’s a difference between having engineers be just really good engineers technically, just a principal engineer who is great at their craft. And then there are product engineers who are people who understand the actual product that the company is working on. What the customers need? How the business model works? What attracts customers? What the competition is doing, and what you can do differently in order to become better, to gain a competitive edge? And having engineers that actually understand that, and have that wider, broader context of the company, they’re worth their weight in gold when they achieve that. And the question is, how do you help your engineers have that kind of product mastery? If you’re just a small, tiny startup, it usually happens pretty much naturally because anything is so small that people are aware of what’s going on. But as you become larger and especially at enterprises, it gets a lot harder, and you have to do active work.

Just the other day, I was talking to a CTO who told me that his engineers started replacing their Netflix time with watching Gong.io. If you know what it is, it’s a tool that salespeople use for tracking their sales calls and how they’re operating. And it actually records the sales calls. And the engineers started listening to those, you know, like you’re watching Netflix. They did that, not because anyone asked them to, but because they were interested. And they gain such a broad insight of what customers are talking about? What makes the product sell? And what kind of disadvantages customers are asking about? That made them so much better at poking holes in the product roadmap. They see something, and product ask them for something, and you can be a JIRA resolving machine. Product tells you, we need you to do X and you just go and do X, or you can have the awareness so that when product comes up with an idea or with a feature or a new product, you can poke holes and say, “You know, I think that the customers really care about this, right? So maybe we can put away those extra 20% of the feature that’s going to cost us 50% of the work and see if that by itself is worth it.” You can have those conversations as a partner to product, which is a gold mine for the company.

First 100 Days [00:20:43]

Henry Suryawirawan: [00:20:43] I mean, all these things that we have discussed, it seems like if you are new, you won’t be able to do it all in one go, right? Like you’re still adjusting to the environment, to the people inside, to the culture. But maybe tell us a little bit more, what will be a typical, like first few months, or first few days for new tech executive coming to a company, what should they do?

Aviv Ben-Yosef: [00:21:03] Yeah. Right now, I’m helping and advising a few people who are in their first couple of months in their executive role. And I’ve done that so many times so far that I realized that there’s a pattern that seems to be working. And I put that as chapter three of the book, which is called “your first 100 days in the company”. What do you do in the first 100 days? And often, you have to balance, just what you said earlier, you have to balance the short-term with the long-term. So, first of all, you have to do a bunch of juggling. You have all of those plates you’re spinning in the air. All the fires you need to put out, and you have to do that. No matter how good your organization is being run, you’re going to always have some things, emergencies that you have to take care of. But as you’re doing that, you also have to be actively working on building rapport. You have to establish relationships with your staff, of course. But also with all of your peers. With the VP of Product, of course. People like the VP of Sales, the VP of Marketing. Understanding what the CEO wants. Understanding how the product is built, gaining the product mastery. And that’s usually what people do in the first month or so. They build rapport, and they do the juggling. Both of those provide a bunch of input, such as things that need to be taken care of, things that you need to do, things that you need to consider. Those go into what I call triage and clearing the fog of war.

Triage is, as you’ve seen in any medical show on TV, you have to decide very rapidly for everything that comes on your plate. Every emergency that you see, every issue that someone tells you about, you have to think and say, “Is this something that I need to be handling right now? Is this something that I need to be handling for me? Or should I be delegating it to someone else in my team? Is it just something that, I don’t know, maybe I should report to the CEO?” You have to do the triage, and you have to clear the fog of war. If you’ve ever played those strategic games online, you start with a map, and most of it is fogged, and you don’t know everything. You just know your destination, where you need to get to. But you will only clear the fog and start seeing and learning how things look when you actually go there. When you actually talk to the people, when you realize where you need to go in order to get to your final objective. So all of those inputs should be pushing you to ask more questions, to see where you should be digging deeper? Who you should be talking to? And then, after you’ve cleared some of the fog, and after you’ve triaged the most important stuff, you start laying your plan.

Usually around two months, you should start acting on your plans. You should do stuff like create change initiatives. Decide whatever you want, for example, re-org the company, change how your sprints are being managed, how the roadmap is being managed, how the teams operate and talk within themselves. All sorts of stuff and decide if you need to change stuff in the personnel itself. Should you be hiring more people? Should you be, I don’t know, working remotely or trying to move people to a hybrid model? All sorts of stuff like that. And that usually happens around the two months mark, when you should start doing that. And the reason I’m aiming for the two months mark to start is because I believe that as humans, we really like not having things changed too rapidly. We like things being as we’re accustomed to it. There are windows where people are more receptive for change. For example, when someone just starts at your company, you have this window of malleability, when the person is open to new ways of doing stuff. And around two months later, they become accustomed to stuff and they get used to the company. They get used to how things work. And the same applies when you have a new executive. In your first hundred days in the company, people are more receptive for change because they expect that to happen at least somewhat. So you should try and kick things off around two, three months. And then I think that once you kick it off, you should make sure that you know, and everyone else know that it’s not going to be the one true way. Maybe you’re trying a re-org. But it doesn’t mean that you’ve just realized what’s the best way to do stuff. Just like in coding, we iterate and we try and we have experiments. You might have to do the same at the company. And now I’m not saying that we’re going to refactor the organization every couple of weeks, because we want to rename a method. But you still need to have an organization that understands that. You don’t have all the answers, the right answers right away too. You are also learning and adjusting and the company is going to change, and that’s a healthy thing.

Henry Suryawirawan: [00:25:32] And also it relates back to the fog of war. Thinking back my old days, playing this strategy games. Every time a new fog clears out, you always find new things, maybe new adventures, new challenges, new enemies, and whatever. So I think it’s a key message to always keep iterating on that.

Moving Upstream [00:25:48]

Henry Suryawirawan: [00:25:48] So the other thing that you mentioned very important is actually to move upstream. So meaning that the Tech executive needs to be involved more in decision making, or at least knows like where the decisions, for example, are being elaborated, or like few key people in the companies that seem to have the power to make decisions. So why is it important for Tech executives to try to navigate and try to move upstream to the decision-making point?

Aviv Ben-Yosef: [00:26:12] Yeah. If you don’t move upstream, if you don’t make sure that you sit around the table where decisions are being made, what will happen is that the CEO will come up to you one day and say, " “We need to get going on X, and we have two weeks to do that”. And you’re like, “Why didn’t anyone tell me about this like a quarter ago?” And that’s what’s going to happen if you don’t move upstream. So you’re at a higher point and are able to look long term. Again, you know, everything’s connected here. You have to enable yourself to look long term, and that’s what moving upstream is all about. Think about it this way. We all know that when we develop code, it’s a lot easier to fix an issue, to refactor our direction at the architecture step when we’re defining the goal. And it’s a lot harder usually to make a big change later, when you have sent the pull request and someone’s making a comment saying, “Oh, I think we should be using a whole different design.” You’ve already done everything.

The same applies for these big strategic shifts the company is going to go through. If you’re placed higher level, you can see where things are headed, and just knowing is already very good. But if you’re there, and if you’re around the table, and you actually speak up, all of a sudden, you can actually help shift things towards the right direction. Real examples that I’m seeing. You talk with the company and you realize that you are likely going to be spreading to multiple markets. Most of your current clients have been around the same time zone, and you see that you’re going to have people all over the globe. If you knew about it three months before it’s going to happen, before you’re going to have those clients, because it’s on the roadmap. All of a sudden, you can start acting with your team to be prepared for it. Maybe you’re going to hire people around the globe. Maybe you’re going to start changing your culture. So you have more remote people in different time zones, and the team is already accustomed to it. I don’t know, whatever. But if you are aware of it, then you can think about it ahead of time. You can actually call the shots or be part in calling the shots, so they are most appropriate for your team and your team can deliver the biggest impact.

Henry Suryawirawan: [00:28:17] Just a little bit of a related discussion. So in enterprise, typically there are already like powers already established, right? Maybe let’s call it political power. So how would a new person navigate this political power? If you have experience working with such like established enterprise before, how would these people put himself in the decision-making table?

Aviv Ben-Yosef: [00:28:38] Yeah. So I’m not going to say that it’s going to be straightforward at every different organization. But first of all, the shift to move upstream starts with yourself. You have to realize that the SpiderMan saying “with great power comes great responsibility”, and the opposite is also true. If you’re an executive, and you have great responsibility on a big team, you should also have great power. You should be available at those higher ranks and see what’s going on. Understand and have people regard you as a partner. So it starts with that mind shift, understanding that you deserve that. Not just you want it politically. You want it because that’s the right way of managing stuff. And then, you have to find the ways to move up. In Israel, we say chutzpah. Because we are okay with pushing ourselves where we think we should be. I’m finding it sometimes harder to help my international clients understand that’s a big part of their role, but it is doable. For example, examples of chutzpah that I’m helping my clients do is when we see that the end of the quarter is reaching, and around the corner. And there are no discussions that the executive is aware of about the roadmap. I say, “Someone’s talking about it. Who is it? And why aren’t they inviting you?” So, open their calendars, and see if they have any discussions that you’re going to ask to be invited to, or go over to the CEO and ask, “Hey, what’s up.” You have to take the initiative because sometimes it’s not because it’s even political power. People are not thinking about the Tech people as having that sway, of having the ability to sit in the business meetings. Not because we can’t do it, but because they have become accustomed to the Tech people wanting to do Tech, and not caring about the business enough. So you have to help educate them and push yourself a bit. It might be a bit uncomfortable in the beginning where you have to elbow your way so you are in the meeting, but it’s going to happen.

Henry Suryawirawan: [00:30:28] And especially in this region where we, Asians, tend to be less aggressive in dealing with all this territory. So I think it’s a good message. And also depending on the culture, I think as well, because if you try to push yourself up, but the rest are not into those kinds of a culture. I think it’s going to be a problem as well. So, any take on that? Especially if you have worked with Asian culture before.

Aviv Ben-Yosef: [00:30:51] I would say that it always has to start with, again, the other person’s interests, and what actually serves them best. You have to have a candid conversation. For example, if you’re reporting to a CEO or if you’re in a bigger enterprise and you’re a VP and there’s an SVP or an EVP above you, and you want to take part in some of the discussions, you have to help them realize what they’re going to get from working with you. Do you know the acronym WIIFM? What’s In It For Me. It’s something that you always have to keep in mind also when working with your staff. But sometimes when working with your colleagues and your boss, you have to see that whatever you’re doing has to also pay off for them because otherwise they’re not going to do it.

When I’m talking to an executive that doesn’t want to cooperate, I’m trying to create a win-win. So if you come up and you say, “I don’t want to be there just because I want to spend more time in meetings.” No one wants that. I’m guessing. What I want to do is I want to be aware of what’s happening because do you remember the last time that we missed a deadline? Because we realized something is too late. If I had known about it early, I could have done something else. So I just want to be, take part, make sure that I’m aware of stuff. Sometimes I’m saying, “Let’s do a prep meeting before so that no one feels threatened.” If you have talked before the strategy meeting, and your boss doesn’t feel like you’re going to say something that’s going to add a bunch of work they don’t want to do or stuff like that, that can lower the stress. But really, if there’s something that’s not straightforward is to position yourself in a place that has political games already happening. That’s something that I think is maybe the hardest part for techies, because we’re really good. When I’m talking about Tech execs really good at Teching, but we’re not good at execing. And sometimes you have to speak up. Sometimes you have to be a bit, I won’t say rude or aggressive, but you have to be more assertive. Otherwise people are not going to just say, “Come on in to the meeting,” by themselves. Sometimes they’re going to. But other times, you have to knock on the door by yourself, and it’s not that bad. You’re trying to do something that’s good for the company, and you’re not trying to harm anyone.

Balancing the Time [00:32:55]

Henry Suryawirawan: [00:32:55] Totally makes sense. Speaking about meetings, I know that executives normally need to spend a lot of times in meetings. Maybe gathering context, making decisions, understanding about other priorities from business, marketing, sales, whatever that is. So that makes it even more challenging for a new Tech executive coming in. How to balance the time? Where should they spend time or even like juggle between all these priorities?

Aviv Ben-Yosef: [00:33:19] So I have my rule of thumb about how much time we should be spending on different things that you’re doing. It’s going to change depending on what you’re doing right now. Sometimes you are lacking in some positions. So if you need to be hiring a new director under you, and in the meantime you’re filling in for the director, you might have more time doing regular work or helping people. But I do have some rule of thumb. First of all, you should be spending a good amount of your time in one-on-one meetings. Not just with your direct reports, but also with your colleagues, and with skip level one-on-ones with the staff under you, even if you’re not their direct manager. Because I think that you need to be getting that sort of insights and context from people who are doing the work. You should also be doing a good chunk of what I call management by walking around. Let’s say about 10% of your time. In non-COVID world where we can actually walk in offices, that means walking the halls, maybe sitting a few hours a week in the open space to see what people are working about.

Yeah, if there’s something I really enjoy seeing is, again, think about the old world where we had people in the same room. You can sometimes spot the debugging huddle, where you see someone sitting next to a laptop and a bunch of engineers around them, looking at the screen together. Sometimes that means that there’s an outage, sometimes just an interesting bug. And when you spot that, you just start listening and you can see how people are communicating. How they’re handling things. And you can pick up a bunch of information, like how are we handling things? Do we have good processes and guidelines for handling outages? That sort of stuff. Things that you’re not going to see, for example, in a post-mortem, because whoever is in it, doing it, might already be used to the way that they’re doing stuff, and they might not realize that they’re missing parts of it. So management by walking around is also a big part of it.

I believe that there are also other things that can help you. For example, if you want to enable yourself to do the most, I usually say something like 10% of your time should be leadership blocks, which are you blocked time on your calendar to think. And I know that sounds weird, but the analogy I always use is how when you’re in the shower, you get all sorts of good ideas. You probably can’t take an hour long shower in your office, but you can take the time to just focus on things. And sometimes that time can be something like, I want to think about the roadmap for the next quarter. Sometimes it can be stuff like investing in your own product mastery. Maybe you’re going to watch some Gong.io sales meetings. Maybe you’re going to see what customers are saying on Twitter, whatever. And sometimes it’s actually thinking about big problems. How should you, for example, structure your team going forward. That kind of time you have to work on your organization, not just in it.

And then there are also a bunch of other things you should be doing. You have your emails, you have to be answering. You have a bunch of time on hiring because you have to be interviewing people. You have to be putting out fires. You have this buffer for at least 10% of your time that you’re going to do stuff that weren’t planned. After all of that, I usually aim for around 25% of your time in other meetings. Not just one-on-ones and not your personal time doing leadership blocks, but meetings for work. And if you see that you have more than that, you might need to be changing things. You might need to be delegating more stuff to other people. You might need to, for example, I call this defragging, like you used to do on your old windows computers. Let’s see if you can make some of the recurring meetings shorter so that they’re not one hour, they’re 45 minutes. Maybe you can make it so that you are not one each week, but one every two weeks. That sort of stuff. So you can make more time for yourself.

Henry Suryawirawan: [00:37:00] I like the way you use some of these geeky terms to explain about tech executives. I think it’s really refreshing.

Management by Walking Around [00:37:06]

Henry Suryawirawan: [00:37:06] So I’m very interested about this thing called management by walking around. During this COVID, how would executives do such thing?

Aviv Ben-Yosef: [00:37:14] Yeah, so it’s definitely harder in a remote world. But I’ve been helping my clients try all sorts of stuff. For example, you should be joining all sorts of Slack channels that you’re not usually on. Not because you should be reading each and every single message. But if you were in all of the different, even the spammy channels where people are sending memes or sending TV shows and stuff like that, you can see what people are talking about. What’s the culture like? Who are more active at different hours of the day? So you can see, maybe you can notice that someone might be having issues because they’re working late at night. Stuff like that. You can also try and inject yourself into some interesting conversations to see how people are handling an outage online. And you can see that maybe if they would use a dashboard that they both can see at the same time, it would help. So management by walking around online is sort of doing that.

Also in our age, where a bunch of meetings are being recorded automatically. I always say that now it’s much easier to be a fly in the room because you can be a fly in the Zoom. I will also do it with a bunch of my clients where we take some of the recorded meetings, maybe the dailies, maybe sprint planning and retrospectives, and that sort of stuff, watch them sometimes at double speed to see how things are going. Are we seeing, noticing some interesting stuff about how people are interacting? Do you see that there are certain people who never actually speak up in meetings? Do you see others hogging the meetings? That sort of stuff. It’s more time-consuming, and it’s not as fun as being in a physical office. But it’s something that actually can help and provide you with bigger context of how things are doing.

If you’re not doing it yet, I’ll always recommend doing these Q&A’s, ask me anything with not your entire organization if you’re too big. If you have more than a few dozen engineers, you might not get a lot of value from doing it with everyone together because it’s not as intimate. But it’s around team level kind of thing, or a couple of teams, or it’s you and a dozen people. That might be very, very helpful, and not just for you, but also for them. And it helps them see that you’re involved, that you’re there. If there’s something that you get from management by walking around physically, it’s that you see that someone cares. The manager actually walks the halls, is present, is there for you to ask them something as they walk past you. And you don’t have to create the same sort of platform for your people online.

Henry Suryawirawan: [00:39:36] Wow. So many great tips. I hope all of you listeners can try out some of these. During this working from home, working remotely, so we missed that kind of connection with individuals. Are also missing this kind of huddle when people crammed together, looking at some problems together. So I think that some of these hacks during this remote work and working from home, I think we could give it a try, and hopefully we can gain more context from the team.

Creating Impact [00:39:58]

Henry Suryawirawan: [00:39:58] Speaking of the next thing which is about creating impact. Let’s say after two, three months in the role, you start to come up with a plan. You start executing stuff. How do you think an executive, a tech executive, should make an impact? Is there any strategy, how should they think about making an impact? Is there things to focus on?

Aviv Ben-Yosef: [00:40:17] Yeah. So, impact is a big topic. But first of all, you have to start, again, with thinking about what’s going to move the needle for the business? What actually matters? As an executive, your product is no longer the actual tech, what the team is delivering. But your product is the team. You have to invest in them. You have to help them grow. Your iterations are iterations on the team. For enabling impact, you have to create the team that’s oriented around that impact. So, for example, I’ve mentioned OKRs earlier. You should think about ways to create a connection, a direct connection between what your team is doing, and the impact it’s going to have on the business. So a bunch of companies nowadays are trying things that are around the Spotify model, where you are working in squads. Each squad is end to end, and you can do things entirely on your own. You don’t have to depend on other squads. That sort of cross-functional team usually allows for more of an impact-driven mindset. Because you can then take an objective, put that objective, assign it to a squad, and then the squad has to do that. They know that they all succeed together or fail together, when they have this one big goal that they are after.

You can say, if there’s something I hate seeing, is the back end person saying, “My API is working. It’s ready two weeks now. It’s the front end who aren’t ready by now.” No one cares. You’re not going to call a client and say, “The API is ready. We’re just still working on the frontend.” No one cares about that. So you have to work together in creating these squads who get these impact-driven goals. You have an objective that allows them to create their own impact. It’s amazing. For example, when it’s an impact-driven goal, let’s say that you’re the manager in charge of one of these squads. If I provide you with a goal where that’s very specifically defined, I’m telling you exactly how to implement something, I’m telling you exactly what to do, you’re not actually empowered. I’m not empowering you to do anything. I’m just telling you exactly what to do. I’m forcing you to be a JIRA resolving machine. But if on the other hand, I give you a goal. You are in charge of this part of the business, of this part of the product. And we want to see the lifetime value of the customers using this go up by 5%, or we want to see churn go down a bit, or stuff like that. Then that engineering manager with the product manager can work together, and the whole team can work together and decide what they need to be doing. And that’s truly empowering people. I really liked the book “Empowered” by Marty Cagan, and he has other books like “Inspired” that are really about this way that product should be working and being developed in highly successful engineering teams.

Henry Suryawirawan: [00:42:56] I like the way you mentioned about all these impact-driven goals or impact-focused organization. So sometimes a little bit tricky when we talk about engineers. They are very savvy with technology, all these frameworks, languages, infrastructure. But somehow missed looking at those business impact or OKR sometimes. And I like the way that you mentioned that the Tech executives who play as a bridge. But I know changing the mindset is quite tricky. What do you think are some of the tactical things that an executive could do in order to change this kind of mindset for engineers?

Aviv Ben-Yosef: [00:43:29] I’d say that first of all, they have to have the product mastery. You have to help them get the product mastery. Because then they actually can think of other things that are not just the Tech. The reason we go for the Tech stuff, that we obsess over the Tech debt, when you go over those kinds of stuff is because for us, it’s the path of least resistance. We know how to do that. We have all the ideas running around. We have the expertise. So that’s the natural thing for you to do. Once you have the product mastery, and once you understand the impact your things have on the company, on the customers, it’s natural for you to start thinking about that. Then you know it won’t happen for a hundred percent of your engineers, but enough to start thinking that way, which slowly gains more and more momentum, which is great.

And another way is to slowly but surely celebrate the right kinds of things. So you have to help people see what actually matters. For example, I always tell my clients, you shouldn’t just celebrate when we reached everything that we had in the roadmap. If three years in a row, every sprint, the team is delivering a hundred percent of what they had in the sprint plans, I know that they have no stretch goals. I know that they probably have way too many buffers being put in place so that they can always reach those goals. On the other hand, if I have a team that’s delivering, let’s say, 80% of the time they deliver everything, but once in a while they take on the stretch goal, and sometimes they miss it, that’s the kind of team of a squad that actually might be pushing the company faster forward because they take on some risks from time to time. We can’t be, you know, we can’t put all of our money in Bitcoin, but maybe we need to put some of it. That’s the kind of thinking.

R&D [00:45:05]

Henry Suryawirawan: [00:45:05] And I think when you say about stretch goals, sometimes this relates back to things beyond just the tasks or the features that the business is asking, right? It relates back to the Tech Capital that you mentioned, it relates back to R&D, you know, researching about new stuff, new, either like platform tools and technologies. Where do you see R&D in play for Tech executives to focus on?

Aviv Ben-Yosef: [00:45:26] Yeah. So I say that we’ve become accustomed to R&D being treated as a cost center. As something that the business has, and they have to pay for it, but it only produces costs. It doesn’t produce money, right? Sales are in charge of actually bringing in money to the company. Marketing help find prospects. But R&D, we just need them because we need the code, but they don’t actually generate money. That’s the kind of thinking. It’s a cost center. And I say that we need to transition our thinking to becoming an innovation center where we can create. Such examples are like the Tech Capital example I used earlier about a tool that helps the sales people create a better pipeline. Or another example would be creating these abilities for people to iterate faster, like I talked about emails from marketing, that sort of stuff. Those are innovations that genuinely helped the company make money faster. Generally it helped the company iterate on its product market fit faster. That’s the kind of innovations that sometimes we need.

Sometimes innovation is very technical. You can create a competitive advantage for a company that’s purely technical, and that’s also Tech Capital. For example, I was eating lunch yesterday with a couple of engineers who are maybe some of the brightest engineers I’ve worked with. They were working at this AI medical startup, and they found a way to put some sort of medical device mapping viewer inside a mobile app, something that no one has ever done prior. Something that till that point, you had to use very heavy and costly workstations that had these special GPU’s only to use that. So specialty doctors had those in their offices, and they had to use those in their office next to the desk. They had to go there and see that. Those two engineers found a way to do that, 80% of what was needed on mobile. And that just helped that company sell so much because those doctors said, “Now I can do it right from the table of the exams next to the patient. I can do it everywhere. I can check it when I get the update data, the data has been updated. I can check it no matter where I am in the clinic. I don’t have to go to my room and see it.” And that was an enabler. And that’s another example of Tech Capital and how you create an R&D team that’s an innovation center, that actually brings in new ways of doing stuff. And when they started doing that viewer, they didn’t know that it was possible. They just had an idea and said, “Let’s try.” To create an innovation center, you have to create the space for innovation. You have to create the space to fail, sometimes. They might have invested two days and have nothing to show for it. But if you don’t allow them to try from time to time, you will have zero innovation, right? People would just look at, again, the JIRA dashboard and do whatever JIRA says they need to be doing today.

Henry Suryawirawan: [00:48:11] I think maybe famously this concept, like innovation 20% kind of rule from Google, right? Is it how you also see it in some other companies? How they introduce this R&D? Is a 20% rule? Or some kind of hackathon? Maybe can share a little bit from your experience consulting different companies.

Aviv Ben-Yosef: [00:48:28] I actually have so much to say about how you create time for innovation. And I think that the 20% time that people know from Google isn’t good enough. I advise people to do something that I call intermissions. Some companies call it sabbaticals for something that’s similar. For example, Basecamp have been talking about their sabbaticals, which is every few sprints, let’s say every six, seven, eight weeks, something like that, you have a week, that’s an intermission or a sabbatical where the team is in charge of doing what they want. I rather that it’s not just another hackathon because hackathons too often end up just being, we’re trying fun stuff and it doesn’t have any actual impact. I would rather the intermissions are actually about thinking. Sometimes it’s about tech debt. Sometimes it’s about creating Tech Capital. Sometimes it’s about learning something new. But you need to be thinking about the impact that it has so that, let’s say, over a year, you have some substantial Tech Capital gain from those intermissions, and to create the time for it.

The difference between an intermission where an entire squad is working together on something in 20% of time is that 20% time is, I decide that I’m going to do it on Monday. You’re going to do it on Tuesday. We’re not working together as a team, and so our leverage is very fragmented. We don’t gain momentum. If you have a whole week to work with your team on something, you can gain so much. And I’m actually seeing a trend right now where some companies are implementing intermissions, are also integrating all sorts of low-code or no-code tools. So, what you get done in a day is like what you would get done in a week. Of course, you can’t use these tools for everything, and it’s not a replacement for all of your production code. But if you want to create a tool, a back-office tool for the salespeople, or you want to create a simple user interface for editing emails, stuff like that. If you use these tools, you can save so much time, and a week of your time going back to the coders without borders, think how valuable, how enabling a week of a coder’s time can be for someone else in the organization. And when that code is using low-code or no-code, they can get done in a day what they might get done in a week. And so a week of intermission can create so much innovation in the company, and that’s what I’m driving for.

Henry Suryawirawan: [00:50:40] I really like this intermission concept, and we can see all these new things that you put in this episode, coders without borders, like intermission, all seem to play nicely along together. And also don’t forget, I mean, like when you create this Tech Capital, it doesn’t mean that it’s only engineer who can do it. Sometimes they can also teach the other division departments to actually learn about this low code, no code, for example. And maybe they can, in fact, create more of it by themselves, which is a multiplier effect.

Organizational Debt [00:51:06]

Henry Suryawirawan: [00:51:06] Moving to the next topic which is about organizational structure. I know that I’ve seen one good discussion point about organization debt. Again, this is a new concept, right? I know about tech debt. Now I know about Tech Capital, but now we are talking about organizational debt. What do you mean by that?

Aviv Ben-Yosef: [00:51:22] Yeah. So likely, we have code smells. As an advisor, as someone who’s working with dozens of companies, I have started noticing organizational’s smells. I see the org chart, and I get this tingling feeling that something’s off. As your company grows, and as things change, especially in startups, but also in enterprises, you gain some organizational debt. Because we can’t refactor the organization every week. We have someone leaves the company, and that leaves a team that’s a bit too small. You’re not going to disband the team just because someone left. But let’s say, a quarter or two have passed, you might have acquired too much organizational debt in some areas of your organization, and you need to be changing stuff.

For example, one of the smells I have is what I call premature organization, where I noticed that there are a bunch of teams that are way too small. We have too many managers managing not enough people, or we have a bunch of titles. I say it’s like going to a medieval show where everyone is a Sir and a Knight, and the Lord of that, and the Duchess of that. Because she is the Duchess of the frontend. He is the Duke of backend, and you start splitting the entire organization between those titles. For a team that’s too small, that’s exactly what I call premature organization, which I’m guessing, you know about premature optimization writing code. And that’s the same when we start providing titles too soon, when we create teams prematurely, we create something that’s not healthy for the organization, and that’s organizational debt. And sometimes that means that we need to unite a few teams together. Make sure that we don’t create titles that create a zero-sum game. Again, going to the example of, usually it’s not Duke and Duchess, it’s Tech Lead for backend, and the Tech Lead for mobile, and the Tech Lead for product. If you have those titles in a smaller organization, it means that let’s say, that you have the backend Tech Lead, and two months later you hire someone who is a world class expert at backend. Does that mean that they cannot voice their ideas? That they can’t take initiatives because there’s already the Tech Lead? No. If you avoid giving titles that split the team too soon, you can create the space, and the place for people to voice their ideas, to take initiatives, to push things forward. That sort of stuff.

Henry Suryawirawan: [00:53:41] Any ideal of team size that you have? Maybe rule of thumb, or like best practices that you’ve seen?

Aviv Ben-Yosef: [00:53:47] My rule of thumb is usually to aim for something around six to eight people in a team. If you have a team with a team lead, that’s relatively new, you can aim for teams that are a bit smaller till the team lead gain some experience. If you have a team, that’s maybe with a manager that’s very experienced, or that the team itself is very experienced, more towards senior, you can get to bigger teams. But the rule of thumb would be around six to eight people.

Conway’s Law and Microservices [00:54:15]

Henry Suryawirawan: [00:54:16] I also see this maybe a relation with how you split microservices. Sometimes you want to split microservices, you split teams as well. We all know about Conway’s Law, right? So again, what is your take about this? You know, splitting microservice, splitting teams, sometimes it’s just splitting microservice, but the team stays the same. So what’s your view on that?

Aviv Ben-Yosef: [00:54:34] I think that, again, Conway’s Law is very true in many companies. But the problem is that sometimes you end up needing to change the microservices because of product changes, but you can’t as easily refactored the team around it. That is why I try and push toward teams where people don’t take charge for a specific microservice, but take charge, again, for a specific business need. So it might be a business need that completely encapsulates some microservices. But some microservices have a shared responsibility across several squads. That’s usually healthier because it means that you have more flexibility to change your microservices, and also you have flexibility to change your squads. With time, as your objectives change, without having to start assigning different responsibilities and code ownerships to people when it comes to the actual microservices.

Product Mastery [00:55:24]

Henry Suryawirawan: [00:55:24] You mentioned a lot of times about product mastery. People in the team or even the executives themselves needs to know about the business, needs to know about the product, maybe the problem it tries to solve. Any other angles that you want them to actually master about in terms of this product mastery?

Aviv Ben-Yosef: [00:55:41] Yeah. When it comes to every Tech Lead, and I think that every engineer, everyone who has some sort of a leadership role, not just executives, we have to work hard to get that mastery. To avoid that, we have to first not go into the organizational pigeonholing we talked about earlier. You also have to stop stress technical mastery. If you promote only those people in your team who are best technically, but not those who have impact, you’re going to create an incentive for the team to focus on Tech and not on the product. So you have to do those at first in order to create the right kind of mindset and culture in the team. And then to bootstrap the product mastery, you have to work hard in order to get your people to, I call it rub elbows, have friction with the actual users, with the actual business. So, for example, have them be attending the QBRs, listen to sales calls on Gong, or whatever tools you have. Read up what’s going on in the market. When I work with my clients, I help them set up this sort of a feed that the entire team can see. Maybe it’s a Slack channel that has related articles. Maybe it’s an actual newsletter or something like that. That the executives and the managers start sending links to articles in the Wall Street Journal and the Economist about things that are related to the market, the company he’s working in. So people gain the broader perspective, that sort of stuff.

And lastly, to gain product mastery, there’s no way around it. You have to see how your clients use the product and why. So I, for example, recommend doing shadowing for customer support or customer success, let’s say, once a quarter or something like that, where people have two, three, four hours where they shadow customer support, and see how they’re handling things? How do your customers even report a problem? When they see an issue, do they realize what the issue is? Do they know to say what they need changed? Do they know, for example, when there’s a bug? Can they say I can’t do X? Or can they say something more specific, like, “I noticed that this feature is not working.” These sorts of stuff that even just noticing the language the users are using, you can realize, “Oh, I might need to change the little alert bubble that I have”, because all too often, product don’t define each and every little copy string that you have that the users are seeing. And we make a bunch of micro decisions as engineers and those have impact on our end users. So if you notice that you’re using a word that your clients don’t understand, or use a term not correctly. If you see what customer success have to go through, all of a sudden you have a bunch of ideas, and you realize what people read, how they act, and what they care about.

Henry Suryawirawan: [00:58:21] Right. I mean, like some of these examples, what I can think of quickly is that some of the cryptic or geeky error code. Maybe like an internal server error, or whatever that is.

Product 101 [00:58:29]

Henry Suryawirawan: [00:58:29] So another thing that you mentioned as an example is to come up with product 101. And I think this is also sometimes baffled me. Like when I talk with the engineer, for example, so what does your company do? How does they make money? Some of them really don’t have any idea, or maybe they can say, “Oh yeah, whatever that is advertised.” But really, they don’t understand the essence of how the company is making money or how the business is working. So how do you create this product 101? Is it like you have a Wiki? You have a seminar, or you have like onboarding kind of things? How do you create this knowledge within everyone in the company to have understanding about the business and the product?

Aviv Ben-Yosef: [00:59:04] Yeah. So I define a bunch of topics that need to be in this product 101 short course that you have for people. That means the basics of the business like, how does the business model work? If you’re in a startup, you have to share, at least at some level, the finances of the company. When you’re expecting to raise another round? How your sales have been trending so far? That sort of stuff that your engineers need to be aware of. Who are your competitors? What your competitors are working on? What is the company’s roadmap and vision? How the market looks? How big is the market? Who are the usual clients? Are they an enterprise companies? They just see in different demographics sort of stuff that you need to understand and also understanding exactly how your users are handling with other products so far? People who haven’t switched your product by now, how does your data look? Are they wasting hours? Is it just costing them a bit more money? Is it just not fun? What is the pain that you’re solving? How do their lives become better because they use your product? That sort of stuff that you have to know. And some of these are things that are rarely changing. You can do these ones right in the Wiki, create a short article about it or a video, and be done.

But other things are constantly changing, right? The business changes. The trends that you have, your roadmap, everything is alive, it’s going to change. So I would say that you have to make sure that your onboarding is very fresh and updated and up to date. But also, I recommend having refreshers to these 101 sessions, like every quarter or so, have a bunch of data sharing happen across the company. It’s not just for engineers. It’s very valuable for everyone in the company. And as a Tech executive, you have to make sure that your colleagues understand the value, and you all share your learnings, your roadmap, your vision, so people have a wider context. It’s sometimes a bit hard because some engineers see another invite for a company-wide whatever, and you’re like, “Oh, another hour wasted.” It’s our role as Tech Leads to make sure that our people understand that this isn’t just something… it’s not a hassle. It’s what helps us actually become force multipliers in the team, and deliver the best impact. It helps us leverage our roles in the company by having that context. So you might not be feeling like sitting through another Zoom, but that’s what’s going to help you long term. I truly believe that. I hate useless meetings, just like the next guy. But I still believe that some of these are crucial, and we have to make sure that we have them correctly, and in a way that helps everyone understand the context.

Less Principal Engineers, More Product Engineers [01:01:39]

Henry Suryawirawan: [01:01:39] So related to this, actually I saw one of your popular blog posts, which is about less principal engineers and more product engineers. In fact, I had one recent episode, also, the guy is talking about data-driven product engineer. So it’s more specific to be more data-driven. So, why do you think we should maybe emphasize less on principal engineers, or maybe staff technical engineers, whatever you call it, and to be more really like product engineer? Because this title is not common yet, I think, in the industry. So what kind of message that you are trying to convey with your blog posts about this?

Aviv Ben-Yosef: [01:02:11] Yeah. So, first of all, I will say that I have no issue with having career ladders in your company where people advance through the ranks and become senior staff principal. I have no problem with that. But what I am saying is that when you’re interviewing, when you’re promoting people, when you’re deciding how your culture is going to look, make sure that those people that you have, and the people that you’re hiring, don’t care solely about the Tech parts. About principal meaning that I am the best person in the world when it comes to React Native apps. But that at least part of those promotions, part of the wider responsibility that you’re expecting from your more senior people, is that they have the product vision. And when I say product engineer, is someone that has broader shoulders in the team. Someone that is capable of taking big tasks, and also has enough context so that when you delegate something to that person, not you directly, maybe as the VP of Engineering, but even your managers in your company. When they have those product engineers, those broad-shouldered engineers, that they can delegate a big feature to, and they will make sure that they will get it done. They will raise a flag if something’s going in the wrong direction. They will ask the right questions. Those are the kind of people that you want, and that’s what you need to be stressing as your team becomes bigger and bigger.

Henry Suryawirawan: [01:03:31] I like that you emphasize asking the right questions. Because sometimes what happens engineers just saw the maybe JIRA card. “Oh okay, this feature. Okay. Let me just do that.” They don’t really ask around like, “Why you designed it this way? Why the writing is this way?” Or something like that. So I like the way that you emphasize asking the right questions.

3 Tech Lead Wisdom [01:03:48]

Henry Suryawirawan: [01:03:48] So Aviv, unfortunately due to the time I think we have to wrap up pretty soon. Thanks again for sharing all this. But before we wrap up, normally I would ask all my guests to share their 3 technical leadership wisdom. So do you have the wisdom that you want to share with my listeners here?

Aviv Ben-Yosef: [01:04:02] Yeah, so we’ve covered some of these. First of all, I think that we all need to embrace product mastery. Not just if you have some spare time, don’t just read up what’s trending on Hacker News, but also read up what’s happening in your market, and understanding your company and your business and everything. That’s number one. Number two is accepting the coders without borders mentality. So you don’t just think about how you are going to deliver what’s on the JIRA, but look around. Look at your colleagues in the company. Look at different departments and think how you can create tech capital that helps them. Not just create and implement whatever feature you have in your roadmap. And lastly, if I may plug the book one last time, I think a good wisdom is to get a copy of my book.

Henry Suryawirawan: [01:04:45] So I like that you put the icing on the cake, right? I think I learned a lot as well, myself from this conversation. I think there are lots of wisdom that you can learn from the third wisdom here, which is to get the book. It’s called “Tech Executive Operating System”. Where can they find it? Is it like on Amazon? Online?

Aviv Ben-Yosef: [01:05:03] Yeah, it’s on Amazon. You can get it on paperback, you can get it on Kindle, and if you want to get a sample chapter, you can go to techexecutiveoperatingsystem.com and download a sample chapter.

Henry Suryawirawan: [01:05:12] Great. I’ll make sure to put it in the show notes. So thanks again, Aviv, for sharing all this. I’m sure many listeners, especially aspiring Tech executives or Tech executives themselves, would benefit from some of the advice that you gave. Thanks again for your time. I wish you good luck with all your consulting and make more people successful with their product mastery and coders without borders and things like that. So, thanks Aviv.

Aviv Ben-Yosef: [01:05:33] Thank you, Henry. I had a great time.

– End –