Tech capital is about creating something that enables things that weren't possible before. And those are the kind of stuff that eventually end up paying long-term. Do have to ensure that when you have these initiatives, when you working on Tech Capital, it has to actually be Capital. That's actually genuinely helping the business enabling other people in your organization. Hey everyone. My name is Henry Surya Barragan.
And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello, to all of you who are listening.
It's always good to be back here again with another new episode of the technology, you know, podcast. Thanks for tuning in, and spending your time with me today, listening to this episode.
If you haven't, please subscribe to technology, you know, on your favorite podcast apps such as Spotify, Apple podcast, Google podcasts and YouTube. And also, please follow technology on our 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 package, you know, dot, f / 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 lead us to help them, create world-class engineering teams, ranging from early startups to Fortune, 100 companies in this episode. Are we've 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. Dot Shifting, the engineers 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 depth towards the end of if also explain why we should not forget to put more emphasis on product-oriented Engineers instead of principal Engineers who Focus solely on just the tag.
I personally benefited a lot from avoid 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 living 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. Are you looking for a new cool? Swag technology, you know now offers you Swags that you can
purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool tracks available by visiting technology, you know, dot, f / shop, and don't forget to break yourself. Once you receive any of those tracks. Hey everyone, welcome back to another new episode of the package, you know, today I have with me someone from Israel, so he's an author.
Advisor and coach for executives. He is the author of the book called Tech executive operating system. So in this episode, I hope we can talk a lot about that or what is Tech executive operating system. Exactly. And what are we if is trying to tell Tech Executives in order to increase and maximize their leverage in an organization, so a wave, welcome to the show. We're excited to have you here. All right. Thank you. Very excited to be here. So I believe in the beginning.
Maybe you can introduce yourself telling us about your career Journey, maybe some highlights and Turning points. Yeah sure. So I must've been a spiv based in Israel. Like you said, I taught myself coding around when I was nine years old. And ever since I've Been a Murder with code and we're creating this magical world. 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 in 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 start-up for the past nine years. I've been independent and that was a big change for me. After being a first employee at a start-up. 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 got a super freelancer. I went around a bunch of very good startups here in Israel, and I hope them with product development coding. Basically, I call myself a very expensive Band-Aid because We're engineering teams that we're delivering, as fast as they should be. And so they have to bring someone like me. And I had a bunch of fun. I helped 567 Acquisitions of work 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, our Southern deliver faster, but when I left things usually went down to the way it was before and that was when I realized that my 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 peepees of engineering because of our Indie to create these world-class engineering teams. So that's the mission. I've been on. I'm sure in terms of transition from being the coder, the doer Implement 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 I need tips or advice. Yeah. I think that it actually was done to the same things that make you an excellent executive or I'm 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 clients 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. And that's when things actually in my experience, start working when you can allow yourself to do that and it's a bit scary. But with the right, Work, I believe that more people can do this than would imagine. 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?
Yeah. So here, I've been working with dozens of people, who some are first-timers as Executives in charge of engineering Innovations. 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. There are in comment for no matter if you're a tiny startup in your first year, and if you are unicorn with hundreds of Engineers under you, I see the same messages in the same principles helping And all of those levels, so that's what the operating system is intended to help my readers with. So is it intended for like incumbant Tech leaders or is it
for aspiring new leaders? Maybe tell us more about this operating system. 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 road doesn't matter, but I've been getting feedback from many readers that they find it very helpful for them to To decide whether they should become an
executive order. Their 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 your own startup and stuff like that. So I think it's beneficial to everyone. 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 on 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 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? Well, it might be a game 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 gonna 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 when the stand That when we're 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 objective. So it's like creating your own. Okay, ours with the CEO or your boss to That you're going to have the biggest impact that you can on the company and organization. And you mentioned, there are four responsibilities in the book in short is Leap. Leap2a.
Be, you can share a little bit of. What do you mean by these four responsibilities? Yeah, having talked to hundreds of Executives and I'm saying, Tech Executives, because there are a bunch of titles ctOS,
cio's, 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. They are usually free archetypes on the tech executive. The E stands for evangelism, which is a outward-facing executive.
For example, if you're a company, that's b2d business to develop heard 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 strike, for example, or the Apple Executives, who talked at the The DC conference, that's the evangelism part. The a stands for architecture, which is the person who has responsibility for architecture and innovation of the engineering team of the R&D team.
That might be the standard CD o in air quotes, where it's the person who knows a bunch of about deep Tech needs of the company who has Labs triangle sorts of experiments. And lastly, of course, there's pee for people who is in charge of the actual processes. And the people delivering the work often titled, the VP of engineering. So you also mention in the book, but 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 executive, 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. Maybe he can tell us more. Why do you think attack executive should think in long term?
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 gonna 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 The long term does that mean that you're not going to look at the short-term? Of course, there will always be far as 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 at the surface because the team deserves to have someone that's looking ahead and trying to think how to best utilize them. Otherwise you working like a greedy algorithm. It's not looking far ahead enough and therefore you might be Shaving some local maximum, but not the real maximum. This team should be striving
for. 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 have heard about technical debt, but Tech capital is something that is new for me. Yeah. So we've all heard about tech that and that's my main issue with it. I'm hearing people talk about it all the time and are spending so much time doing 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 two dollars a day and stuff like that. Now we see that there's a limit to how much you can gain by lowering your death. 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 features like the stick and 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. 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 as when at a start-up
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 something. King 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 help them see how things are changing in the city.
There were currently targeting the whole says, organization started being driven by this tool. So that's Tech Capital because he created something that then enables. Something no one else before fight was possible. And those are the kind of stuff that eventually end up paying long term. So you mentioned that, this is different that features, right? Because intact 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? I think that first of all, you do have to ensure that when you have these initiatives, when You working on Tech Capital? It has to actually be Capital some of the time with the team should be doing. Stuff. That's very technical, not Tech that necessarily some of it would be Tech that because we can't really get rid of it.
Sometimes you'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 test 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. Bonita cycle times become months. Once someone 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, that'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 quotas Without Borders. You want to create Engineers, that help, not just the Direct Customer after company, but everyone in the company, so you might be hoping 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. So I like the term when you mentioned coders Without Borders from your examples, few things that we can listen or The engineering helping the marketing or the sales team to build some tools that can help them to do more, self-service, tasks, 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. But like they don't like talking to humans. How do you create this environment where the coders Without Borders actually Excel? Well, we have to avoid the creation of silos. We have to avoid people. Ooh, Cajun, holding themselves and as Leaders, pigeonholing their 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 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 are 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 everything is so small that people are aware of what's going on.
But as you become larger and especially at Sighs is it gets a lot harder and you have to do active work. Just the other day. I was talking to a CDO who told me that his Engineers started replacing the Netflix time with
watching ganga. Yo, 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 engineer started listening to those, you know, like you're watching Netflix. They did that not because anyone ask them to but because they were interested and they gained
such a broad. 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 AGA. Are 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 of, with a feature or a new product, you can poke holes. And so, you know, I think that the customers really care about this, right? So maybe we can put away those extra 20% of the future that's going to cost us 50 percent of the work and see if data by itself is worth it. You can have those conversations as a partner to product, which
is a goldmine for the company. I mean, all these things that we have discussed, it seems like if you are new and you won't be able to do it all in one go, right? Like you 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 of your few days for new tech executive coming to a company? What should they do? Yeah, right.
Now, I'm helping in advising a few people who are in their first couple of months and 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 3 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 for emergencies that 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, with the CEO, once 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 Ward 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. 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 a 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 what 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 triage 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 initiative, decide whether you want, for example, reorg, the company change.
How your Sprint's are being managed, how the roadmap is being managed, how the teams operate and talk within themselves, or sorts of stuff and decide if you need to change stuff in the personal self should. Be hiring more people. Should you be on a no 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 to rapidly, we like things being as we are accustomed to it. There are windows where people are more receptive for change. For example, when someone One 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, to get used to how things work, and the same applies. When you have a new executive in your first 100 days. In the company, people are more receptive for change because the expected to happen at least somewhat. So you should try and kick things off. I'm around 23 months and then I think that once you Get off, you should make sure that, you know, and everyone else know that it's
not gonna be the one true way. Maybe you're trying a reordered but it doesn't mean that you've just realized what's the best way to do stuff. Just like encoding, 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 you want to rename a method but you still need to have an organization that understands it. You don't have all the answers.
Has the right answers right away to you are also learning and adjusting the company's going to change. And that's a health effect. And also, it relates back to the fog of War, thinking back my old days, playing this strategy games, every time new fog, clears out. You always find new things. Maybe new adventures, new challenges, new enemies Balzac and whatever. So, I think it's the key message to always keep iterating on
that. 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 on, like, few key people in the companies that are seem to have the power to make decision. So why is it important for Tech executive to try to navigate and try to move Upstream to the
decision making Point? 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. Hang 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 until that easier to fix an issue to refactor our direction as 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 in 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. That 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 know about it, three months before, it's going to happen before, you're going to have those clients because it's on the road map. All of a sudden you can start acting we 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 in the team is already accustomed to it.
I don't know whatever, but if you are aware of it and you can think about it ahead of time, you can actually call the shots or be pardoned calling the shots. So they are most appropriate for your team and your team can deliver. The biggest impact just a little bit of a related discussion. So in Enterprise, typically, they are already like, how was already established, right? Maybe that's call it political. Equals power. So how would a new person navigate this political power.
If you have experienced working with such like establish and the price before, how would these people put himself in the decision-making table? Yeah, so I'm not gonna say that. It's going to be straightforward at every different organization was first of all, the shift to move, Upstream starts with yourself. You have to realize that despite Rumours saying with great power comes great responsibility and
the opposite is also true. 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 wanted politically you want to, because that's the
right way of managing stuff. And then you have to find the ways to move up in Israel. We say hutzpah, because we are okay with pushing ourselves where we think we should be. I'm finding it. The sometimes harder to hold my International clients. Understand that's a big part of
their role, but it is doable. For example, examples of hot spot that I'm helping my clients do is when we see that the end of the quarter is reaching and in 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 will go.
Over to the CEO and as 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's way of having the ability to sit in the business meetings. Not because we can't do it. But because they have become accustomed to detect, 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 you. Away, so you are in the meeting but it's going to happen 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 kind of a culture thing is going to be a problem as well.
So any take on that, especially if you have work with Asian culture before I would say that it always has to start work again. 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 is an SVP or an EVP above you and you wanna take part in some of the discussions. You have to help them realize what you're going to get from working with you.
Do you know the acronym with him? 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 you remember the last time that we missed the deadline because we realize something is too late. If I had known about it earlier. I could have done something else. So I just want to be take apart. 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 to don't want to do or stuff like that, that can lower the stress. But really, if there's something that's not straight forward is to position yourself in a place that has political games already happening.
That's something that I I think is maybe the hardest part for techies because we really good when I'm talking about tech execs, really good at attacking but we're not good at executive 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 gonna just say come on in to the
meeting by themselves. Sometimes you're gonna 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. Totally makes sense. Speaking about meetings. I know that Executives normally need to spend a lot of times in meetings, may be gathering contacts making decisions understanding about other priorities from Business Marketing sales, whatever that is.
So that makes it even more challenging for a new tech Executives. Coming in, how to balance the time. Where should they spend time or even by juggle between all these priorities? So, I have my rule of thumb about how much time you 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 and
some position. 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 11 meetings. Not just with your direct reports, but also with your colleagues and with skip level one or ones with the staff under you, even if you're not there.
Rex manager, because they think that you need to beginning that sort of insight 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, a non-covered world where we can actually walk in offices. It means Walking The Halls may be 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 hosel, 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 are handling things. And you can take 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 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 your block time on your calendar to think. And I know that sounds weird. 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 road map for the next quarter. Sometimes it can be stuff like investing in your own product Mastery. Maybe you're going to watch some gone. Yo, sales meetings. Maybe you're gonna see what customers are saying on Twitter, whatever and sometimes Actually thinking about big problems.
How should you, for example, a structure, your team going forward? That's 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 have to be putting out fires. You have this bar 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 locks 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 or 45 minutes. Maybe you can make it so that they are not. And each week but one, every two weeks that sort of stuff, so you can make more time for yourself. I like the way you use some of these geeky terms to explain what the executives. I think it's really refreshing. So I'm very interested about this thing called management by walking around during this covid.
How would Executives do such thing? 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 are in all 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. You see how people are handling and outage on. Line. 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 flying the room because you can be a friend, a zoom. I 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. You watch him. Sometimes if 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. You see others hogging the meetings that sort of stuff. It's more time consuming and it's not as fun as being in the 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 the He's q&a's, ask me any things 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 a ranked 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 is 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. Wow, so many great tips. I hope all of you listeners can try out some of these during this working from home, working remotely. Or so.
We miss that kind of connection with individuals or also missing this kind of huddle where 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 Give it a try and hopefully it can gain more context from the team. Speaking of the next thing which is about creating impact. Let's say, after 23 months in the world. You start to come up with a
plan, you start executing stuff. How do you think an executive attack executive should make an impact? Is there any strategy? How should they think about making an impact? Is that things to focus on? 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, the team, you have to invest in them. You have to help them grow. Your iterations are iterations on that team for enabling impact. You have to create the team that's oriented around that impact. So for example, I've mentioned, okay hours earlier. You should think about ways to create a connection, a direct connection between what your
team is doing. In the impact, it's going to have on the business. So I'm a bunch of companies. Nowadays are trying things that all around the Spotify model where you are working in squads. Each quad is end-to-end and you can do things and Charlie 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 squat and then the squad has to do that. They know that they all say 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 in person saying my API is working. It's ready, two weeks. Now, it's the front and who aren't ready by now.
No one cares. You're not going to call a client. Like the API is ready with just still working on the front, and no one cares about that. So you have to work together and creating these quads, who get these impact driven goals. You have an objective that allows them to create their own impact is amazing. For example, when I say 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 with that's very specifically
defined. I'm telling you exactly how to implement something. I'm telling you exactly what to do. You are not actually empowered. I'm not empowering you to do anything. I'm just telling you exactly what to do. Unfortunate you to be a gr. 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 turn go down a bit or stuff like that. Then that engineering manager with their 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 like the book empowered by Marty Kagan and he has other books like inspired that are really about this way. That product should be working and being developed in highly successful.
Teams, I like the way you mentioned by all these impact driven goals or impact Focus 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 okay. Are sometimes and I like the way that you mentioned that the tech Executives to play as a bridge, but I know changing the mindset is quite tricky.
What do you think are some of the technical things that an executive? Could do in order to change this kind of mindset for engineers. I say that. First of all, they have to have the product Master. You have to help them get the product Mastery because then they actually can think of other things that are not just attack. The reason we go forward, the texture of that, we obsess over detected, where 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 Product master. In once you understand the impact, your things have on the company on the customers. It's natural for you to start thinking about that. And, you know, it won't happen for 100% of your engineers, but enough 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 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 spring plans. I know that they have no stretch goals.
I know that they're 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 to deliver everything but once in a while to 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 fast. Forward because they take on some risks from time to time.
You can't be, you know, we can put all of our money and Bitcoin, but maybe we need to put some of it. That's the kind of thinking. And I think, when you say about stretch goals, sometimes this relates back to things Beyond, just the tasks for the features that the business is asking, right. It relates back to the tech Capital that you mentioned a relation back to our ND, you know, researching about new stuff in you either like, platform, tools and Technologies.
Where do you see RND in play for Tech Executives to Focus on. Yeah, so I say that we've become accustomed to already being treated as a cost center and 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 Rd, 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 become. An innovation Center where we can create. Such examples are like the tech Capital example use 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 help the company make money faster, generally help the company iterate on its product Market, fit faster. That's the And of innovations that sentence 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 are working 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 filled that point you have to use very heavy and costly workstations. That had these special gpus only to use that.
So, it's especially doctors had those in their offices and they had to use those in their office, next to the desk. We 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 us Company sell so much. Because those doctor 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 that the data has been updated.
I can check it no matter where I am in the clinic. You 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. The just had an idea and said, let's try to create an innovation Center. You have to create the space for Innovation you have Great.
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 Jura dashboard and do whatever. G ra says, they need to be doing today. 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 introduced.
This. RNG is a 20% rule or some kind of effect on maybe can Share a little bit from your experience Consulting, different companies. 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.
Base camp 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. Nor sabbatical weather team is in charge of doing what they want. I revered 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 that intermissions are actually about thinking sometimes it's about
tected. 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 were an entire Squad is working together
on something and 20% time. Is that 20% time is I decided 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 Code or no code tools.
So what you get done in the day is, like, what you would get done in a week. Of course, you can 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 code is Without Borders.
Think how valuable how enabling a week of a coders 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 with the might get done in a week and so a week of intermission can create so much innovation of the company and that's what I'm driving for. I really like this intermission concept and we can see all these new things that you put in this
episode. Who does 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 Do it. Sometimes. They can also teach the other division departments to actually learn about this, local no code, for example, and maybe they can, in fact, create more of it by themselves, which is a multiplier effect moving to the next topic which is about
organizational structure. I know that I've seen one good discussion point about organization depth. Again. This is a New Concept, right? I know about tech that now I know what a capital, but now we are talking about organizational debt. What do you mean by that? Yeah. So like you, we have code. Smells As an advisor, someone who's working with dozens of companies. I have started noticing organizational, smells.
Are you 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 gained some organizational debt because we can't refactor the organization every week. We have someone leave the company and that leaves 18. That's a bit too small. You're not gonna disband the team just because Someone left.
But let's say a quarter to half past, 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 front end. He is the Duke of back-end and you start explaining the entire organization between those titles 14th. 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 your 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 backhand and the tech lead for Mobile in the
tech lead for front-end. If you have those titles in a small organization, it means that let's say that you have the back and Tech lead and two months later. You hire someone who is a world-class expert at back end. Does that mean that they cannot voice their ideas that they can't take? Initiatives, because there's already the tech lead. Know, 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. Any idea of Team size that you have, maybe rule of thumb, like best practices that we've seen, my rule of thumb is usually to aim for something around six to eight people in a team. If you have a team, Of a team lead, that's relatedly new. You can aim for teams that are bit smaller tool, the team,
leave getting some experience. If you have a team that maybe with a manager that's very experienced or that 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. I also see this may be 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.
Alright. So again, what is your take about this, you know, spitting microservice, splitting team. Sometimes just spitting microservice, but the team stays the same. So what's your view on that? 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 product changes but you can't as easily refactor the team around it.
That is why I try and push toward teams where people don't take charge for a specific microserver. But take charge again for a specific business need. So it might be a business need to completely encapsulate 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 micro services 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 microservice, you too.
And 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, may be the problem. It tries to solve any other angles that you want them to actually Master about in terms of this product Mastery. 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 know. Not go into the organizational pigeonholing we talked about earlier. You also have to stop stress, technical mastered. 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 tackling 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 our quad rub elbows. Half. Action with the actual users with the actual business. So for example, have them be attending the QB ours, listen to sales calls on Kong or whatever tools you have, read up, what's going on in the market. When I work with my clients. I hope them set up this sort of a feed that the entire team can see maybe it's a select channel that has related articles.
Maybe it's an actual newsletter or something like that. That the executives and the managers start sending links. Two articles in the Wall Street Journal and The Economist about things that are related to the market, the company's working at. 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 wire. 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 with a shadow customer support and 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 change? 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 sort of stuff that even just noticing the language. Our users are using, you can realize, oh, I might need to change the little alert bubble that I have, because But 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 that 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 need how they act
and what they care about, 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 internal server errors or whatever that is. So another thing that you mentioned as an example is to come up with product one-on-one. And I think this is also sometimes Buffalo me or 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 of 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 Vicky 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? 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 going to start up, 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's Just have to throw 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, b2c indifferent, demography, 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 that 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. In some of these are things that are really changing. You can do these ones right in a week. He create a short article about it or 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 will say that you have to make sure that your onboarding is very fresh and updated and up-to-date. But also, I recommend having refreshes to these one-on-one sessions like every quarter. 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 Executives, 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 other context. It's sometimes a bit hard because some Engineers see and ever invite for a company-wide, whatever. And you're like, oh and other our 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 their contacts.
So, you might not be feeling like sitting through another resume, but 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. So related to this, actually, I saw one of your popular blog post, 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 Think we should maybe emphasize Less on principal Engineers or maybe staff technical Engineers. Whatever you call it m 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 post about this? Yeah. So first of all, I will say that I have no issue with having career letters 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 are promoting people when you're deciding, how your cultural 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 principle. 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, responsibilities 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 contact so that when you delegate something to that person that you directly maybe
as 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. I like that.
You emphasize asking the right questions because sometimes what happens Engineers just saw the maybe G record. Okay, this feature. Okay. Let me just do that. They don't really pass around like why you design it this way? Why the right thing is this way, or something like that? So I like the way that you emphasize asking the right questions. So I believe, 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, Up.
Normally I would ask all my guests to share their three technical leadership wisdom. So do you have the wisdom that you want to share with my listeners here? 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 code AS Without Borders mentality, so you 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 a capital that helps them. Not just create an Implement, whatever feature you have any road map. And lastly, if I may plug the book one last time? I think a good wisdom is to get a copy of my book.
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? Yeah. It's on Amazon. You can get it on paper backing and Kendall. And if you want to get a sample chapter, you can go to Tech executive operating system.com
and download a sample chapter. Great. I'll make sure to put it in the show notes. So, thanks again. I'll be for sharing all this. I'm sure many listeners, especially aspiring technique, Securities or Tech Executives themselves would benefit from some of the advice that you gave. 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, I'll be fine.
Thank you, and you had a great time. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show notes of this conversation on the episode page at technology. No, the death website. Including the full transcript interesting quotes, and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the show's mailing list on package. You know, that deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.