Scaling High-Performing Engineering Teams - Alex Rashkov from Meta

Desi Velikova 00:00

Hi everybody! No matter if you’re in web2, or web3, as you scale your product to cater to 1000s of users, you’re faced with one of the most common challenges for technology startups: the challenge of scaling your engineering team fast. Scaling is not just about rapidly hiring people. It is about building resilient systems and effective team structures that will help the talent you hire thrive and deliver outstanding results. Put the brilliant person in the wrong environment, and you can expect nothing but frustration and disappointment. How to effectively scale an engineering team is one of the most discussed topics in the tech world. To help you find some of the answers. I spoke with Alex Rashkov, engineering manager at Meta. Alex has also held senior engineering roles at HSBC, Moo.com and a few smaller startups. He spent years setting up and leading dev teams, and in today’s episode, he’s sharing his vision on how to build a high performing engineering team. Enjoy the next 40 minutes. And don’t forget to subscribe to our channels wherever you’re watching or listening. Welcome to the product

Desi Velikova 01:23

Hi, Alex, great to have you here.

Alex Rashkov 01:25

Hi, hi, I

Desi Velikova 01:26

I’ve been looking to this conversation. Just for the listeners, we’ve known each other for I don’t know, for probably a couple of decades. We have a mutual friend. And I know your career since you were a student and junior developer to now engineering manager at Facebook. But just tell us a little bit more about your story and what’s been helping you to grow in your career step by step.

Alex Rashkov 01:50

Yeah, definitely. So where should I start? I, I started my career as a software engineer, probably 15 years ago. So I’ve worked across different sectors and different companies, from startups to medium sized companies to large organizations. And I’ve, I’ve had the opportunity to work across different products as well. So have spent some time on ecommerce payments. I’ve done a little bit of compliance. And most recently, I worked at HSBC, and now at Meta. So my career During my career outcome. I’ve been very much kind of invested in building products, solving problems for them customers, but also developed a really strong sense of helping teams and working with people. So I’ve shifted from engineering into engineering management and people management about six years ago. And I’ve been doing that through some of those companies.

Desi Velikova 03:02

Right. So engineering manager means different things to different people in different organizations. And I probably can find like a dozen of job descriptions for the same job title. So tell us a little bit more about your day to day. And what do you do as an engineering manager at Meta?

03:19

Yeah, so that’s a really great point there. So engineering management is very kind of broad term. And there are generally a lot of different different archetypes for people with different focus and things might vary company by company. So specifically around Meta, what we do, we have generally two tracks for engineering managers, and one is organizational leader. And the other one is kind of tech lead manager. So for me personally, my focus is primarily probably in between those two. So I’m trying to work really closely with people still remain really invested in to kind of the end to end product. And the the other thing is I’m we’re not hands on this is this is something specific around matter that our focus is primarily people product, and career roles. We don’t code and and that’s really crucial. That’s something I’ve had to do in previous roles in previous companies. But this is really giving us an opportunity to actually support our teams the best way we can, in terms of kind of my day to day responsibilities. As I mentioned from one side, I’m trying to kind of set up career growth opportunities for the engineers work closely with our cross-functional partners. So that means product data, or user research and try to bring the the entire group together, as well as kind of setting up some of the internal processes and making sure that we work well as a kind of larger team.

Desi Velikova 05:09

Interesting. For me, as an outsider, one of the most important qualities of an engineering manager is the ability to speak two languages, to be a leader for your engineering team, but also to kind of effectively communicate with the people outside of your team, and especially non technical stakeholders, and probably sometimes even acting as a translator between the two. So what are other key qualities of high performing engineering manager?

Alex Rashkov 05:43

