Episode 3 follows Raquel Vélez (@rockbot on Twitter) in her management journey as she moved from lone-manager-at-tiny-startup to discovering her “first team” of engineering manager peers. Prior to management, Raquel was a JavaScript developer who eventually found her happy place learning to work with systems of people instead of systems of code.
We talk about the similarities and differences between small companies and big companies – the impact of reorganizations, discovering lanes and your first team, managing sideways, securing promotions for your reports – and how it’s still humans all the way down.
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast microseries by Cohere.
Hi, I’m Jennifer Tu, and I’m here with Raquel Velez, who I really know as Rockbot, to talk about what it’s like going from managing in a small startup to a medium largest company. Raquel, can you tell us a little bit about yourself?
RAQUEL: Yeah, absolutely. I’m an engineering manager and I have been working as engineering manager for almost three years, I guess, at this point. And I started out as an IC. I was a JavaScript developer who ended up doing a bunch of Node. And then I really found my happy place in terms of thinking more about the systems of people as opposed to the systems of code. And I just really like that a lot more and found myself in management. And basically just started working my way up through all those fun challenges.
My entire career, up until the company I currently work at, has been at really tiny startups. So, it was like 40 people or less. And then I made the jump to my current company where I joke that I was like employee number 998 or something like that, because I wanted to move to a company that was between 500 and 1000. And so, I was successful at that moment. [Laughs] But then very quickly, it grew more and more. And in fact, it’s now like over 1500 people.
So it’s been really a fascinating jump from the super tiny to, in my world, super huge, but it’s not like a massive, massive enterprise company that has tens of thousands of people. Well, I can’t speak to that level. The jump from 40 to 1500 is really quite stark. And I think that’s what we want to talk about today.
JENNIFER: There’s probably more teams at your current place than there were people at your last place.
RAQUEL: Oh, my gosh. Yeah, probably. Almost certainly. Almost certainly. I mean, I think certainly in terms of like, even just if we only look at the engineering side of it, at my last company, I was managing at my peak, I want to say like nine, maybe 10 engineers. There are definitely more than nine or 10 engineering teams at my current company. [Laughs] So yeah, it’s pretty intense.
JENNIFER: How about in terms of the number of people you’re managing, has that [inaudible] or are you still managing nine or ten people?
RAQUEL: I consider myself ridiculously lucky right now in that I currently have six reports.
JENNIFER: Oh, that’s very nice.
RAQUEL: Which is just like, “What? Oh my gosh, this is so nice.” Though, I will say that at my peak I had 12 and that was just untenable. I know that there are people who manage like 25 people, but it’s just like I don’t know how anybody does that, and does it effectively. So, I had 12 then we had a reorg.
One of the things that changed a lot for me was experiencing the reorg. And I guess, in small companies, you have reorgs, but it’s such a small company that the reorg is, “Well, we’ve decided that instead of having these two teams that are separate working on pretty similar things, we’re going to try to merge them.” And it’s like from two teams of five into one team of 10. It’s like, “Okay, whatever.” Or maybe it’s the opposite. Like, “We’re going to separate this one team of 10 and turn into two teams of five because there’s a better delineation between those two. Here, it’s like, “Okay, we’re doing a reorg,” and all of a sudden a bunch of people are getting moved across multiple teams. Maybe you’re going from four teams to five or three teams to four. Or maybe you’re sticking with four teams, but now they’re all defined differently. And there’s like a much more human element to it where you have to be like, “Okay, how are people going to react to all of this change?” Because it’s not just your role is changing, everybody you know, their roles are changing in some way. And so, that’s been really interesting as well.
JENNIFER: When you experience a reorg in a larger or smaller organization, are there things that you can do the same in your approach to that as an engineering manager or things that you have to do differently?
RAQUEL: I think that the things that I have done the same is just being a good people manager. I think being a good people manager is necessary regardless, because people don’t change when the size of the organization changes, people are still human. You don’t go from being a human to a robot. [Laughs] So, making sure that people still feel like they’re part of something bigger is really important.
One thing that did change is I needed to be much more explicit about what our new roles were. In a recent reorg, I actually got to spin up a brand new team, which was super exciting for me. It allowed me to kind of really help dictate what are we doing, what’s our purpose. And I had a new product manager. And so, she and I both worked together to identify, what’s the vision for this team? What’s the mission of this team? What are our focus areas? And we wrote things down a lot. There’s a lot more writing, I think, because the teams are larger. In this case, it’s not just you focusing on your individual team. You’re writing that document to share with the other engineering managers and the other teams in your larger organization. My peer engineering managers, which I never had a peer engineering manager at my previous company, they need to know what is it that my team is focusing on? Because I think it’s important to know about, like, lanes. There’s that saying like good fences make good neighbors or something like that. And so, knowing where the fences are enables you to be really explicit about saying, “Hey, I need help. I need you to come into my lane and give me a boost,” or, “Hey, I see you’re struggling. I’m going to go into your lane and take stuff off of your plate.” And I see that as like the most helpful thing as opposed to some people who are like, “Oh, I hate the idea of so much structure because then it really limits how much I can do.” And I don’t see it that way. I see it as it really enables the way that I can really work with my peers in the most effective way and be the best teammate that I can be.
JENNIFER: It’s almost like you’re going from working alone to working in a team because you have all of these peers around you.
RAQUEL: Absolutely. And that was actually a huge component for me. At my last company, I was the only engineering manager and I reported directly to the CTO. It’s really hard because you don’t really know how to grow. There were moments when I would ask my manager and even my CEO like, “Hey, how do we grow to the next level?” And in a startup, sometimes the people who are in charge, they’re just as new to this whole leadership thing as you are. Or maybe they’re newer or maybe they’re more experienced. And if they are more experienced, you’re really lucky. But working in the [valley], it can be a little bit difficult. And so they were like, “We have actually no idea.” And it was really frustrating for me because the feedback I got from from one of them was, “Well, why don’t you define what your career or what your new job description would be, and then let’s work towards that.” And I’m like, “That’s a great idea in theory, except in practice, I have no idea what the next level looks like.” I don’t know how to put it into words, much less visualize it because I’ve never seen anybody at that level before. I couldn’t tell you what a director does compared to an engineering manager. I remember the CTO once said, “Being a a middle manager is so hard.” And I thought that meant I am a middle manager because I’m between the executives and the IC. So therefore, I am in the middle. [Laughs]
JENNIFER: It makes sense to me.
RAQUEL: It makes sense. But then when you come to a larger organization, you realize that middle management is actually like the Oreo cream between management, like cookies. So, the Director is middle management. I’m what would be considered a line manager because I’m right next to the ICs.
JENNIFER: Yeah.
RAQUEL: But I didn’t know that. Like I said, my entire career was startups, so I had no context for that. And so when they were like, “Hey, why don’t you just write your own job description?” I’m like. “I don’t know what that’s supposed to look like.” I’ve never met a director, so it was just impossible.
And so, I knew that the next stage of my growth was going to be going to a bigger company where there were other engineering managers, first of all, so that I could compare notes with my peers and just have like a gauge by which I could tell, “Okay, where am I succeeding and where do I need to improve?” And then also having a manager and having my manager have a manager and then having that manager have yet another manager, and seeing the growth potential so I could see, “Oh, okay.” And it turns out I wasn’t ready for being a director because it turns out a director does a very, very different role than a line manager. What I needed to do was grow to the next level of line manager. And so, that’s the goal now as opposed to like, “Oh, yeah, I want to be a director. I want to be a VP.” Like, “Whoa! Hold up.” I’ve completely reset my expectations of what my career path looks like.
JENNIFER: That’s amazing. I want to dig into one little part of this, which was you mentioned that there are lanes that a line manager should expect to be in because you have all these peers around you and you don’t want to be bumping up into their space. And I’m kind of curious how you find your lane, and then how you learn to collaborate with your peer managers around you.
RAQUEL: That’s a great question. There’s different types of lanes. One is lanes between other engineering managers. So, identifying what are the boundaries between what your team works on versus another engineering team. And then another series of lanes are between engineering and the other parts of the org, like product design and things like that.
JENNIFER: Let’s focus on the first one, if that’s okay.
RAQUEL: Sure. Yeah, totally. Focusing just on engineering managers, I think there’s a lot of different ways that you could do it. And I think it really depends on the type of company that you’re at. There are companies that are product driven companies and there are companies that are design driven companies or engineering driven or whatever. And so, I think that that will kind of help define it. The way that my larger team has decided to define the lanes, which is actually kind of difficult, is we’ve tried to focus on service boundaries. So we take our code base and break it down into the different components or services that make up our larger section of the code base. Then we can say, “Okay, Team A focuses on these three services and Team B focuses on these other services.” And so you can kind of be like, “All right, cool.” So if I’m in charge of these three aspects, then it’s easier because you can just be like, “So when something’s broken, we will fix it.” And that’s one way of thinking about it. Or as we build product, we’ll be focusing on these aspects of the product or whatever. So, you can do it in terms of engineering components, you can do it in terms of product components.
Where we’re at, at my current company, it’s a very product driven company. But the engineering side of it, we’re trying to divide it into engineering components. And so what happens is you actually have a lot of overlap because let’s say, for example – I’m going to do a really, really high level example. But let’s say instead of a frontend team and a backend team, let’s say you’ve got like a billing team versus the app experience team.
JENNIFER: Yeah, that makes sense.
RAQUEL: And from an engineering component perspective, you might say, “Okay, the way we’re going to divvy this up is frontend versus backend.” And then there are going to be times when the frontend has to talk to the backend. And it’s like, “Well, who owns that component, like the interface?” The APIs between the React and some sort of backend or whatever. Maybe there’s databases or something like that. So that’s an engineering way of breaking it down.
Or you can break it down by product perspective. So, billing versus the app experience. But then in that case, your engineering is going to be split up across it as well. You’ll have frontends and backends on both sides of those. And then now you need to figure out, “So, what are the components of the application that just focus on billing versus just focus on experience?” But of course, there’s going to be overlap. And so, that’s kind of like the boundary line. And you can say, “If we need to talk about the experience of the billing, then what does that look like?” And so that’s kind of your opportunity to really interface with your peer managers and say, “Look, I’m about to go into your lane,” or, “I see that you don’t have any bandwidth to tackle this, so why don’t we take it?” And then, like, “I’ll keep you abreast of how things are going.” I hope that makes sense and answers your question.
JENNIFER: Yeah, it does.
RAQUEL: Cool.
JENNIFER: And it just makes me wonder next, how do you coordinate with your peer managers? How do you know which peer managers you need to be coordinating with? What happens if you find there’s one you haven’t been coordinating with?
RAQUEL: I think the most important thing is just to be really authentic and human. There are going to be moments where you’re like, “Okay, I’m convinced that this is my thing and I’m just going to go for it.” And so, on some level, you might even have built it. And then you find out later, after you shipped it, maybe there’s a customer complaint and the bug goes to the other team. And you didn’t even know that that other team found it or what even existed. And then, the engineering manager might be like, “Hey, I looked in the org chart and I found out that your engineer worked on this thing,” because you can see the commit logs, and you can see everything in GitHub. But then you might be like, “Wait, who is this engineer? How did they get this? Where did this come from?” And then they might reach out to you as the engineering manager and be like, “Hey, what the heck?” And in that case, you might apologize and go, “Oh, my gosh. I’m so sorry. I didn’t realize that this was part of your components as well.” And this is an opportunity for us to start talking through who owns what, what are the boundaries and really just start to define that because maybe it just wasn’t defined before. If you know the boundaries, if you know who owns what pieces, and basically, you can look at that via whatever tracking tool you use or maybe it’s just a spreadsheet or who knows, then you can kind of give them a heads up and you can say, “Hey, I really, really value tech specs and product specs because it gives you, again, a written documentation of what you plan to do.” And then you can go in and talk with people and say, “Hey, here’s our plan.”
If you want to go the extra mile, you can even say, “Hey, we’re planning on doing this thing super high level. We haven’t even started to do any engineer exploration, but I want to just see when you get your buy-in on this. See if you’re already doing stuff like this.” The more that you can develop a network across all of the various peers that you have, the better you can start to have those super early conversations. For example, in this billing versus app experience situation, you can be like, “Hey. we realize the international users are having difficulty with the billing. Do you think your team can tackle this piece of it, or is that even on your road map or what? Do you mind if we take it,” or whatever? So having that network and building that trust across multiple managers is, I think, really key to really making an impact.
The only tricky bit is that in a larger organization, there are more managers and there are more peers. So the time it takes for you to build that new network is much longer, which then ultimately results in a lot more apologies. But I like to see those apologies as opportunities for instant networking. [Laughs]
JENNIFER: It’s feedback time.
RAQUEL: Exactly.
JENNIFER: Learning to navigate the organizational structure and learning to network across your peers sounds like this really critical and also new skill that you have to develop when you move from no peer managers to having peer managers. Are there any ways to start? If you could go back in time through your first week, is there a time or an action you could do to make that easier for yourself?
RAQUEL: I think, easier for myself, maybe in hindsight, you can make the argument of like, “Okay, if you write all of your stuff down and share it regularly, you’ll be better off.” But that’s a little bit harder because you might not have that muscle ready yet. It’s almost like trying to tell somebody who’s like a runner like, “Hey, I needed to swim 10 miles.” I mean, I could probably do it, but it’d be really hard and I’m not trained on how to do that effectively.
JENNIFER: Or telling a very brand new developer to comment their code.
RAQUEL: Yeah, exactly. That’s exactly right. And so, ideally say everything. But the problem is you don’t know what it is that you need to say and what you need to hold back on, because what I’ve learned is that it’s not enough to just say everything that’s on your mind. That’s actually too much information. And so, you need to reduce some of that, because sometimes people perceive too much information as reasons to get anxious. Like, oh, my gosh. You don’t know what you’re doing. You don’t have any focus. You’re waffling or whatever. It comes across that way. Even if you’re not waffling, sometimes what you need to do is just say, “Okay, here’s my plan. This is what I’m going to do. This is how I’m going to do it. This is the timeframe in which it’s going to get done. And this is how you’re going to know when we’re successful.” And it’s just learning how to focus your intent and deliver the message to the right people is something that just takes time to learn, like how to write a good comment. I mean, how many times did we ever write comments that were like, “This function adds two numbers or adds A + B or whatever. [Crosstalk]
JENNIFER: Yes, exactly.
RAQUEL: And you’re just like [crosstalk] doing development for multiple years will look at that and go, “Oh, man, I used to make that mistake. And that was maybe not the most useful way of handling that.” And so, it’s the same thing. Learning the mechanics of communication and keeping people on the same page. And learning how to manage up and manage sideways is a whole interesting sort of thing. I think we could summarize it as learning to manage sideways because I’ve never really had to do that before. And being really, really deliberative about your communication.
JENNIFER: Was it possible for you to find, I don’t know, allies or mentors or people to help you learn how to navigate this enormous organizational structure? Or did you mostly have to try things and learn through that feedback from your peer managers that it wasn’t working?
RAQUEL: I think it was a little bit of both. I felt like I could trust my manager pretty easily from the get-go. And I was able to be like, “Hey, I don’t know how to do this thing. What do I need to do?” And he would give me a little bit of advice like, “Try these things. Try those things.” Because sometimes I think when you know zero, it’s hard to even experiment because you don’t even know what to do. And then getting feedback just kind of hones in on some of that.
I feel really fortunate. When I was interviewing for this current position, I talked to a lot of different people, and a lot of different companies. And I tried really hard to talk to some of the people that I knew I was going to be on the team with. And I just try to gauge like what’s our rapport between me and my potential peer managers, because this can be somebody I’m going to be working with a lot. And in many ways, they’re your team. There’s this notion I’d never heard of before until I got here of “your first team”.
JENNIFER: Your first team?
RAQUEL: Yeah. And I was like, ‘What is that?” To me, my team was always the engineers who reported to me plus me. And the first team is actually who are the people that your manager – like you all have the same manager. And so, it turns out my first team is actually my peer managers. They’re my teammates. And so, in the same way as an IC, you might apply to a company and interview with people who are going to be on your team, you want to get a sense of like who those were going to be. And I have the same situation with – I think it’s important to do the same thing when you’ve got other engineering managers to get to know who are they going to be? Are they going to be antagonistic or are they going to be super helpful?
I feel really fortunate because it feels like I’m in a study group all the time. And I mean that in the most positive way possible.
JENNIFER: That sounds really supportive.
RAQUEL: It’s super supportive. I had to learn things like promo packets. Are you kidding? I’d never heard of a promo packet before. To me, when you knew an engineer was ready to be promoted, you would go into the CTO’s office, you knock on the door and be like, “Hey, so-and-so is doing a really awesome job.” And they’d be like, “Yeah, I know. I’ve been noticing it,” because they’re like one step away and they see all the work that that person is doing, too. And you’re like, “I think it’s time for them to get promoted.” And they’re like, “Yeah, I totally agree.” “Cool. Let’s make it happen.” The end. [Laughs]
In a larger organization, there’s a process and you have to put together a packet for an anonymous committee to review at the same time as everybody else. They go in and you have to give written testimony for why this person is ready to move on to the next level. There’s like a written component and a structural component, making sure that you’ve got all the evidence. Honestly, you don’t get multiple opportunities to do this in a single promotion round. You get to do it the first time, and then if they say no, you have a potential opportunity to appeal. And if you don’t win the appeal, that’s it. Your person does not get promoted. It’s almost like, “Oh, my gosh.”
And so to prepare for that, I got to lean on my peer managers. And every single day at lunch for two weeks before promo packets were due, we would sit together and we’d go over promo packets. And we would review them together and be like, “Hey, the wording of this is super vague,” or, “Hey, I don’t know that this project really showcases what you want it to,” or whatever. And so, I feel really very fortunate enough in that perspective to have that kind of team. Otherwise, I don’t know that I would have been as successful. [Chuckles]
JENNIFER: Yeah. Then suddenly, in addition to not having a promo packet passed, now you’ve got a retention issue you have to address.
RAQUEL: Yeah, exactly.
JENNIFER: I’m glad you’ve got that study group.
RAQUEL: I know. Me too. [Laughs]
JENNIFER: Now, we’re definitely over time. I want to ask you one last thing.
RAQUEL: Do it. Do it.
JENNIFER: If you could give yourself one piece of advice or give someone else in the same situation of going from solo line manager to trying to move into a space of peer managers, what advice would you give?
RAQUEL: I think the most important thing would be to really learn how to ask for help and learn and try to understand, almost treat each person that is your peer as somebody who reports to you in terms of getting to know them as a human. Actually, scratch that, I’m going to rephrase. Get to know them as humans. Know who you’re working with in the same way that you would have as an IC. Get to know the strengths and weaknesses of the people on your team and then harness that as an opportunity to give help and get help. Because you’re a team and the success of your people is dependent on how well you can support them. And the more support that you have to support them, the more they will feel supported, and then they will grow. And your job as a manager is to help your people grow and help them do great things, as part of the larger mission of helping your company do great things. And so, if you have that support network within your first team, there’s nothing that will stop you. If that makes sense.
JENNIFER: It does. Great. Thank you so much for sharing everything you’ve been learning about going from tiny startups or small startups to medium largest companies.
RAQUEL: You’re welcome.
JENNIFER: If people want to talk with you more about engineering or management, where’s a good place for them to reach you?
RAQUEL: Totally. Feel free to reach out to me on Twitter. I’m @rockbot and I have a blog which is at RaquelVelez.com. You can find my contact information on there to email me if you really want to.
JENNIFER: All right. Great. Thank you.
RAQUEL: Yeah. Thank you.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. Our theme music is by Kevin MacLeod and we are edited by Bryant from Zinc. If you like this episode and want to hear more, tell us on Twitter. We are @wecohere.
