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. 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.