That’s a great question. So you’re right that on one, I would say there are three levels of communication that we need to be able to navigate. And you have different stakeholders with different mindset, different goals, and different folks as well. So more on kind of day to day with engineers, we need to be very kind of understanding the technical jargon and kind of be able to reason about the projects and the tasks that people are doing day to day basis. Equally, we need to create, in collaboration with product and design, our vision and strategy for the team. So linking the technology and how technology fixes problems for the end customers, and how we are supporting the product vision is really kind of key on kind of team level conversation and communication. From there we have different partner teams that we work with, some of those are closer towards somewhere, those are a bit further away in terms of alignment. So we need to bring and create the right forums for those teams to be able to connect, work together and deliver solutions and to end. And finally, I’d say communication going upwards with our leadership. So you, we need to be very careful and be able to kind of condense the information from what’s going on to the day to day and be able to communicate leadership in a way that they understand, what’s the direction? Do we need any support? Where do they can jump and support our team to be better? This is just probably one part of it on communication, I think there are other really important this for engineering manager that needs to need to bring to work to our workplace. So one, from my point of view is setting up very clear expectations for engineers. So then, people can go and execute do the right things without having needing much input from from manager or other partners. The other thing is providing timely and constructive feedback. This is this is really crucial, because this helps us navigate and correct the course of what people are doing. But this goes two ways. So we are very open about feedback at Meta as a whole as a company. It’s part of our core core core culture. And it’s it’s not just giving and providing feedback to engineers, but those being able to receive feedback. So and that’s the growth mindset. Growth Mindset is the other thing, which is important, both for engineers in and managers within methods as well. So we’re not perfect, we’re all kind of growing our skills constantly. And that’s something I’m trying to bring in my kind of day to day job, trying to be very open, very, very vulnerable, and receive that feedback and work with that with engineers to to make sure that my approach is right for them as well.

Desi Velikova 09:10

It’s great that you mentioned the cross team cooperation is like really one of the biggest challenges for larger organizations. According to LinkedIn, Meta’s got over 9000 developers. I don’t know if that’s correct. And I’m sure you also had a very large team at HSBC, to anyone finding it challenging to create the right team structure, especially from an engineering point of view. What’s your advice? What worked for you in terms of processes and practices, but also models in terms of how you can structure a team?

Alex Rashkov 09:47

Yeah, so I guess it was something an example from HSBC. So when I joined the company, back then we had had to engineers. And we had to really quickly grow from. From that, in two and a half years, we grew up to three cross functional teams. So I guess one bit, that’s really important. I mentioned cross functional teams, this is a great way to create really good culture within the team, and make sure that we’re, the team is delivering end to end value. So what we were we’ve been trying to do is have engineers, designers product or working as a core team across a big problem area. So they were owning the problem for start to end. And that whole team was responsible and accountable to deliver those end to end solutions. This is, this is, I believe, really crucial on how people work. And this is something that we are trying to build in, in Meta, as well. So for us, we have engineering, we have data, we have user research, design, and product. And all of those functions are really crucial to deliver quality product. And if they work really closely together, it’s it’s a great collaboration model, because you have individuals or groups of people that have different mindsets and different look on the problems they’re trying to solve. Now, if you put that group together, they can challenge their ideas, they can work on their ideas, and they can come up with something really tangible, that’s really solving problem in a unique and sometimes innovative way that each of those functions in a silo would not be able to deliver that result. So in terms of operational models, outside of the teams, I think it’s really important to set up really clear working models across those teams. It’s something I’ve seen in Meta, and I’ve seen in other companies is, teams are working sometimes in silos, they have their own goals, they deliver on those goals, until they reach the point where they realize they’re doing the same stuff as another team. When that happens, you have a normally a clash of which priority is more important. And that’s the point where normally people escalate up the chain, and they need to kind of find a way to resolve those conflicts. I think if you create the right models up front with the right partner teams around you, it’s looking at roles and responsibilities. Alignment, how do you share goals, across board, metrics, and data is also a really crucial to make sure that people have that alignment. And they establish those connections. So this is something that I’ve been doing in the previous company, and I’m trying to do here at Mehta. So definitely for anyone dealing in working big organization, I would say invest in in creating those relationships and working models across different teams.

Desi Velikova 13:13

Oh, excellent. What do you think is the ideal structure of a cross functional team? Who are the players in this team?

Alex Rashkov 13:21

