In Episode 26, Ale Paredes (@ale7714 on Twitter / ale7714 on LinkedIn / Latinas In Tech NYC) shares her team’s experience as they find themselves not just unexpectedly remote during a pandemic, but also unexpectedly onboarding while unexpectedly remote during a pandemic.
We talk about the role of documentation, 1-1s, and social touches in onboarding and team management.
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast by Cohere.
Hi, I’m Jennifer Tu, and I’m here with Ale Paredes to talk about unusual onboarding of new employees when you’re unexpectedly working remotely during a pandemic. Ale, can you tell us a little about yourself?
ALE: Hi, everyone. Thank you, Jennifer, for having me. I’m the VP of Engineering at Code Climate. I am from Caracas, Venezuela, and I moved to New York six years ago, joined Code Climate three and a half years ago as a senior software engineer. And then the company grew and I have been growing with the company. Currently, I manage a small engineering team of 11 engineers. And on the side, I also co-lead the New York City chapter of Latinas in Tech.
JENNIFER: Sounds great. You mentioned you’ve got a small engineering team. I understand that like many teams, you recently and unexpectedly went from in-office to entirely remote. And then along the way, you were growing the team as well. Can you tell us a little more about that? Like how long the team had been unexpectedly working remotely, when your new hire started or what their first day was like?
ALE: We went remote mid-March. And two weeks after, we had two engineers, a start. Their first day, we had them join our stand-up. We do engineering stand-ups every morning at 10:30 a.m. We had them join, introduce yourself so they can see everyone and recognize everyone’s face in real life. And then we follow what we call Day 1 onboarding plan where we write what are the steps and engineer should follow to start onboarding themselves in our services.
JENNIFER: All right, sounds pretty typical. One of the things that a lot of teams do with onboarding is they have a Day 1 plan and have some kind of here’s how you get set up in our system. And when teams are in-office, we rely on the new hire to be able to turn to their new teammates in person and do a little bit of nonverbal communication to find someone to ask for help. So they kind of look around, see who makes eye contact back, who kind of looks kind of friendly in their general direction. And so, I’m wondering what kind of in-office practices you had before around helping your new teammates, your new hires, get help from their teammates and what you did afterwards when everyone was unexpectedly remote?
ALE: So usually before all of these, when an engineer has their first week, there is a lot of pairing. Usually different members of the team pair with them on different days. So they have kind of like a buddy throughout the week to ask questions and get help as soon as possible. So there is none of that frustration of like feeling blocked or like you don’t know what to do.
And then we move into this remote work. The most important difference was realizing that we needed to give more intention to allow that bearing. So we created a scale with all of the engineers on the team. And they knew they had to bear Day 1 with these new engineer and kind of like the topic of the bearing was like setting up their local environment, for example, or getting an introduction into how the architecture of the system. So I think the main difference was being more intentional about creating those opportunities to ask questions and get heard.
JENNIFER: Does that mean that when your new hire started, they were 100% pairing with everyone? Or was it more of they could ask for a specific pair each part of the day?
ALE: I wouldn’t say 100%. There were portions of the day where they were paired. And then we use Slack a lot. And we encourage everyone to ask questions. For example, let’s say you are setting up your local environment and everything seemed to be fine. And then for some reason, it broke. Sharing those questions so that someone can jump in and help out. And if the solution doesn’t seem to be easy via text because sometimes that’s kind of hard. Then we encourage to just jump in in a Zoom call and kind of like they work out the problem and make sure everything is running fine.
JENNIFER: What did you find in your new onboarding strategies that worked really well, maybe worked better than you thought or didn’t work nearly as well as you were hoping for?
ALE: What I thought worked really well, one of my biggest concerns was how can we make sure that everyone that is new in the team feels comfortable. If they’re having any struggles, how they feel they can contribute to conversations. So that was one of my biggest concerns is how can we make them feel connected. And I think that part worked out surprisingly well. And I think partially that is based on my very biased opinion. I have a really good team. And everyone usually is very open about how they feel or during a stand-up. If someone has a slow morning or is not feeling great, they would say so on the stand-up. And there is no [inaudible], it is completely fine to have a rough morning. So I think having that open and vulnerable environment, allow the new engineers to feel comfortable and very connected right away.
What didn’t work out so well? I didn’t realize before we went working remote, I have half of my team working in Brazil, so I thought or I made the assumption, “Well, our processes must be fairly remote-friendly,” because we already have engineers working remote. But then when we were doing this onboarding, I realized that there were a lot of things that we knew because we had the context where they weren’t in writing or documented anywhere. So I think that was a part that didn’t work out so well. Our documentation was a little bit weak. But that said, the silver lining is that we encourage a lot of the new engineers to start writing, kind of like all of the documentation that was missing or was out of date or needed to be expounded on. And now, we have a stronger documentation that will definitely make it way easier to onboard anyone remote or in the office.
JENNIFER: Did you find these gaps because the new hires found them or were you able to, I don’t know, get ahead of things and really anticipate?
ALE: I will say it was more of reading, I read between the lines. Like someone will ask a question and I will think like a completely fair question, like, “How are we supposed to do this?” Or like, “What is your expectation about using Jira?” And then I will think to myself, “Wow, this is a really good question. And we should have documented this,” because how will anyone outside of our team know we have to do this. So it was kind of like, I couldn’t get ahead of it, which is not great.
JENNIFER: I think that’s kind of normal.
ALE: Yeah.
JENNIFER: I don’t know any team that’s really gone ahead of it. But just in case, I needed to ask what the secret was, in case you had figured it out.
ALE: No. But I do think there is something really good about having new engineers is how easy it is [inaudible] spot what is missing, because I don’t have any of the historical contexts that we have. So things that are seem obvious. For them it’s like, not really. So, it makes it very efficient to make everything stronger when you’re onboarding. So that has been like the silver lining.
JENNIFER: One thing that you mentioned earlier that I want to learn a little more about is you said that your teams really know that there is no shame in coming to stand-up and saying that you’re having problems. And I’m wondering what it is that you do to reinforce that feeling of there is no shame and what you need to do differently, if anything at all, when you’re doing that remote.
ALE: I start with myself. So, I talk a lot about how I feel. And that doesn’t mean that I don’t also refer to facts when something happened. But also if I’m having trouble understanding something, I won’t pretend that I know everything. I will be very expressive. I’m vulnerable and say, “I don’t really understand this problem,” or I don’t have enough context and I cannot offer advice. And I think when you’re the leader and you are able to almost make it okay for everyone to do it as well, because there is like a sense of normalcy. And then I will say I encourage our senior engineers [inaudible]. So when a senior engineer sometimes I see them asking questions on private channels or in DMs, I will Slack them and be like, “Hey, can you maybe post this question in a public channel to make sure everyone can see that you also have questions.” And they just sometimes don’t understand things and that’s completely normal. And the more you ask, it almost becomes like a habit. So I think that’s the biggest thing.
From going to remote, I wouldn’t say we did anything different. But something that we did, which is like very specific to a situation is we do monthly product retros which are focused on the process on like how design, engineering, and product work together. But the last retro we did which was like three weeks after we went working remote, I noticed that no one really was in the mood to talk about the processes that we were using. A lot of the topics that we had were related to how we feel, how we’re coping, how it may be hard to separate work from being at home. So, I encouraged that we had that discussion. Everyone shared tips. Everyone was very vulnerable and candid. So I think being flexible with your own processes and being able to adjust to a situation has been useful right now.
JENNIFER: That’s really interesting that your team in the retro a month in was able to turn up that they had a lot of feelings about how everything had changed. I also really liked how you described doing a lot of modeling and then asking your most senior members of your team to also do modeling for how to show that it’s okay to not know things. And it’s also okay to have feelings about what’s going on.
ALE: At least right now, that has been the most effective way I have found, to not only try to model myself what I think our behavior should be, but also make that scalable, because right now I have two squads within the team, so I don’t usually talk to everyone all the time. So it’s kind of like trying to make that modeling scalable.
JENNIFER: Yeah. So talking about squads is making me think about how people relate to each other. When we are in office, we do a lot to affirm our relationships with each other. We say hello. We go get coffee together. We just take all of these moments between and spend them together. And one thing I’m thinking about is how has your team been creating those relationship affirmations while being unexpectedly remote? And then how do you integrate new team members into those experiences?
ALE: I will say one of the first things that we adjusted when we went into remote was to make sure that, for example, in the stand-up every morning, we have a [inaudible] that is almost like socialization instead of just going right into business. So people talk about what they had for dinner or what are they doing for the weekend or what video games they’re playing. So I think that helps a lot into understanding or creating those connections.
We also have – this is not engineering in specific, but every day we have an optional Zoom meeting called water cooler. And you can just like pop in there for a couple of minutes and talk about anything. Something that I really like is one of our new engineers, she kind of took the lead on making sure to remind everyone to join the meeting, which to me is a sign that she feels comfortable and that she wants to create more of those connections. And then we try to stay connected as well through Slack and making sure people talk about work related things and also non-work related things.
JENNIFER: I think you mentioned earlier that you’ve got a couple of people who were onboarded and it sounded like your team was on the smaller side before. How much did your team grow? And how has that been like?
ALE: My team grew last quarter about 40%.
JENNIFER: Oh.
ALE: Yeah, they were six and now 10. So yeah, that’s 40%. Last quarter, we grew about 40% more or less. And one of the biggest [chiefs] is communication. Communication when you’re really small is so easy, getting everyone on the same page. Everyone has the same amount of context and ensuring that happens is very easy and low effort. And now, we went from a small team that all the time work together into two squads, which means that your engineers started working on projects that [inaudible] have not that much context, but maybe they could help or offer a hand or but they don’t know it. So I think one of their biggest [chiefs] is making sure that we create visibility across the team about what’s going on. But without needing everyone to be in all of the meetings, for example, or read every pull request, because that doesn’t seem feasible. And then also making sure that our engineers, especially our engineers that have been on the team for a long time, feel comfortable of letting go a little bit, which I think is very normal for us to feel when we have been working on something for a long time. It’s almost like our baby. And then someone else comes in and they have different ideas and context, and they want to change things.
So, being able to make sure that we’re giving new engineers half that space to suggest those ideas and we are listening to those ideas. I think those are the two biggest differences in terms of how we’re handling communication. We are doing a lot of more writing in general, which is a bit cheap for us. We used to rely a lot of face to face like, “Oh, let me get you out for five minutes.” And they will tell you exactly what you need to know. Even if we were on the office, it wouldn’t be feasible to have everyone for five minutes. So now, we’re writing clear product documents, we’re doing more requests for common documents, which are basically design documents and we use pull requests to request reviews from non-engineers. Make sure everyone is asking questions or raising concerns.
We used to [inaudible] only on really big, big projects, but now we’re trying to add more consistently, even on medium sized projects. And so, that’s how we’re improving communication. And then every squad lead kind of meet with their team on a weekly basis to make sure they plan for the week. They have priorities and everyone is aligned. And then each squad chats with the rest of the team, “These are our priorities.” Or, “This is what we see could be risky or needs attention or we will input from someone else.”
JENNIFER: That sounds really challenging, going from one team to multiple teams is already kind of hard. And to do it at the same time as going unexpectedly remote sounds even harder. One thing I’m wondering is, are there ways for you to bring up the feelings that people are probably having about this while keeping that forward momentum of making the changes that you need in order for your team to be able to work effectively?
ALE: Yeah, absolutely. I have been using mostly one-on-ones to address some of these feelings. Also, we have bi-weekly meeting for team leads, which I think is another good forum to make sure that team leads are aware of maybe communication issues or things that could be improved across the engineering team. In general, I rely a lot on one-on-ones to understand how someone is feeling. For example, let’s say I noticed that someone’s communication wasn’t the best in a core review when a new engineer is proposing a change. Let’s say I noticed that. Usually my instinct is not to assume any bad intentions because I don’t really know what’s going on inside this person’s head. So I will bring it up during a one-on-one and say, “Hey, I noticed that this happened. And I think that the communication could have been handled better this way.” And I make an emphasis on highlighting why I think this could be impacting negatively the other person. And I try to share as much context as possible about that. And then I open up the conversation with a question like, “Why do you think this happened?” Or, “How do you think you could have handled it differently?” And then usually what happens is that the other person would share like, “Oh, I had too many things on my plate,” or, “I am really worried that we’re taking this technical direction because he has all of these phrase. And I worry that if we take on all of this phrase, then we would have too many incidents,” or all of these concerns.
And then when I hear all of that context, what I usually offer is advice. I try to reaffirm that those concerns are valid concerns. But he or she could have communicated those concerns in a way that the other person understands where you’re coming from. This is very helpful, especially when someone is feeling worried that they are giving away their ownership and things could change in a negative way. So I try to highlight like, yes, these are all valid concerns and I’m sure if you share these concerns with the other person, they will see where you are coming from and understand and work with you to address those concerns.
Another example that I think often happens is when someone new comes in, maybe they have done things differently in their old jobs and they bring in those ideas. I think for someone that has a lot of context, they may feel like, “Oh, are you saying we’re doing things wrong?” Or they may take it a little bit negatively. I usually try to remind to put yourself in the position that is someone new. They are excited. They want to contribute and they are being curious and trying to understand why we’re doing things this way, and almost trying to provide value by suggesting how we can do it better or if that’s possible. So yeah, I [inaudible] one-on-ones to kind of rehearse those conversations in a way.
JENNIFER: Wow, that’s really helpful. So anytime you’ve got a lot of change in your team, no matter what that change is, you need to dig into your one-on-ones and pull out the feelings about it. And then that tells you, the leader of the team, what you need to do to address it across the whole team. That’s great.
ALE: It feels almost like, when you’re an engineer and you have a bug – I’m not comparing humans to computers, of course. But you try to go into all of these different places where the problem could be and gather as much context as possible. That’s kind of how I approach these situations. I don’t want to make any decisions or judgments on what the problem is until I have all of the information.
JENNIFER: So using one-on-ones for context gathering.
ALE: Totally.
JENNIFER: This has been really great. Do you have any final words of advice for our listeners?
ALE: Yeah, I would say that even if you are onboarding new engineers without needing to go remote, I think that one tip that is also something that I try to practice that is really helpful is establishing right away that place of trust. So if something is not going perfect, you want to encourage that new engineer to give feedback as soon as possible and share anything that is crossing their minds that could help them or that could have been done better. And also, share that the process itself is not perfect yet. I know we’re learning. So there is always opportunity to make the process better.
JENNIFER: Thanks, Ale. And if people want to continue this conversation, what’s the best way for them to reach out to you?
ALE: I use Twitter and LinkedIn. My usernames are the same in both: ale7714.
JENNIFER: Cool. And you mentioned Latinas in Tech. Is that also a good place?
ALE: Yes, definitely. You can find us on Twitter, Facebook, Slack, just Google Latinas in Tech or go to LatinasInTech.org and reach out.
JENNIFER: Great. Thank you.
ALE: Thank you.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. I’m Jennifer Tu. Our theme music is by Kevin MacLeod. And we are edited by Mandy Moore and the DevReps crew.
If you like this episode, please think about leaving us a review on your favorite podcast listening platform. This can make a really big difference in helping other people find and start listening to Storytime with Managers. Thanks so much.
