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.