That’s a good question. So um, I probably mentioned few of the functions, you should definitely have engineering product design. And we we have like user research as well as part of that. And then data rights is, our outcomes are very much data driven. So we have a matrix, we are really trying to invest in those areas. So how the team decides who are the actual people involved, that could be quite flexible, but they each of those individuals should be represented in the decision making of the process. So one of the thing, which is really important is finding the right balance, which is never an easy task of how much information should go into different levels. Because let’s say let’s take engineering, for example. If you involve engineering, every single step of road mapping process, for example, you might the return on investment you get out of that process might not be as impactful or as big if you just involve them in the right times and write moments for them to deliver their ideas. So it’s really important how you manage the communication. So engineers can continue delivering their core function. So building the product from engineering point of view, but same time being involved in the process, end to end. And just one thing to say one thing, one process that we’ve been trying too, I’ve been trying to kind of utilize from Agile is Three Amigos, Three Amigos is you normally have product, you have engineering and quality assurance QA talking about the problem coming up with solutions and how they solve it. I’ve been trying to repurpose that for metal in our team. So we are doing similar discussions where where we have a product and decisions needs to be made. We have product design, engineering and data as a core team, or at least one representative of each of those functions to make those decisions and drive the projects forward.

Desi Velikova 15:40

Right? How do you measure the impact and the performance of your team? Unfortunately, how long someone’s spent on a task or lines of code is a vanity metric, it doesn’t really measure impact. How do we make sure that your team is aligned with the overall business vision and objectives and you can measure their contribution properly?

Alex Rashkov 16:04

I think this is very much depends on the situation and the team, the maturity of the team for let’s say a well established team, where you have already a working product, it’s already deployed to customers, you have clear metrics and understanding of the problem space. some extent, you can purely focus on metrics in that area. And for meta search teams they normally have like Northstar metric, they have clear targets that they can use on measuring the impact of their outcomes. So they understand well, what are their operational day to day metrics and they and levers that are allowing them to push the product in one way or another direction? For my team, I would say we are more relatively new within our space, we have a lot of ambiguity with what we’re trying to solve. And that maturity is not there of the both product of the technology and the kind of data metrics framework we have a moment. So that requires a lot more understand work. So I guess, let me speak about, we have three goals at meta normally, that we use when we build our roadmaps and how we kind of try to measure impact for the teams. So we have understand goals that are allowing us to do a deep dive in our area, do user research, do engineering understand of the problem, and come up with a solution for that problem. Sometimes, as part of that, we might run experiments to validate some hypothesis and so on. There is a ship goal, ship goals are we know we need to build certain piece of functionality from engineering point of view. And normally, these are very clearly clearly understood problems and why we’re doing it. So could be for improving operational operations within the different teams, or improving the underlying product that already exists. And we know we have migrations due to legal or compliance issues and so on. And then there are metric goals. Metric goals are with maturity, like with the least amount of maturity, you start from understand with the most amount of maturity, you are reaching the summit these metric goals where you have a clearer idea, how do you move the needle and how much you want to move the needle, for example, you can say, reducing, let’s say bad content with 20% within a specific area. So these are the three main goals as we try to use for engineers, there are, I’d say, three, three, or four kind of main axes that we use, for one is project impact, where we can clearly say, what was improvement, or what are the achievements and we try to measure and assess throughout the process. We have engineering excellence, which is general improvements of our platforms. Sometimes those might be serious bugs that are affecting hundreds or 1000s of customers and that are costing us millions of dollars, for example. And that is, that could be a way to show the impact for the for the specific engineer, or the business as well. And then we have two more which are people and direction. So people is very much around. How do you support other people? How do you collaborate with the rest of the company? In these are metrics that are not very clear. So it’s not non quantifiable metrics, but still, we try to measure that through feedback. And again, back to the feedback culture, this is really important. So we have full visibility within the company. And finally, direction is setting up the direction for the team to roadmapping, creating projects, or influencing other teams in the organization as a whole.

Desi Velikova 20:18

Well, from your experience, what are some best practices for improving team performance? I mean, I’ve heard managers before using hackathons, code reviews, voting, content, suggestions, and so on, and so on. What has worked for you.

Alex Rashkov 20:35

