Hi everyone. My name is Patrick you in, for
today's episode, we covered leadership in Tech, doesn't
matter whether you're a people manager or technical leader.
What you need is, those leadership skills, but which
ones are they? How do you get them in?
How do you grow into that position?
Starting out as a software engineer?
Joining me today is REO, Weinberger, who's a VP of R&D at
amplication and has over 150,000 students over at, you know, me
with this courses. I'll put all the links to
socials in the description below.
Check him out. And with that being said, enjoy
the episode. So you and I met actually, when
I was applying for a job at app Cam and you were in front of me,
when I did the interview you I was the interviewee and you were
the interviewer but was that already when you going to
transition to into engineering manager like what was your role
there back then. Cool.
So that's true. That's true.
You are an interview and I remember you, you know, in
highly Rock high regard. Basically I joined up cam
originally as a principal engineer.
For technical knowledge. Basically.
Yeah you know the goal was like app.
Come was a British company moved over to to Amsterdam like a lot
of other British companies Post brexit.
Yeah, wanted to set up Development Center with
engineers and product and all that.
And I was the first one to be hired in engineering with, with
some goal of hiring, you know, 10 12 Engineers over the first
year, that was kind of chill. Yeah.
And then later on things, skilled quite quickly and we
ended up with about 50 to 60 engineers in the first, in the
first one year. Yeah, consisting of both
full-time employees and contractors as well.
So yeah that's insane. That was not the original plan
but then I transitioned into a head of engineering role.
Yeah. For both the Amsterdam office
and the Cambridge office. Yeah.
Engineers in both sides. We're like a remote first.
Kind of minded company. Yeah?
What? Because I hear.
Principal engineer, I hear staff engineer, or I mean, front-end
and back-end are kind of obvious technology wise, but what is the
difference between like a principal engineer just regular
software developer? Okay, cool.
So I think this is a good point to say, it really differs per
company, you know, and I think it also depends on the size of
the company specifically for app Cam.
It was a it was a large company. It's been around for over 20
years, it's publicly, you know, traded into stock exchanges it,
you know? And it has it has a big Organ.
It's a big organization. Yeah, I would say that the
difference. So principal engineer for me is
an engineer who has some overarching knowledge over
certain discipline or disciplines.
Yeah, whether it be front-end back-end infrastructure, Cloud,
all that. And the idea is not to sit in
one team and work on a single product backlog and stuff like
that. The idea is to utilize the
knowledge to develop a practice, okay?
Whether you're for example, our front and practice, you know,
You want to hire 56 engineering teams and in the future,
obviously more than that, that's just the first year.
Then you want to have that person, you know, who's able to
make sure that that we follow best practices that enables
other Engineers to develop best practices, right?
So it should be an enabler. It should be somebody who's
technical the principal Engineers on like, you know,
engineering managers. For example, tend to be very
very technical. They can surgically dropped dive
into a problem. Mm-hmm.
And and their presence in solving, a problem is meant to
enable under Engineers grow as professionals so that they can
take over from that point. Yeah, but usually you know, my
experience from Principal engineer that does own as well.
For example where I worked the very surgical role supporting
role. Yeah they do sit down and write
code an experiment. You know if the business has a
big problem they need to solve like into zones case micro front
ends. Yeah they're one of the pioneers
of micro front ends its principal engineers.
That kind of LED this thing, experimented with things broke
things pipelines and then with the rest of the teams that this
Vision was developed, okay? So that's kind of the principal
engineer roll. It any bigger companies like
Amazon, Google and stuff, a principal role is like a guru.
It's like an absolute Guru. There is like a handful of those
in an entire company's. It really differs in depends on
the size of the company. Yeah, but their role is very
much like overarching, right? Making sure that an engineering
experiences in place and kind of Pioneering when it comes to the
best practices and you were new attack as well.
I also yeah yeah and in our case adapt cam it was a business
that's been running for a while and it was a digital
transformation project so there was a lot going on.
It was setting up a new development center.
Yeah it was getting into Amsterdam hiring the talent.
It was transitioning from a c-sharp dotnet kind of tech
stack into a more No, GS serverless AWS kubernetes
finding how to glue the two themes.
Like obviously we want to move away from the older Tech stack
but it exists. Yeah, I can we integrate, can we
do it? Smartly can we do it?
Neatly can we set up best practices as we do it or just do
it and, you know, forget about this practices but then the next
thing that joins is doing things differently.
I think that's kind of the role, you know?
Yeah. Yeah.
It's a, it's a hard thing. Do you think it's for everyone
like, because What I understood from what I have kind of grown
into. I started out as a junior didn't
have the title, but I very much had the experience of a junior,
and then you gain more and more control of what you're doing,
right? You don't focus on how you do
things, you focus on what you're doing and why you're doing.
And for me, personally, I figured out what the tech thing
is actually. Usually pretty simple because
you can boil it down, and it doesn't have to be that complex,
even though people make a complex, I think the most
complex systems are the ones people made it complex.
Because there's a very distinct niche in which you actually need
the complexity on a technical note, technical level.
And then for me, there's either you go more in depth which I
think the principal engineer role would kind of fit into, or
you go more High over right. You go into that management
position, the engineering manager role or what have you do
you see it that way, as well? That that principal engineer
would be, kind of more in depth, with regards to the technical
skills. Totally, I think, I think
principal Engineers are first and foremost.
There are technical people unlike engineering managers who
when they transition into management.
It's a new career. Yeah.
It is a new career like you become a junior exactly where as
principal engineers get to retain their day-to-day work and
and you know time spent on doing technical stuff.
Yeah, and you know it if it's for everyone it depends.
I mean you need to be a leader, it is a leadership role.
It's not a managerial role. Yeah, but it is a leadership
role. You need to know how to Convey
Concepts. You need to know how to argue
about stuff in a way that enables others to express their
opinions. That's very important.
You need to be able to dive deep and simplify if you're, if
you're a principal engineer or, you know, we can even take that
to more senior engineer roles and certain or staff engineer
roles and and it differs per company.
But you need to have the ability to, you know, add picking up a
ticket on jira and developing an interface or an API.
These are things that are more common but when your company is
tries to solve something that Hasn't been solved yet?
Yeah like how to do distributed module Federation or how to
introduce micro front ends in a way that wouldn't affect the
user experience or minimize impact on user experience.
These are things that require not just an extremely high level
of expertise in the ability to convey Concepts.
Clearly it's also like what do we do next, right?
We have this thing, we can discuss it.
You really want good opinions from Engineers, you need to make
sure they understand it for them to understand it.
You need to know how to convey these Concepts.
Loop right? Yeah.
And then how do we adopt it? Which team should logically go
first because technically, it's simpler.
Right? What language is should we use
to solve a specific problem? Like how do you go on the one
hand, you have the bias of Engineers.
I want to write golang like I've heard this in every team ever
because go long apparently is a fun language.
Yeah. But then you consider the vision
of the company and the technical challenges it needs to solve to
achieve that Vision as a leader in Tech, whether it's again,
principal Staff and Stuff. These are some of the
considerations you need to take into account but you're a
technical person. Check To form of Equestria.
Now that makes sense, man. It it's a lot that's already on
a plate of an engineer, right? When it comes to a front-end
back-end technology, full stack or Cloud.
Also, what have you with regards to Security in testing but it's
a full plate and then you have that principle engineering role
which you described is also more of a leadership role right?
Making a safe space for other to speak up and then being a
Visionary of where new technology will bring us.
And if this is the right technology for the company,
right? Even that business understanding
needs to be there before you can be Give but we talked in the
pre-show or actually a previous conversation and like me, you're
not very much a reader. Right?
I don't consider myself a reader.
I like to listen. That's also the reason why I
listen to podcasts and do one. But how did you cultivate those
skills? Like is it a lot of
experimentation for you? You have good guidance and
leadership in your past. Like how did you add you gain
that knowledge first and foremost and then even though
skills? Okay, cool.
So yeah, I'm not a reader. I just agh ADHD is a bit of a
struggle. I do read on Wikipedia though, a
lot, but by reading a book is a bit tough for me.
I started as just a software engineer, right?
I mean, my first job was a front end developer with angularjs and
I transition to angular. Yeah.
And I started working at doesn't on where I, you know, I I became
a singer, front-end engineer. I really wanted to transition to
the back end because scale, you know, millions of daily users
was really attractive to me. I got heavily involved.
I spent some time in the developer experience team at the
zoning. The platform, not in, I got to
touch everything. I mean, I'm self-taught.
So I don't have a degree in computer science or anything.
I just really loved creating stuff.
Yeah, but I also got bored very quickly, okay, so you know, I
learned HTML and CSS and then that kind of got kind of boring.
How can I make it more attractive?
I learn JavaScript or interactive.
Rather. I want to make my front and flow
easier so I learned real Act or you know I want to I want to be
able to develop back-end services that will scale without
me having to worry about it. Yeah and for my team to own it.
So we went more towards the serverless kind of thing and I
just really liked learning stuff when they're useful.
Yeah, for the job. I'm trying to, you know, for the
task, I'm trying to solve. Yeah, with regards to the
leadership aspects, I don't know.
I guess I was always like whenever I was in a team.
I don't know, product managers used to tell me that I'm a very
product minded engineer, okay? And that they can talk to me
about the customers needs. And I did see that there is a
tendency for engineers to look for a like roller coasters.
You know, like now we shouldn't go for typescript because it's,
you know, it's we need to stick stick to bare metal and I don't
know, things like we should write, which we test absolutely
everything. And I just, I just liked
focusing on delivery on one hand and understanding that
developing code. An evolution and, you know, or
an evolutionary process, rather. Yeah, you do something today in
two weeks, you'll do something else you will.
You will naturally acquire some tech debt and I always kind of
liked the balance and I and I don't know.
I always when we had team conversations and stuff like
that, I liked focusing on what matters.
Yeah. And not unlike all these
discussions of should we have t, eslint ignore lines and text,
like great conversations, but I always like focusing on the
higher level. And I guess that kind of helped
me develop those leadership skills.
I always liked, you know, transmitting knowledge to people
and educating when I was at the Zone.
We had, you know, hack your future.
I don't know if you know that organization know, basically,
refugees people with Refugee background from from Syria, from
Iraq, from from other countries, who came to over to the
Netherlands, hacker future, trains them to become software
engineers and then they get an internship at companies.
In the Netherlands and in other places around the world and when
EV the head of people at the Zone told me that that, you
know, we might join this this program and Mentor them.
I was like I want to do that, you know.
Yes, I always jump in for mentorship.
That's something I absolutely love.
I love being mentored as well. I have a mentor.
I've had one for over a year now and I'm looking forward to their
sessions. I really believe in mentorship.
Yeah. And that it's just not possible
that we know everything exactly. And even if we think we know
something, let's hear somebody else because if somebody tells
you something and you're in the same thing with them and you
know you maybe they're your ex colleague or your manager or
whatever. Even if you don't agree with
100% of what they say, there's no chance that you disagree with
100% of what they say. Like some of what they say must
be true. Yeah, to some extent I think at
least hearing it even though you think you disagree like remove
that bias. These are the things that I was
actively seeking. Okay.
As an engineer, because I saw bias.
In teams that I was a part of and that was a productivity
killer. Yeah, I recognize a lot of
myself in what you said, when it comes to wanting, to be
effective in, whatever we're doing, right?
If that's delivering a product to a client, obviously you want
to deliver the best product but also it needs to match whatever
the client wants, right? And if we can build a really
cool technical feature, but no one's going to use it.
I'll be the first one to say, do we actually need this?
Because I don't think anyone's going to use it but not every
engineer is like that. So I recognize Is that it takes
a certain perspective and I think a certain I don't know way
I think it's interest or curiosity rather that you can
use to, I don't know, have a insights in that your goal needs
to be not just to write code because I have the most
beautiful code. You need to make it your goal.
Also needs to be help the other team.
Yeah, you know, unblock there depends.
If you're that dependency help other teammates find solutions
to their problems, their own stuff.
Improve processes, make your pipelines faster.
The For faster, right list tests, but deliver high-quality
software, you know, you need to find those things that will
ultimately benefit the business and not just the code that you
put on GitHub. Exactly, like code is, is one of
the things that don't quite matter, as much as other things,
when you get into leadership. Yeah, exactly.
The Ritz management or principal engineer or whatever it is.
Yeah, it doesn't doesn't matter at the end, but I mean, I
recognize also what you said when you get kind of bored for
from a certain technology, you will move on to Something new
right learned that kind of unknown thing.
And at some point you're like, okay I'm comfortable in that and
then you move on to the next one as well.
I kind of see it as like a you go from zero to 100.
I'll never get to that 100%. I don't think I will get to,
like, 60 70 when I'm comfortable, and I'll move on.
And when I really need that last 30% of knowledge, I know exactly
who to bring in because I know that they that's that thing
right there. Either a master in front-end or
back-end or when it comes to infrastructure platform, I'll
bring those guys in. That's exactly that.
Yeah, I'm doing it these days. I really.
Yeah. Because what's your role
currently then is it still principal engineer or have you
moved on since I saw some VP R&D at a startup called amplication?
Basically, what we do is we want to change the way Engineers
developed software, or the way software is developed.
What we do is wear platform where you basically design your
systems and your software and microservices or model it, so
whatever you like. Yeah.
With a nice cloud-based. You I wear open source as well
by the way. So fully open source, fully open
and we save you a lot of time, like when you want to bootstrap
a new micro services are or new application, you can use
amplication to, you know, set up your entities set up your
permissions, your authentication authorization, you know, you can
configure Kafka and configure redis and configure postgres and
whatever database you like and customize it to your needs and
will generate code for you. Yeah.
So you own the code we're not like a cloud service where you
were going to deploy your code. With us.
But we're going to make your life easier and trust me, I've
had conversations with companies that spent years trying to do a
tiny portion of that and that cost a million.
So it's pretty cool. Like I've been using it myself
for a while and you can't you just move so quickly.
And yes our motto is code. What matters?
Nice other than boilerplate? Yeah.
Like that a lot. I'll check it out after.
But you have to the role of would say VP of R&D.
Yeah. Is that still is it like a
managerial role? Or is it like a technical
related? Leadership role.
What is that? So, it's a managerial role.
Yeah. We're a very small right now.
So, you know about 16 16 people? Yeah.
So in my role, I report to the CEO and I'm basically in charge
of the of, the R&D organization that's like, engineering.
How do we, you know, what technologies do we use?
How do we set up our engineering teams to deliver our product?
We need one team, do we need three?
Yeah. What kind of skills do we need
to have in the team? You know, helping teams figure
out best practices. I think at this stage of the
company, it's a it's very like flat right.
So I'm with the team every day all day and I do get to code a
tiny bit which is nice. Yeah.
But yeah. You know, my goal is to set up
the organization for success and growth because if things keep
going the way they go up, will likely grow and need to hire
more folks in and I want to make sure we have a solid core.
We have good practices, we're very Ryu, no visible outwards.
You're an open-source company. We gently generate code for
companies and we got to make sure, you know, we take that
responsibility seriously and do it, right?
Yeah. Interesting.
Because I'll be, I'll be honest with you when I met you for the
first time, we were in a kind of engine interview session and
obviously you ask questions of the things that you expect me to
know, but if I didn't know, I would just be honest and say
that and you would explain it to me in such a simple way and it
didn't matter if it was front end back end when it comes to
in. Of structure, whether code
actually runs on right, Docker kubernetes.
I figured you would know it and you could explain it in a very
simple way. So, when you mention you've
moved on to kind of a managerial position, that's quite
interesting because I did not expect you to do that.
I've obviously our first meeting was very brief, but I thought
you were one of those like, real technical guys back.
Then why why did you transition or how did you transition?
I'm I'm assuming it was a napkin since you mentioned, you be kind
of became head of engineering there.
Yeah. So I was actually an engineering
manager before up cam at a company that you might know
called one fit. The moment one fit is, is some
some fitness-related solution in the Netherlands.
I was an engineering manager there, and it kind of took
leadership of the process of pivoting during covid as well.
So that was my first managerial experience was a fantastic
project by the way, but then I, I did think that I want to get
into a more, like, technical role and that's why my next roll
it up. Wasn't more principal engineer
rule. Yeah.
And you know, the circumstances were such that we need to grow
to deliver what we need to deliver.
Yeah, and naturally, I became head of engineering.
I mean, I was, you know, I was I was up for that I like working
with people. I like having a close
relationship with people like talking to people.
Yeah, I really believe in this thing called called people, you
know? Because if we don't have people
in, I mean that's not that's not going to work.
So teams, how do you, you know, I had some, I had some important
Vision there about micro front-ends microservices, that's
exactly what we did, which was very technical on one hand, but
on the other hand, you were going to make sure you have the
right people and exactly the company you got to make sure you
have the right leaders as well. So I was totally after that, for
the head of engineering rule, it did get me farther than I had
hoped from from coding. But in my current role, And
that's something, you know, and that's where I mean.
What what I mean when I say it differs per company.
Yeah, I know that for a long time where I am now I'm going to
get to be very technical and to the level that I want to be I
like experimenting with stuff right over the past two weeks.
I've spent my free time and in between trying to figure out how
can I get the engineers to be like, super productive?
Yeah, and developed directly on the cloud.
Like, this is something. This is the kind of stuff.
I'm passionate about. I don't think it's right for me
to go and pick up like a task and block the entire Team
because there is a dependency on some release.
I don't have, I don't have the time for that.
So I'm trying to figure out where can I use?
Like kind of my higher level overview and bird's eye view of
things without blocking Engineers yet, giving them value
in. Making them more productive,
helping them with decisions. So, yeah, not quite coding.
But I like that, I like having impact on people and I like
learning from people, really cool?
Yeah, really cool. You're still an enabler but on a
very technical level in that way.
Yeah, that's really cool to hear.
So I want to go back to the hiring process because you said,
you skilled the team from it was expected to be, like, 15 people
or two teams into a, in a very short time into a team of like,
50 or 60. I don't know the exact numbers,
but even you were hiring to me was very different.
Cause obviously, I was on the other side of the thing, we had
one conversation and then we had a conversation, it was kind of a
live coding session, but I didn't really feel, how do you
say that? I don't look forward to life
coaching sessions, I think they're very intimidating.
Once it's on the other end and I've seen like stuff on YouTube
which is appalling where people just get roasted and they're
like, you don't get it. It's supposed to go like this
and you're like, well, this also works and then they still don't
agree. But you take was very, very
different. Was that the only two rounds or
did you do three rounds? What's your take on that with
coding? Probably won round one round,
right? So my take on coding.
Is that the code that you're right?
Yeah. Is actually like I don't know.
30% of the interview. Yeah.
I do think it's important that Engineers will know how to code,
but you know, when your interview there's stress
involved, maybe I'm, you know, coincidentally, I'm asking you
something that you just forgot. I mean, this happens.
You're not a robot. Yeah, so my focus on hiring
that's also, you know what? I communicated back to the
hiring team as well as the team grew the code matters, but not
that much. What kind of questions?
Do you ask right? How curious.
Are you how collaborative are you?
I will never ask you a coding. Expecting a specific answer
because that's bad because I want to hire a good engineer.
You're not an engineer. Who knows specifically that
specific answer that I asked like a trick?
Exactly. I mean, my point is to set you
up for Success. Yeah.
Right. And I want to get the best
version of you as a candidate and I want you to feel
comfortable and that's always what I told people during
interviews. I don't care if the code is
going to run, I'm not even gonna run it.
Yeah, I want to see how you think I want to see, like,
what's automatic for you. How do you do speaking?
Cup your thoughts. What kind of questions do you
ask? How do you solve a problem
basically right? Yeah because that's what we do.
I mean we solve problems Cody's is a tiny bit of it.
What about documentation? What about priorities?
What about dependency management?
Right? Yeah, asking that your product
manager questions to understand the user better.
These are the kind of things that I like putting focus on.
I think it's quite easy to understand.
If somebody knows how to code. Yeah, yeah, yet no one.
Does it like that? I mean, I've done a lot of
interviews because I sucked at it and I wanted to get better,
so just for the sake of interviewing, I sometimes, And
especially at the beginning because manned the idea of
someone sitting in front of me and judging whatever I'm saying,
right? If it's a tell me about yourself
or if it's a coding question and I don't know it.
It didn't, it didn't feel good. So to get more comfortable with
that, I might not even have gotten better in each of you,
and I just got more comfortable, I would do interviews, but very
much, the technical interviews would be kind of confronting to
me, and everyone, I mean, if you look at the biggest companies,
right? They have multiple rounds of
either. Interviewing you don't even get
to talk to a person. Sometimes you get like a hacker
rank kind of thing you have to do and then afterwards, you
either get rejected by some automated system or Then you get
to talk to someone and then still, you have to do a
whiteboard session or like a system design thing.
It's so many rounds, very much technical.
No one asks those questions that you ask like, even do you
challenge the product owner? Or what do you think of
dependency management or how do you collaborate that usually
doesn't come as much the Forefront as I think it should.
Yeah, exactly. That's because I know that
people can learn how to code if you, if you, if you're a
fantastic engineers and you've been working with, I don't know,
coddling or Java for the past seven years.
And you know how to design scalable microservices yeah.
Using a denote tools that we use like Kafka and rabbitmq and AWS.
It doesn't make sense to ask you questions about node that you
would lice likely don't know. Yeah, that's not the value.
I would get from you, you can learn node, you can learn
JavaScript in in a few weeks, if you're solid engineering and I
don't want to set you up for failure, and let me tell you
something funny, actually, when I joined the zone, It's exactly
when they came over from from the UK as well.
Yeah, I think it was the engineer that the 13th engineer
in Amsterdam and the hiring gold for that year was 120, Engineers
for year. The right, that's crazy.
That was huge and it happened, really?
Yeah. It was, it was insane like
that's legit hyper hyper growth, I guess and we all got training
on how to hire people. We got it.
Bye-bye, again EV she was the head of people.
She was shared a senior people role in booking.com before and
like I remember it as one of the most impactful trainings I've
had. Yeah, like, can you compensate
for hard skills? Yes.
Like lack of hard skills. Absolutely.
I would rather hire somebody with with, you know, slightly
average or above-average hard skills.
But excellent soft skills. Yeah, that was like, I remember
a specific chart that you drew, which is like, you know, hard
skills, really soft skills and what's easier to compensate and
what we want. And that was very impactful for
me. And you know before I joined the
Zone I had a very Very technical hiring process.
It was super technical, very deep dive, very Cody, super fun.
I have to say, like a lot of, you know, you saw something and
then you get another constraint and another constraint, and how
do you hash it? And how do you make it more
efficient? And yeah, it goes deep.
I just happen to know the answers, okay, to get the job.
But then, when I started hiring and I saw the question Bank.
Yeah. I was like, I don't know 80% of
that. Really?
I felt so lucky. Yeah.
And that's the place where, you know, I was super productive
there, a lot of letter, A lot of initiatives there.
I was really, really productive there and learned a lot but I
could, you know, if somebody else would ask me a different
question. Yeah, pretty sure I wouldn't get
the job. Interesting, pretty sure I
wouldn't get a job because the question is there like some of
them were really tough? Yeah, right.
And they were all like labeled as senior engineer role you know
questions. So that's that's what I mean by
that and I did take a lot of good stuff from the hiring
process there. But what I didn't take is like
these very specific question. Yeah, there are looking for
specific answers. I don't think he tells us much
about engineers. Yeah, yeah, I agree.
I'm wondering what what it's going to Trend towards I think
now. I mean first, it was a hiring
boom, right. Because the salaries went up
people, transitioning left and right.
People, that could hire. The fastest probably also got a
lot of people, the fastest. Now there's happening.
It's happening that people are getting laid off more.
I'm seeing on LinkedIn posts of several engineers at beer
companies being laid off. So, I don't know.
The hiring process is going to evolve.
But what I get when I get into is when you scale a team from
that, say 10 people to 100 people, or even 50, this going
to be a lot of growth pains. Now, that's what I would assume.
What would I do? What have you seen kind of with
regards to growth pains? And how do you make sure people
stay effective. So I've seen that happening at
the Zone. Yeah, I think it was managed in
a not so bad way. I've been, you know, I don't
remember exactly details but it was I remember that.
You know, when I joined the Zone, Artie, Team split three
times. Mmm.
So I think that was managed pretty well.
You know, the team became too big.
Yeah, people became dependencies of each other and the decision
was very quick to split in the display it again and the split
always kind of makes sense to me.
Okay, so that was good. But with app can specifically,
we had some challenges because some of the engineers were in
Cambridge. Yeah.
Really valued those engineers and we didn't want to, you know,
they were they only knew C sharp.
So a part of it was like time for training.
They need Upscale some of them had great leadership, you know,
qualities that he wouldn't. We want to keep them right?
And use their leadership skills. They can learn how to code in
JavaScript, that's fine. Yeah, and then in Amsterdam as
well, I think my focus based on what I saw, you know before, is
that how do we retain that DNA that we have, like, we're at a
luxury? This very early stage of, like,
one person basically of cherry-picking the people that
we want to have, you know, we paid very decently which kind of
helps Soooo and I my focus was on finding the rock stars.
Okay, I knew some folks from my past jobs and stuff like that, I
managed to identify with in-app. Calm some of the existing
handful of Engineers, one or two rock stars that are just have
this amazing can do mindset, you know, can kind of roll up their
sleeves, you know, if you got to do kubernetes, then you will do
it. If you got to do micro services
and know, you'll do. Yeah, it was really, you know,
identifying this core that I think represent what I want this
organization to be and what I want the interview process to
feel like four people. I want, I want them to whether
they got the job or not to leave thinking.
Wow, that was fun. Yeah, that was different.
So it was hard, identifying, those and hiring those.
But once we got those and that's also what I'm doing in my
current job, right? Yeah, I'm telling I'm telling my
folks guys, you can code Great. But that's not what I meant.
What's going to make us successful a successful team?
Yeah. It's how you communicate.
Its how do you resolve dependencies?
How bias for action one of the most important things for me.
There's something just do it. Yeah, of course, not everything
is like the tile so many times I've seen in places like a small
thing. Just a low-hanging fruit.
Just pick up that fruit solve the problem.
Yeah. And and you know, earn your
Champion points out exactly. Yeah, identifying this this
corset of people made scaling so Easier, you know, we were
aligned on, microservices micro front ends, the Technologies we
use we actually never documented the set of Technologies we use
because we were so aligned. Yeah, that we didn't have to do
that interest, everybody was using typescript.
Everybody was using service. Not that.
I'm saying that necessarily technically, it's right, or
wrong. Yeah.
But the level of alignment there was so solid.
It was very, it was like a Harmony and then these people
became the leaders of their squads and and I think you know,
that's kind of my focus today as well.
I want to make sure that the core is super strong because
when we hire 20 30 more people and we need to have that strong
core. Otherwise we're going to have
like some DNA disruptions and and it's going to feel a bit
clunky and I want to keep that like yeah solid.
Yeah that makes sense. I love that you said DNA because
that's I think I think that would be one of the best answers
that I've seen. I'm a consultant right now.
So I jump from Team to team and I talk to colleagues, also do
that and when there's a In a mismatch or you'll notice it.
You'll be like their mindset is just completely different.
In their perspective is is so opposed to mine that we just
don't match, right? There's a DNA mismatch there.
So if you, make sure your core is solid, right?
If that DNA is the same, then it will also spread out and they
will seek the same mindset of people in that way and I think
you kind of constrain your growth pains in that way which
is really cool in that way as well.
And it's easier, if you accept the fact that people will make
mistakes Yeah because I've also seen places where you know, you
have the title of a manager and on paper you have the
responsibilities of a manager but if your manager doesn't like
exactly what you're doing, yeah, it just makes the process so
much more tiring, so you hire people for who they are.
You know, you understand that there are good Engineers.
You understand that? Their thoughts are different,
and their background is different.
And as a manager and also senior manager, you need to know really
well, what are my core most important things that I don't
compromise on? Yeah.
And what are things that I just let my people, you know, do
their thing. Perhaps be super successful,
perhaps make mistakes, but I'm going to hire the right people,
if they failed at something, they can just learn from it and
share the knowledge. Yeah, because if you, if you try
to Shield people from making mistakes, I mean, humans don't
scale. And as a senior manager who's
micromanaging others, you're not gonna have a great time, you
know. Exactly.
But are going to be angry things are just not going to work.
Yeah. Yeah.
That makes sense. I mean, when it comes to making
mistakes, I I am trying to write more on LinkedIn and stuff.
So, I was writing this on the train, but I remember very
distinctly when I was on operations, I did the worst
thing you can do which is basically make a huge mess from
production and I knew it happened.
I was trying to solve it as quickly as I could before
someone noticed it. But obviously, someone was
running standby, and they immediately got an alert on
their phone. They called me.
And they said, was what happened?
And I explained it to them, and they were very chill about it,
will come fix it and I'll, I'll walk to your, to your desk in a
bit. And, basically, I was going
through all the scenarios when it went.
When I was like, okay. Is this how I get fired?
Because I was very Junior. Was my first year.
Am I going to get less responsibilities?
Or more shackles? I don't like the idea of that or
the sound of that and they came and they said well it's fixed
will. I'll schedule a meeting and
we'll go through what I did. So you can learn from that as
well. And then when he was walking
away and I was like is that it like is they're not going to be
any form of punishment. They like don't be ridiculous,
man, everyone makes mistakes. And then you share directly
story and then he pointed Get out a colleague and they shared
their story and man it was such a relief like looking back.
I'm really happy. I was in an environment where it
was safe to make mistakes because everyone does it right
now that I'm a few more years into it.
I've seen so many mistakes I've made so many mistakes and how
you pick up and recover from that and learn from that.
That's him. Incredibly important and not
just learning from that when when my team makes mistakes II
pushed them to tell others. Out it then they grow from it.
Yeah. They become better, you know,
Educators or the communicators and I'm like how can we
capitalize on that mistake? Yeah.
And take it as a topic that they're going to talk for half
an hour and you explain what happened and how what can we do?
So that doesn't happen again, let's reverse this thing.
Alright, mistake happen, like there's nothing we can do about
it. Now, let's at least grow from
it. Not just as an individual not
just as like a one-on-one feedback.
Now that's fine man. Yeah.
How can the rest of the team? Understand this mistake can
happen to any of them? Yeah and that it's no big deal
but just know what to do. So that it doesn't happen again.
I really like that. That's a way for them to teach
them to pay it forward, right? That's an Air Force mindset.
Is that? Yeah.
Investigate a lot but yeah, like I had when I was a deer for
somebody left, snack bag in an airplane, okay?
And that's like in Air Force terms.
It's terrible. It can, you know, get sucked
into stuff. Yeah.
Like, you know, some some bags, have some aluminum in them and
this can be, this is conductive. Sometimes and you just don't,
you know, you want to be sterile, you don't want to ever
leave anything behind. Yeah, just took all of us with
the big screen, the explained, what happened?
Who did it? And the person who did it
explained? What are the potential risks?
Yeah. Even if it takes you to the
extreme of like an airplane crash and stuff, of course,
that's a variation. That's not just Air Force.
But yeah, I mean, it's not, it's not investigating and sharing
for the sake of humiliating. Someone, yeah, it's for the sake
of growth. Yeah, I really like that.
That's that's the The best thing you can do grow from it, not
just as an individual, but as a collective, right?
I think I really got lucky when when I was in their environment
because I've I'm on Reddit sometimes on like programmer,
subreddits and stuff. And I see people just absolutely
get flamed when it happens. And I'm like, man, that is not a
good environment to be in especially very early on in
Korea, right? When you early on in your
career, you want to have a safe environment, you want to have
the room to make mistakes and you want to have good guidance
and mentorship as well. Now, That's why hiring the
right? Managers isn't exactly what you
get to pick your manager. Also, I think people sometimes
forget that hiring is the two-way, right?
If it's not a good fit from the interviewees perspective, just
be like, well I don't want to take this job right now,
totally, it's choosing the because there's going to be key
people in and around your career along along your journey and you
need to make sure that the right people as well for you and for
your career, when just to step back, when we're talking about
growth, You mentioned your team naturally split, right?
And you said that. I felt that it was a good split,
but what kind of support are we talking?
Is that like a domain? Is it like a technology because
I've seen different teams function in different ways.
And what I really don't like is the technology split.
So I think I was very lucky there.
So the first to hire as a napkin Amsterdam where myself and
Harris you came from Google. It was our VP of product
basically. Yeah.
And you know, here's here's like all So, an advice for managers
become best friends with your with your product, folks in your
product managers because you're, you know, you're not just an
engineer coding anymore. You have to understand the
product we do well and I think that early relationships that
we've built helped us understand what are things going to
possibly look like in three, four, five months.
Yeah, domains right order. Capturing order resolution.
These are like domains that we had we put them under one
umbrella, two teams, right? Yeah, searching things.
The whole search domain for for Life Sciences, crazy, the whole
kind of landing pages and promotion.
Things like we managed to identify those domains business,
domains patterns deployables, right?
And that's kind of how we split the teams and have to say,
that's one of the smoothest team splittings that I've ever faced.
Okay? Because product managers were
not scared of, you know, when a team splits like what happens
with product manager, right? Do I get this team, do I get the
other thing? I like that kind of ego did not
exist. Okay, which was great.
So I wouldn't say it was you know, I cannot just go and say,
hey folks, we split the teams because you know, we need to
have some, some Q&A resources there.
Yeah. Who's gonna lead that team is
the potential leader that I have in mind?
As does? Do they have a good connection
with with the product manager? Can they work well together?
Yeah, is the product manager proficient in their domain.
That's more of like a high risks or VP.
Kind of question to answer. Yeah, I think being able to
tackle that together and you know bring engineering and
product together, really made it easy.
So yeah, that that the teams were split into business
domains. Yeah, independently.
Deployable microservices, micro front ends.
All of them were using like, next GS and react and
serverless, and some of them were running on containers as
well, when it makes sense. Yeah.
But in practice, I mean, if, if there would be a problem, that
is like absolutely solvable using a specific, Vic language,
I'd be down for that, but you'll have to convince me.
Yeah, you'd have to convince me because what I don't want to
have is, you know, this can be solved with go.
So we do it in God, it's going to give us like maybe one point
two times faster, you know, execution speed but then you're
the only one who knows go. Yeah.
And you might go that's that's a funny but you know, you might
not be here. Yeah.
Next year or in half year and I won this thing to live like my
success as an engineering. Major is about developing
scalable and maintainable systems.
That would continue serving the business the scale and people
will come and go and people should be able to switch around
and that's just easier when you use common Technologies.
Yeah, exactly. When you're aligned in a tech,
right, it's not just an amalgamation of whatever it
wants to try out at serverless. For example, we were using go
for something very, very specific because execution speed
was one of the our most important success metrics and
the business new that we are ready to Invest to invest in
folks, knowing this so that we are able to maintain this
because that will be our Competitive Edge.
Yeah. Some of it.
Right. That's really cool.
It really depends on the on the business that you're in.
Yeah, that makes sense. I'm really happy.
You said the domain split because, whatever what I've seen
is, when you want a dedicated team, they need a clear goal,
right? And I need to have ownership
over the whole process. Oh, yeah.
If their ownership is not there, if they're their end station is
like a we put on test, then there's this empty kind of
thing. That is not fulfilled for them
because they What does it matter, right?
Because then weeks down end, they'll hear all your features
life and he'll be like, I've already moved on since then.
Like, it's gone for me. Engineering teams.
Must be. You know, owners of their
domain. Yeah.
If they cannot own their domain, then perhaps we're over
splitting because somebody said it's like a to Pizza team and we
must split because, you know, that's the Amazon ruler
something. They must own their domain.
Yeah, they must understand the product, they need to understand
like what's on the road map. They need to spend time with the
designer or designers, they need to do all the triaging and Three
Amigos and all those sessions to understand how is the user going
to use this thing. Yeah.
How do we test it? Is it right?
For unit? Testing is right for end-to-end,
testing. I like it when Engineers do
automation, as well. What kind of infrastructure do
we need for this? But I don't want to have, is
Engineers creating a task on jira for some platform
infrastructure team that has to wait for three weeks.
Yeah, let's go on to the terraform code and set up the
database, and if you don't know, To do that and I'll help you or
with somebody who knows how to deal with you leather next time,
you know how to do it. Yeah.
Because that's how teams move fast.
Like, I've worked for it. Strange for me to imagine that
but like, front end and back in teams.
This is something that used to be pretty popular in a few years
ago. Absolutely.
How did this even work? Did it did it even work?
I guess I don't know and it evolved I feel like yeah I mean
you gotta own your stuff and it have come for example of had an
engineering enablement team because I did acknowledge that
some things are like tight dependencies, right?
Like a UI library for us to share across our front end.
Great, let's put one or two folks.
There, who are passionate about you?
I would do a great job are. Great communicators can can
understand the needs of the teams and help them work on UI
libraries, and I will do some rotation as well.
So that everybody gets to contribute that UI libraries on
a bi-weekly basis. It would swap.
And yeah, I mean ownership you got to be able to take something
into and deploy it and maintain it as a team.
Otherwise I don't know. I've not seen it working another
way as effectively. Yeah.
I agree as one of the final
thoughts. I have is so for engineers that
are Engineers, now that I have aspirations to go into that
leadership role either technical, technical or
managerial, because I think I fit into that category myself.
I was talking to you before the show.
If I were to jump in, let's say in an engineering manager role,
my role would completely shift, right?
I would have no clue what I would do day-to-day.
Sure? I have some form of vision, but
I'm 100% sure it would be misaligned with the people.
I would actually be managing. What are some what is some
advice you would give in to people that have those
aspirations? So they can already have like a
little dabble in that and it doesn't have to be a plunge and
sink or swim. So again I have not read any
leadership books but I'm going to try to give my advice based
on What I did to get into leadership.
Yeah, but also what I would expect from from leaders in my
team. First of all, regardless of
that, if you have a manager that you appreciate try to identify
what you appreciate about them, I can say, you know, gladly say
I've never had a terrible manager, okay.
Every single one of my managers, I loved a lot about them very
different things. By the way, in every one of
them, but I also didn't like some things about them.
And I think you understanding and analyzing, what do I want to
take from this person in this manager and what do I not want
to take from this person? A great practice to have
secondly, ask them to delegate some tasks to you.
I've always asked my managers when I wasn't sure, if I want to
go into leadership, technical leadership management.
I asked them. Can you let me do something?
That's like non-confidential that's going to help you because
the best leaders they help take off weight from their leaders
and they do it by earning trust and being accountable and being
responsible and being able to you know, have bias for action
and just drive change. So I wanted to prove and prove
Myself as well, right? That I'm I'm kind of made of
that material. Who can my manager will be like,
wow, like I just got a lot more free time to take care of other
problems. Because, yeah, this person this
person took leadership of an ownership of some process,
right? In terms of you think it's
obviously Engineers, always look for the next step, right?
And after you're a senior engineer, depending on the
organization, you could go staff.
Principal, you know, engineering manager, I would say, It's not
like a ladder that you have to go through, all right?
So for either role, whether you're going for technical
leadership or people management, you need to be a leader.
Yeah and that's something that is important.
Now not everybody knows if they're our leader, right?
Some, it's that certainly something that can be developed
like some of the best leaders I've worked with.
We're not like naturally born this way.
I certainly wasn't like I really wasn't a as a child, I was not.
Yeah. I was like the last person to be
picked for football also because I was terrible at You know, but
you gotta understand it going for management you.
It's a new career. Yeah.
Like you you need to know how to work with people.
You need to learn that it's like you don't open you go to the
office every day for years and you open vs code and code as a
manager. You don't do that.
Yeah, you need to remember their problems.
You need to be very organized. You need to know how to be sorry
for the term, but a shit umbrella.
Yeah, because there is a lot of shit going on in an organization
and you want to Shield your teens from that shit so they can
focus and be productive, right? And these are things that people
often think, wow, my next step is a manager.
I love my manager. I want to be like that.
You need to understand if that's right for you and but I'm not
saying that to scare anyone but it's a different career path.
And you know, on the other hand technical leadership.
Yeah, you gotta have the ability, you're going to have
folks who are super talented with you very technical,
somebody might join your company and he's done things that are in
greater than what you've done from a technical perspective.
But you know, you were the leader.
And on the one hand, you want to know how to listen to people on
the other hand, you know, you're gonna know how to deal with like
bias personality. Sometimes people have something
against a certain technology. An done are like a very, very
vocal people or just people who know how to argue really well,
but don't know anything about that technology.
Like, You got to know how to lead and how to get buy-ins from
people. He has a leader like that, super
important as an organization grows, you gotta know how to get
buy-in from people. If you want to introduce a
change. You want to do it in a way that
people even though they might not always agree with it, they
feel safe around it. You feel like it's going to
bring the company in the team to a more like productive place.
And I think that's kind of their common things between people
management. And Technical leadership is, you
got to be a leader, you got identify the stars, you get to
help those who need help, identify those who need help.
Make the right decisions. Know when is the right time to
do things when it's the right time, not to do things know how
to talk to people and get their buy-ins.
And set an example. I think that's the most
important thing. Yeah, set an example, because
everybody's going to look up to you and you want to be that
person who steps into a room, when two Engineers are having a
conflict, whether you're a principal engineer or an
engineer manager, and you want to instill a sense of safety and
like, all right guys, let's just make a decision and as this one
that one day, this is just one day, we're going to be here for
many months and years. Yeah.
Let's just put this behind us. Yeah, I loving them.
There's a lot of good stuff in there, but the one that sticks
with me the most Is taking a little bit of your manager,
right? A little bit of their load and
allowing them to delegate and getting that trust in that way
and being more comfortable in doing those tasks because they
probably gonna be completely new is a really good way and a small
step towards what you're probably want to do, or you can
learn that that is actually not for you.
If you try and figure out something like, man, this is
really boring or like, is this really what they do?
That's knowledge. Right?
That's experiment experience and you can do that, I think.
Both on more people oriented managers as well as technical
leaders in that way as well. Really cool man, II, love how
this conversation flowed is there anything you still want to
share? Now I had a lot of fun so
profound it. Exactly.
As I imagined it to be I have watched your episode and I
absolutely loved it. And yeah thanks for having me
here. Awesome and thanks as well.
I don't know which camera because we switch position.
I'm going to take that one. I'm gonna put all aerial stuff
in the description below. Check him out.
Let him know you came from our show and thanks for listening.
Listening will see you on the next one.
Thank you.