So I guess from the different things is like, from one side, you have culture and from the other side, you have different rituals that are helping to either create that culture or support, communication collaboration within the team. From different I would say, it’s very important to create the right forums for the team to be able to communicate clearly within within the team and externally as well. So we have regular show Intel’s where we do like product demos are we do different learning sessions, people have learning sessions, and they can present the outcomes and something that will impact or influence the entire team. Also, you mentioned hackathons, we do hackathons fixed stones on different levels within the team, within broader organization. And that is really helping us to achieve some of those various I mentioned engineering excellence, where we’re trying to kind of keep our platforms healthy and stable and to operate well. But what’s also really important is using Agile rituals like retrospectives, where we have continuous learning cycles, to improve our process, where people have the forums to contribute and tell us and like, speak to each other as well, to explain what’s working, what’s not working. So these rituals are really important because they create an environment, highly, highly trustworthy environment, which removes judgment and allows people to experiment and do things. And then from there, it’s like, next step is create empowering your team. So giving them opportunity to decide how to drive impact for the work, and be the been the driving seat. So this is very, very specific thing on about matter, which I haven’t seen anywhere else, even though I’ve been trying to create them, previous organizations. It’s very much engineering driven. But it’s not just that it’s individual, our individual contributors, people on the ground, decide what to what projects to run and how to run those projects. It’s, I want to kind of steer away from engineering driven, because that’s very isolated the rest of the groups, where in reality, we have design, we have product, we have user research and engineering as well, driving projects, very much. Bottoms up. So design are. So we’re doing design sprints, ideas are coming up out of those projects that are being generated, and the whole group works together to deliver those projects. But people on the ground can decide where the impact is, can convince leadership. So people within the team about some extent, but also leadership, why do we want to invest in certain area, and we empower people to pivot on projects, if someone figures out there is no value to work on certain area, they can completely change the whole direction of the project, as long as they can show what was the problem, and why there’s more, where’s more impactful and to be delivered and how they plan to execute that. So empowering our people creating trustworthy environment. And having those kind of shared values within the company and within the team are really important drivers for creating those highly performing teams.

Desi Velikova 24:34

Well, that’s a great example of trusting your people. Let’s talk a bit about the people side of the job and your approach to managing tension within the team. Engineers are highly intelligent, very empowering people. Many of them are introverts. They’re usually very consumed by their work. But one of their common weaknesses and of course, I’m generalizing here not everyone is the same is their ability to effectively communicate with non technical people? What’s your advice here? Do you have any tips how we can manage this? And also, what’s your experience with managing different personalities on the team?

Alex Rashkov 25:16

So generally, we do the environment, the area I worked in the moment is very much with product generalists. That’s what we call this set of software engineers, and system engineer this, the idea is, these are product minded individuals that have built end to end solutions, customer facing products. So what I would say, there is there is that problem, I’ve seen it in the past, I’ve seen it in myself, where we, by myself as an engineer, I was very much in the weeds in the day to day and focus on the technical problems, and sometimes forgetting about forget forgetting about the end customer, and what are we solving? Why are we building it. And this is, this is very important thing of trying to step back, look and understand the big picture. I think this is why we’re trying to make sure that people are not working in silos. And we are trying to pair up, let’s say more junior people that might express those traits in with some more senior people that will can help them and help them help them grow those those qualities, and abilities to understand the product and why we’re building something. For us, every single project is starting with impact. And the impact is where we try to link that technical solution back to business value or customer value. So this is part of the culture to some extent. And this is really helping us to frame the problem. So we we have documents that we normally write for each of the projects, and people are really encouraged this part of the communication of outwards. So people writing one pagers or RFCs requests for comment, as they’re also commonly known, where they explain what the problem is, what the goal is, what’s the impact for the customer. And this is normally being shared with a wider group. So where people can comment and ask different questions and try to understand what’s the value. So this is a great way to have communication, wire communication, and understanding and alignment and allows you more junior people to grow and understand why they are building something. And it’s not just for the for technical reasons is for delivering and customer value. Something else which is very well developed within Meta and it’s working really well is we have a lot of we have strong mentorship and mentoring culture within matter. So that’s happening on multiple different different levels. I mentioned there, we’re trying to pair up senior and more junior engineers on teams. But also there there is mentorship programs that are being run all over the Meta different orgs different parts, which are helping engineers to really grow different set of skills, whether those are technical products, project management, career growth, opportunities, and all of those things are being discussed with, let’s say, people, individuals that have been within the company for few years, and really can coach and mentor people to grow those abilities. Well, through through their career. Yeah.

Desi Velikova 29:06

Right. Um, I don’t think this is the case, it might tell from what you’ve been describing. But unfortunately, in many organizations, developers and engineers are often being treated as a tool, executing other teams, ideas and visions. It’s wrong. It’s demoralizing. It’s also miss business opportunity, because many engineers are actually highly creative people with strong business flair. What can we make sure that we avoid this? And I don’t think to be honest, this is done intentional. Maybe sometimes it’s a matter of you know, how you have structured teams in your company, but especially for younger startups that are about to scale up their teams. What’s your advice? How can we avoid this and make sure that engineers are active contributors to the process

Alex Rashkov 29:58

and the I’d say probably there are different types of startups being led slightly differently. You have startups being started by highly technical people, and understanding the problem purely from a technical side, but not having that much investment and on the people side, but equally, you might have more product minded people that are creating the startup. And that might be the word foxes, I think it’s really important. And there are probably different stages for each age company startup as well. So that’s very important to look back and understand what stage you are, where do you need to invest? And what do you need to how do you need to restructure your organization, and this is a continuous process. So dealing with a company with, let’s say, two to five to 10 people is one thing. Now once you start experiencing growth pains with, let’s say, 30 people, you people have to our leaders within that company will need to start creating the right structure and the right communication channels. So to avoid those things, I’ve seen very much top down structured organizations where what you describe is there is a task that needs to be delivered and goes down to levels and someone each level is trying to keep their responsible for delivering the outcome, and they’re keeping the next level down. So one level is accountable. The other level is responsible for delivering the outcome. And this is where you have the top down culture which creates those kinds of silos, or very much execution lead culture, and that stifles innovation, creativity, and it’s very much creates that toxic culture generally, because people had, you need to deliver this by this time, and sometimes sometimes coming from banking and financial background, where it’s highly regulated. Sometimes probably the majority of your business needs to be executed in such way because you are held as a whole company accountable to deliver and help your customers make sure they’re safe, their funds are saved and so on. Other environments, you have more flexibility. And I would say some extent within matter, we have a little bit more flexibility to do those to change the approach where it’s bottoms up. So doing it bottoms up means you need to assume that you don’t have control of the process. And some people are really struggling with that idea. If you don’t have the process, they there they think they won’t be able to control the outcomes. Again, if you have clear direction vision, trying to give some guidelines and guide rails guardrails for for those teams to work within those guardrails, they can produce results, and good results aligned to the overall vision. And that allows them to organize and being flexible of the how do they communicate on a lower lower level. And also, having metric culture data driven culture is really important. Because without that, you have no visibility, you don’t know whether you’re going the right direction or not. And you don’t know where when you do you need to kind of change direction for teams orcs. And it’s really difficult to navigate that environment. So data driven is really important. Giving some flexibility and ownership for teams, especially how they are organized and so on is really important because then they become owners of, of their final product and the outcomes as well.

Desi Velikova 34:03

As an engineering manager, I assume your role is much more about leadership, and executing the vision rather than coding and developing can be more. So I’m just curious, how do you maintain the depth of your knowledge so you can stay confident you’ll lead your team in the right direction.

Alex Rashkov 34:24

So it’s very important to figure out where I can have the biggest impact for my team. For for me, I am trying to extend a lot of trust in the engineers. The people that are on the ground are the people I work with, and I rely on their advice very much. So this is important because if I’m coding and I am involved in the day to day, operational execution part I become automatically a bottleneck for the entire team for us, like removing myself From the day to day, I’m trying to focus on communication on relationships on, as I said, vision and strategy are probably one of the most important bits. But also I try to keep myself at least involved in some of the project discussions and some of the technical discussions. So I maintain some level of understanding of what the problems are, and how I can best support those engineers. So, for example, during our hackathons, I’m getting involved with the engineers, even though I’m not coding, I’m still looking at their code, I’m trying to understand the solutions and how they’re approaching it. I am still, some of my kind of engineering skills from the from my past are still relevant. And as in terms of advice, that still applies to let’s say, probably not that much senior engineer, but more for junior engineers that are trying to figure out how to navigate the company, and how to deliver more impact within our engineering excellence. area. So these are the main ways I’m trying to come in getting involved in day to day activities, to some extent, but not too much, because otherwise, I’ll lose focus on other more important bits in lose the bigger picture.

Desi Velikova 36:30

Right? So having the right people that you can trust is so important when building your team. What qualities are you looking for when hiring engineers for your team?

Alex Rashkov 36:42

So we we have really rigorous and well established hiring process. Generally, how we hire is, once a person has been hired within the company, we we need to attract that person to want to join our team. So it’s likely that’s

Desi Velikova 37:04

how it should be everywhere.

Alex Rashkov 37:07

It’s quite it’s, for me, it’s a big game changer compared to any other previous company. I’ve been involved as a hiring manager during the whole process from start to end. And normally, what I’ve been looking for in people is, first we always look for technical skills, right? That’s important for an engineer, they need to cover the the bar for the requires role and for the required level. And this is super similar to within Meta as well. So people are doing coding interviews, people are doing design interviews, as part of the hiring process. But there are other interviews, like culture or team fit. And then behavioral interviews, which are trying to figure out few things, looking at motivation, empathy, looking at ability to be proactive or proactive mindset. Also, this is getting things done, right. So can you unblock yourself and deliver on different outcomes? Having a growth mindset, thinking of how do you develop yourself? How do you develop your career, or any other outside activities that people are doing are really good, strong signal that they are trying to develop themselves in different ways. And communication as well. Communication is a great factor. It’s as social network social company, for us communication and visibility, transparency, is super important. And that comes up in different ways in our day to day interaction interactions and how we manage projects, how we deliver the projects, and so on. So I’ll say these are the top levels, we have different areas within those that we’re trying to assess through our interview process. And I would say from my experience of being hired at Meta, it is now seeing it from the other side. It’s very transparent. It’s a very clear structured, and we try to remove bias from our process in through multiple different levels. Having involved multiple different people involved in that process really helps to weed out people that my experience but we all experienced bias in our conversations, but having different cultures, people from different backgrounds, nationalities, different underrepresented groups as well, is really important and that’s part of our kind of whole end to end prior firing up. By hiring pipeline, and process,

Desi Velikova 40:04

that was a great chapter. Thank you very much for your time. Alex, before I let you go, what’s your advice to young engineers who are just starting off their career? Where is the best place to learn?

Alex Rashkov 40:15

Typically, yeah, I started my career working for small companies. I’d say for new engineers, if they have opportunities to start their career as a startup, whether that’s as a training or they started a role as a junior engineer, that’s a great place to learn fast and develop skills fast. Startups are fast paced environment. Very often, you need to wear different hats, and you need to solve problems that you’ve probably won’t face in a well established big company, you have to do product, sometimes product, you need to be a designer, sometimes you need to work closely with marketing, and other teams. So this is a great opportunity to learn fast develop skills and, and fix problems on the ground. And that they’ll be my advice, once they kind of established and know that what they want to do, how they want to drive their career, they can take any path forward, and but all those skills they’ve acquired in a startup would be really beneficial and useful for them.

Desi Velikova 41:30

Interesting. Thank you so much for your time today, where can people find you online?

Alex Rashkov 41:35

I am on LinkedIn, and Twitter. So if people want to reach out to me, I’m always open to talk about engineer manager or kind of problems and how people can navigate the space or engineering purely career growth opportunities and so on. So, yes, I’m happy to share links with you as well.

Desi Velikova 42:00

Perfect. Enjoy the rest of your day. So that’s it for today. Thanks for listening, everyone. This podcast was brought to you by Tony. We spent our time designing the future of web three. Check us out on pony dot Studio.