You have to have autonomy, trust, transparency… all these things that make it possible for highly functioning teams to work well together.
Another special episode this week! This is the first Outside the Valley episode not hosted by me (you’re welcome). This week’s episode is a replay of our recent AMA session with CTO of TaxJar Matt Anderson. The AMA was hosted by our VP of Sales Mike Fossi, and a special co-host: VP of Engineering of Help Scout (and previous podcast guest), Megan Chinburg.
It’s a conversation between engineering leaders of two awesome remote companies talking about how the COVID-19 pandemic has affected their teams, figuring out processes and goal setting, and how they go about hiring the right person for their teams.
If you’ve enjoyed this episode, please consider leaving a review on iTunes!
The podcast is also available on your favorite players: iTunes, Google Podcast, Castro, Overcast, Spotify, Stitcher, Player.fm, and Tune In.
Follow us on Twitter to get updates.
Looking for top talent fast? See how Arc can help you:
⚡️ Find developers, designers, marketers, and more
⚡️ Freelance or full-time remote + fully vetted
⚡️ Save up to 58% with global hires
Hire top talent with Arc risk-free →
Topics also covered in this episode:
- How COVID-19 pandemic has affected Matt and Megan’s working routines
- How Matt and Megan kept the morale and culture of their engineering teams intact during this challenging time
- How they go about figuring out meetings and setting goals for their teams
- The hiring processes and interview questions at TaxJar and Help Scout
Mentioned resources:
- TaxJar
- Help Scout
- Matt Anderson
- Megan Chinburg
- Basecamp
- Fellow App
- Help Scout’s 12-Step Remote Hiring Process
Related episodes:
- Mark Faggiano of TaxJar: Creating Remote Employee Culture
- Megan Chinburg of Help Scout: A Look into Help Scout’s Hiring Process
Transcript
Mike: All right, good morning, everybody. We’re gonna go ahead and just wait about one or two minutes here to get started and I’ll kick off with some intros. But I just wanna give people a chance to go ahead and log in. You know, for questions and things, feel free to ask as we go along. It’s designed as an AMA format. So put your questions there in the chatbox and our host will get to them as soon as we can. But yeah, we’re just gonna give it one or two minutes here to kind of go ahead and let everybody jump in.
Okay, let’s go ahead and get things kicked off here. I’ll start off with some intros. So first of all, we have Matt Anderson. Matt is a CTO at TaxJar. He’s been leading a fully remote entity for about six years now. TaxJar is 100% remote team, and they’re helping e-commerce sellers to manage sales tax. So Matt’s currently based in California with his wife and five children.
And then next we have Megan Chinburg, she’s the VP of Engineering at Help Scout. And she’s been actually managing teams in a fully remote company for over four years. So she’s described herself an engineering leader who really loves building strong and successful teams while promoting collaboration, autonomy, and creativity, and personal growth. She’s also a cyclist and violinist who’s currently based in Italy.
And myself here is I am Mike Fossi, VP of Sales here at Arc.dev. We are the host of the webinar. If you’re interested in taking a look at Arc afterwards, more than happy to chat, I’ll put up my contact information. But Arc is a remote developer and hire platform. And we’re working to make it easier for companies to hire great developers who just happen to live outside your zip code. So if anyone is interested in looking at ways to kind of grow their engineering team after this, more than happy to chat. But let’s go ahead and get things started with some of the first questions we have. I’ll turn it over to the both of you.
Megan: All right, thanks for the intro. So, Matt, you’ve been managing remote teams for a while now, working from home though, during a pandemic, does present a new set of challenges. What’s the biggest difference for you as a leader during this time, and what are you doing to keep up morale on your team?
Matt: Yeah, these have definitely been some challenging times for all of us. I think what it is, is that we’re finding ourselves in a new context. So, people…you may have been remote, you may have been in an office and just finding yourself remote. But you’re finding that you’re working next to your spouse or partner or roommate or your kids are running around the house, and you have a new responsibility of taking care of them. And that’s really changed the context and I think that’s where the challenge comes from.
So for me, Mike’s shared that I do have five kids, but I’ve had the privilege like since they were young to be able to…with my wife to homeschool them. So I find myself where some of my daily context hasn’t changed. And so that allows me as a leader, that I’ve found to be able to put a little bit more time into focusing on like this new kind of care for the people around like, that’s beyond the normal care and so you have to have extra empathy. And so that’s kind of how I’ve addressed some of this time but then how I can turn and like give that back to my employees who have no idea how to have a couple of kids at home, teach them school, which is kind of a wild thing to put on parents you know, overnight, and then expect them to keep doing their jobs.
So I think that’s been a big part of the leadership is looking at that being able to give time to people who need it there. And then the morale comes beyond that, right, like tonight, you gotta look for ways to make people laugh, smile throughout the day, I don’t know, joke about the bad situation and do stuff like that. So we’ve seen a lot of new happy hours, like social hours, game hours, like people are playing online games for like an hour at the end of the day, just playing trivia games or whatnot, just to do something other than work and other than think about…you know, worrying about their family’s health and the health of their, you know, neighborhood or whatever. So, yeah, so continue to do those one on ones and be flexible. Those are a lot of things we’re doing at TaxJar.
Megan: Yeah, absolutely. We’re doing that as well, lots of happy hours and more get-togethers.
Matt: Yeah, you would have thought as a remote company we would have done a lot of those, but we didn’t, because like people didn’t, like crave them as much as they do now where they need, like, they need a little laughter. Like we’ve actually had…I think we’re on like, our third or fourth week with kid talent shows. So in the middle of the day, like, people just take a break, and the kids come on video and they do…like they sign up for talent, you know. I think there was one boy who recited his lines from the school play because the play got canceled. And so you know, he put his costume on and did his part.
Megan: Oh, that’s fantastic. We also did a show and tell where people could bring their kids on and they could do show and tell of anything that they wanted to share about. And I think today we had a trivia game that was hosted. So we’re trying to find new ways to create intentional social time. I love it.
Matt: Yeah, for sure.
Megan: Are there any of the practices that you regularly employ on remote engineering teams, that you find are especially helpful right now during these challenging times?
Matt: Yeah, so, you know, we’ve been fully remote at TaxJar since the beginning. That’s seven years now and counting. And so I think the collaboration and communication was required that whole time. We work together. We’re across time zones. We’re mostly based in the U.S. But we have someone in Hawaii, so like, that’s a seven-hour time zone shift that we’re dealing with.
And so we’ve kind of dealt with this, but definitely, the times are changing. People’s hours are like, a little different now where people have to like, come back later because they wanna you know, take care of family during the day or something. So, you know, Zoom has been great. So we’ve been on Zoom since 2016 and that’s really helped. Like, we just talked about the social hours or whatever, that allows a little bit of that context, to have facial expressions, whatever they need to kind of help the communication.
I think we just lean into those tools, right? Like, we’ve been practicing that and so we have to keep leaning in on those things. We use Basecamp and so there’s a lot of stuff there going on and it allows people to interact asynchronously.
You know, it allows people to set proper expectations like, hey, it’s not an immediate response. It’s like, “Hey, I just need a response soon.”
Like that continue to allow people to be collaborative without having to find the exact time that they used to work together, right, like, “Oh, my schedule is off.” So like, the only way…if the only way you can do something is to always be able to sync up on video I think that’s where you start having that challenge.
And that’s not just during hard times, but I think that’s when you start having these time zone differences and when you have these other things, you know, given that your teammates will continue to help communication I think.
Megan: For sure. I feel like all of the things that we do as remote teams and remote leaders, we now have to exceptionally double down on everything. Like that’s…
Matt: I think…you know, part of strategy for most business is to take advantage of like luck. And I think those who practice remote work or distributed work and were intentional about before this, are going to be like, “Oh, sweet, I can like lean in more on that because that’s what you need more of now.” And those teams that hadn’t yet practiced that or hadn’t really been intentional about it are finding out that, “Oh, if we document our decisions, and we have conversations that aren’t in the hallways, right, if we have better conversations, huh, we can do more.”
And I’ve heard that from big companies that have in-person teams like, man, we really quickly realized we should write down the notes from our meetings. And you know, we should document the decision on paper, or you know, or wiki, or whatever it is. And like, all of a sudden, your team has this ability to kind of detach from being perfectly synchronous and timed and they’re gonna be like, “Oh, like we could do this.”
And so they’re having to learn and fight. And I don’t see the remote teams I think so we have a little bit of advantage there of just… But what’s interesting to hear in that, right, like how to communicate more effectively, how to be collaborative in these challenging times.
And I’m hearing it from AMAs like this with, you know, big companies like Facebook and Slack and Dropbox, is like, “Oh wow, we can pick up some of the stuff that all these remote people are talking about, of asynchronous and writing cultures and stuff like that.
Megan: So to piggyback on that, so there are a lot of folks that are approaching remote leadership for the first time. Can you tell them what you’ve learned about building a great team, or I guess, a great culture on your remote team?
Matt: Yeah. So, culture is hard. I think a lot of people are always talking about it. And I think…like I don’t even know what it is and I don’t think a lot of people do, right. It’s just that thing, it’s kind of the how it feels to work somewhere, how people behave. It’s what people want, right, like their desires and how that plays out itself inside the company. Like I wanna be more competitive, I wanna be more creative, I wanna create an innovative company. No, I want a company that just does things perfect or something like that. It’s like very different kind of wants and desires, a little personality.
At TaxJar, we…Elaine Page who’s our VP of People Ops, she’s helping lead us on kind of assessing our culture and our dominant culture, like the one that exists now, the one that the employees want it to be. And it’s an interesting…it’s kind of like taking a personality test in my non-scientific point of view of this kind of stuff. But I think what you want to kind of think about your culture and building it is like, you don’t wanna be changing people. Like, you’re not trying to change who people are.
So I think one of the things is you gotta do great hiring. You gotta hire people who want kind of similar outcomes or similar like styles, right. Like, “I wanna be very creative,” so well, you probably should find people who are amicable or agreeable to that or really desire that. Because if you find somebody who’s against being creative and that you have to do it and they’re not amicable with it, you don’t wanna build that. Because then you’ll have this kind of culture of people where it’s pockets of different ideas. And I think that’s true in person, it’s true in remote.
So, let’s see, what would you say. So what have I learned? So I think it’s hiring, don’t settle if you don’t think it’s, you know, the right person. It’s not trying to find people like you because that’s…it’s finding people who are better at something than you, who are additive, right. I think it’s not trying to find just like you, then you don’t have a culture. And so, yeah, those are a few things there’s not one answer here because I think every company is gonna have their own little difference.
Megan: So given that folks are, you know, potentially transitioning from non-remote to remote now in our current situation, and they’re managing teams that used to work, you know, being able to pop into a room and whiteboard together, like there’s a couple questions in the queue that we could probably address around this like leadership/meeting management. So one person asks, “Are you using Agile Scrum? What sort of tricks in a remote environment or how do you do that well in a remote environment?” And kind of the follow up is, when teams don’t have time zone overlap how do you make those teams work?
Matt: All right, yeah, good question. Yes, we try to be Agile. We’ve had iterations of Scrum, to kanban boards, back the scrum style teams and really, you know, we use Jira and Trello. Early on, we used Trello and now we use Jira because it got a little more complex with dependencies and stuff like that. But we are a team of 45 kind of engineers and so we collaborate with the product team, and CSO. And so, you know, we form delivery teams of the product manager or an engineer manager subject matter expert kind of thing and then three to six engineers and they kind of work long-term but on projects with… So we try and set up like scrum. I think that’s the agile answer.
And I think we run into the same challenges that I ran into in a previous company where we’ve rolled out scrum, and we were very, like, strict about it. It’s just hard and we were all in-person. And so you always ebb and flow with the person, like, “I wanna do a lot of process,” “No, I don’t want process.” So I think that Agile part is always…it’s kind of interesting. As the team gets strong at it, then you pull back. As the team gets weak on it you have to push forward on the rules.
Megan: Do you have live stand-ups or do you have weekly sync meetings? Like how do you manage the time zone overlap or lack of overlap?
Matt: Our teams are part of Agile so they’ll do stand-ups, right. So we have ebb and flow between four or five days a week on a video call at some time that works for everybody. And now we’re at a point where most of the teams are probably, you know, maturing together. They’re like, “Let’s do two of those a week because we liked talking to each other,” and we’ll have three asynchronous check-ins.
So we’ve used Basecamp to do automatic check-ins that just say, you know, “What did you do today?” And so that way, they still get that face time that sometimes they want or need to work through a complicated problem when they do that.
We have a person in Israel, and we have a person in Spain, and then we have people all across the U.S. So like, we have a few time zone problems, but we’re able to where like within three or four hours, that’s easy to find an overlap. But like, Megan, I know you’re in Italy, like how does your team find that overlap?
Megan: We strive to get four hours of overlap, which is not 100% possible because we do have a designer who lives in Sydney. So like on that team, in particular, we try to avoid having folks from Europe on that team. So we do a little bit of time zone I guess, optimization on the teams when we’re in those extreme situations. But for the most part between…most of our folks work somewhere between the west coast of North America to I think our furthest east is Kiev, Ukraine. So we can get about four hours of overlap and that works pretty well for any sort of weekly meetings. And we do stand-ups using Slack so we do asynchronous stand-ups there.
And we don’t use Basecamp. I know you mentioned that you use that.
In terms of, like essential tools, in my experience when you have asynchronous like communication, documentation, and decision, documenting your decision seems to be the most important thing.
So between Slack and Jira, and face to face, Zoom, I guess face to face communication, as well as wherever we’re documenting our decisions are the most important.
And I think like some companies, we have a handful of tools that we use to document things and we try to create rules around like if it needs to be saved forever it goes in our wiki. If it’s, you know, ephemeral, it can go in whatever you want. Most teams standardize around something but no other special like remote management tools that we’re using.
Matt: Yeah, Zoom to talk to each other.
Megan: Zoom, yeah.
Matt: That’s what we’ve used, and Basecamp, we’ve tried to stay in one. We’re using an app called Fellow so it’s like fellow.co I think, I don’t know, fellow.com, fellow.com. But that’s been good across the company, across TaxJar to do like, track one on one conversations or even meetings, people use it for just the regular meetings and it helps having agendas, right.
So coming into a remote meeting with an agenda and people can see it ahead of time or you can document it after the fact. So that’s been a side tool that’s kind of on the managing side.
Another thing that was asked in the questions that I noticed was around OKRs, or kind of performance. And so I would think that’s another kind of tool you can use to manage the teams. We’re working on OKRs.
We’ve always done goal setting. But we’re starting to try to use OKRs because it provides a language and a framework for the goals we’ve already done. It allows us to communicate them better now that our team is like…we’re no longer 20 people, we’re 165 people.
So like, it’s very different, right? Like you need different kinds of communication tools, and I think that allows us to communicate those goals. And now we can have conversations with the teammates about those and our progress towards them and how they’re impacting them or not. And so that’s what we’re trying to do. We’ve never given it a name until maybe the last nine months. We’re actually like, okay, OKRs, let’s give it a shot.
Megan: Yeah, I find that especially with the remote teams, you can’t…it’s impossible to micromanage essentially.
You have to have autonomy, trust, transparency, like all these things that make it possible for highly functioning teams to work well together. I think having very clear objectives instead of directives is like the critical ticket.
OKRs can help with that.
Matt: For sure.
Megan: So we can change the conversation just a little bit and start talking about hiring. So at Help Scout, we have a pretty rote 12 step process that we follow. We have a blog post about it so anybody can read it, you know, get all of the insights they would need to kind of ace our interview process. Can you tell us a little bit about TaxJar’s hiring process and what’s worked well for you?
Matt: So I was part of hiring every employee from the beginning, from when we were just three of us kicking around the idea. But now we’ve built a team so we have a process. I don’t know if it’s 12 steps, but it is definitely a repetitive process we do for all employees. So now it’s like an entire team of people who get involved in, you know, the application and email exchange, then some interviews on video. So we do some Zoom that kind of tell you about the process, like to introduce you to the process, talk maybe a little bit about compensation and the title upfront, just to make sure that we start off on the right foot and there’s no hidden, you know, expectations on that.
And we do video interviews, right. So across the team, we do like…we call them cultural interviews, but they’re really just interviews from people in other departments that you would probably partner with or be co-workers with. And so we give them a chance to provide a different perspective and it’s usually a panel so we can get multiple points of view from the same exact questions. I think what’s worked really well for us… You know, what everybody at TaxJar would talk about because it’s probably the most unique thing is we do what we call a mutual assessment.
And that is that we try and move through the video interview process. If it means a technical, we do a technical one. But like we get to that and then we say, “Come work with us.” We’re like here’s contract to hire, it’s kind of an old term, but like, give us some amount of time, where over the course of…as much as 30 days, you know. If you need 30 days to break this time up, but
…We wanna see you do a real project with your teammates, right, like of all skill levels. And we get to see them at work. We get to see that they can show up on time. Like if they told us they were gonna show up, we want them to show up on time and do the work that they said. We wanna see how they interact with people who did the interview, right.
It is a test that you can do remote, but it’s also just what’s worked really well. It’s just to get to work with somebody because you can really tell this is gonna be long-term and we want long term fits, we don’t want quick. So we wanna invest that time upfront and we invest our time into it. We’ll compensate for that portion of the interview on an hourly contract rate. And we wanna see the candidate is kind of ready to invest in kind of a long-term partnership. So that’s probably been the most striking piece for overall texture in hiring.
Mike: I wanted to jump in. Could you maybe elaborate a little bit on the 12 step process that you guys use? And if there’s anything that you think really helps kind of change the process that was unique to you guys, or something that’s really helped to identify better talent in that?
Megan: I’m not sure if it’s anything really, like, expressly unique about the process. It’s very similar to what Matt said. We start with…we have a team, everyone agrees on the interview questions ahead of time. We have specific interviews that are looking for specific things. So the very first call is all about value-add. I guess some teams might call this a cultural interview, but what we’re looking for is you know, are they gonna bring value to this team in a way that you know, not only supports our company mission and values but also they’ve got something special to bring.
And then we move on to a technical interview, which has a couple of different parts and it varies by team. But we started handing out a snippet of code before they go into that interview. And so the candidate will read through it, prepare, and then they’ll walk through it with the engineer doing the interview. And so they can kind of see how they might critically review a snippet of code, which is pretty enlightening. And then we always go through a logistics call, just like, you know, talking about salary expectations, you know, benefits, that sort of thing.
And then we have a project. So rather than a contract-to-hire, we have a project that we have scoped down to about six to eight hours. And we did have one of our engineers do the project himself so we could test our theory of whether that was actually a six to eight-hour project.
Also, we graded. We had two of the folks who usually grade the projects, grade his project. They didn’t know it was his project, although one of the engineers did say like, “This looks very familiar,” because they’ve worked together for a lot of years. So pretty brave on that engineer’s part to go through that. But we wanted to check ourselves and make sure that we are asking for something reasonable. And so then, following the project, which is completely…you know, we’ve removed anything that could tell…you know, could trigger a bias. We’ve removed the name, the people who are doing the review of the project, have no idea who’s in the queue, who they could potentially be looking at. And then following that, there’s also two people doing the reviews and they don’t get to see each other’s scores until the end.
So we do a lot of intentional bias removal in the process.
And then at the end, usually the candidate will talk to myself or maybe the CTO or in some cases, both of us, and then we move to the hire process or the onboarding process. And maybe what’s unique about us, I’m not really sure, but I haven’t seen this at other places I’ve worked, for at least the first week, we highly emphasize just getting to know Help Scout, getting to know our customers, getting to know our voice, our values. We have people work in our customer support queue so they get to talk to our customers and learn how we like to talk to people.
And typically, developers are not going to be committing code until you know, the second or third week because we really like to give them that space and time to digest everything. Because it’s really the only time when you start at a company that you don’t have a bunch of people asking you for work, and asking you to do something. So we really like to give that time.
I guess the other unique thing that we do is we always have a…we call it the work BFF. So we pair someone up with another person sometimes on their team, but sometimes from a completely different team just so they have someone to bounce ideas off of. Ask like, “Where do I find this?” You know, give them a little bit of support as they onboard. Specific interview questions to see if an engineer is a good fit, that’s one of the questions that came in. Matt, do you have any?
Matt:
I ask from a lot of people about the last time they broke production. It’s not about remote work but I think it shows some characteristics. Like I like to learn because I like to know what they broke and what they’ve learned from it, right? I expect to hear some experience there. But did they take charge of the situation? Were they honest? Like, did they hide from it? Did they step up for it?
Because I think in remote, you wanna know people are gonna take ownership. You wanna know people are gonna step up and say something.
So I think it’s both a technical question, right? Like it’s kind of figuring out like, what history do you have to, you know, help your decision making in the future? I think a lot of that helps with remote. It’s probably one of my veiled questions that gets at remote because I think we all ask, like, how many team members… Well, what is a remote situation? So we do wanna hear that too, right, like we wanna hear about their prior situations. But I think you can see it in how they do their coding.
Megan: And in terms of specific technical questions, I wouldn’t say we have any specific technical questions that unveil whether the engineer is gonna be a good engineer because that is hard to ask for. And the project is what really helps. Like we actually get to see them code. So most of our questions around like, would you be a good fit are more around like, asking questions that dig at humility, ownership, empathy, mentorship, thoughtfulness, things that we really value in anyone at Help Scout.
I guess we do have a couple of questions at the beginning of the technical interview that I would say are pretty easy. You know, they’re more like, you know, kind of like level 100, level 200 computer science questions. And they actually uncover quite a bit about the person based on how they answer because if they scoff at you, and you’re like, “Why are you asking me that question?” Like, depending on how they answer that that will tell you a lot about that.
And I think you get more information by digging in on a project that they’re really excited about, like, how deep can they go on it? How do they explain it? Especially for me when I’m interviewing because I’m very distant from being a developer at this point in my career and so I look for how do they explain something highly technical to me because communication is huge in remote culture. So that’s another thing that we look for.
I’m very curious about this Matt because at Help Scout we have not yet crossed over that, I don’t know, that threshold of being able to hire junior folks to our team. Right now most of the people that we bring in have somewhere between 5 and 20 years of experience in the industry. And I’m just curious if you’ve been able to hire junior engineers, and if so how have you approached that?
Matt: I guess it depends on what you mean by a junior engineer. But we’ve definitely had to be cautious there, I think as any small growing team would be because you know, your teammates only have time to invest in building the product, and like, they’re being asked for that much time at the early stage when you’re building the company that’s your focus. So you don’t have the ability to be the mentor. So you have to be cautious, right? Like you wanna hire them but you don’t have time for the senior, like more experienced teammates to give them that full attention.
And so what we have as the teams grow we have found success. And what I would kind of call a junior engineer, they have some experience, right? Like, they’ve gone to school. They’ve, you know, done something on the side for a while where they’ve seen it. The people we’ve hired that are really early in their career, like really recent graduates of like Codecademy or Code School, or AP University, but they have some production experience, like they’ve been around a team that have customers and they’ve deployed code to that.
Now, the level of contribution there is different, but that’s kind of been the bar where we said, “Hey, you’ve at least…we need you to have at least experienced Jira, or you know, agile planning with a group of people in-person or remote. And you had to see your code…like a demand for your code and you got it out.” Because I think that…on a small team, that’s growing when you’re being asked to meet new demands to find customers just to you know, make money you’re not in a position like an IBM or a large group is. They have teams that have had years, decades to build capacity to train, mentor, you know, people earlier in their career.
And you know, like where I started, I started with a big company because they had more roles for people with…you know, like, there’s not as many roles on a team. You know, I think, like our sizes at Help Scout and TaxJar, they’re not hundreds of engineers. So that’s been kind of the conversation I’ve had with myself, and now with my VP of engineering and staff is like, how do you balance teams out too?
Megan: Right, exactly. And can you talk a little bit about your onboarding process and maybe specifically, like if you do anything different for folks who are less experienced in their career, but just in general, what are the practices that you use for onboarding?
Matt: Yeah, we’ve really grown here as a company in the last two years, like we…it was about two years ago, we really got intentional because we were getting…you know, we had 30, 40 employees. It was like, oh, man, we’re gonna hire more? We better get…like, show them around now there’s a lot to see at TaxJar.
So we have templated projects that get spun up for new employees or actually employees during the mutual assessment process get one. And then if they do become a full-time employee, we have a whole another one which, you know, gives them a checklist of things to do, gives them people to talk to or videos to watch about the company documentation. So we do all that for the engineers. You know, they get assigned to a team. They get to meet their teammates. We’ve built a project that kind of does… We have one available for their laptop, right.
Because actually, you know, we use MacBook Pros, for the most part. Some people wanted to go off of that. But we have, you know, a laptop script, I think kind of…I think thoughtbot has one out there that’s published, that starts your machine, right. I think it’s everything installed like the tools that you would need. By default, we have one that actually pulls down the repositories for one of our primary apps and seeds a database and builds out all just out of a shell script. So like that helps too, right? And it could be better because as the system gets more complex and we do more container stuff we can improve help but that’s growing pains that we…like, “Oh, we outgrew the tool we used to use, and we have to rebuild this.”
So you continually kind of…I do that which helps onboard and helps like me get a new laptop and get back into coding, right. So now I can actually reset my environment if a laptop breaks or something like that. You know, every engineer, I think this should be stated for those of you… Like, regardless of if you’re remote like when you join a team, it’s gonna take some time to get familiar with code, get your local environment working the way it needs to work to test.
And I think we try. Like I want our organization to get people to that aha moment or whatever, faster, right? It should be a day, but sometimes it’s a week, because like, they forgot an environment. We forgot to update the documentation about a new variable or something like that and like for the whole week, or…you know, like, it just doesn’t work for them. They can’t do something locally. They have to like push it up onto the cloud. And so I think that’s how you measure or how you should measure how people are doing onboarding too for engineers, just can you get to the coding? Can you get to doing your job? Do you have a setup script or are you doing containers like Docker to get people running on code fast?
Megan: Not 100% across the organization. I wish we did but we’re making progress towards it. Like of course that’s kind of the end goal is that we can say here’s your laptop, like, you know, go run this, and like poof, you’ve got your local development environment and you can quickly get coding. It kind of depends on which team you’re on and which services you’re gonna work on because some of them are easier to get to that containerized deployment state than others. But that’s the goal for sure. So there’s another question that came in asking is there anything different when it comes to onboarding a remote developer versus a co-located one? Do you wanna take this?
Matt: I mean not because they’re a developer. I think… Yeah, so there’s different stuff you do because they’re a remote employee. We don’t fly anybody anywhere to meet them but we do try to have two retreats, company-wide retreats each year and that’s where they get to meet. So if you’re hired just before one, like you’re off to the races because you meet everybody. Some people have to wait six months for that experience.
But I think everybody, whether you’re gonna be sitting with them or whatever, you’re gonna have to onboard them at some point. Now, I don’t think… So maybe documentation like, rather than a conversation, you wanna use documentation, right. So I think that might be it where if you’re co-located, you’re gonna look over the wall and say, “How do I set this up? What does this part of the code mean?” or, “How do you guys do this process?” You’re probably gonna ask somebody for a verbal co-location, but yeah, remote you’re gonna have it written down.
And so I think that’s probably the biggest difference. But you do that for the whole remote employee, you have to write everything down, or record it or something. Just because you don’t know if you’re ever gonna do it…you’re gonna do parts of it live but you don’t know how much overlap you’re gonna have. So, it’s what I would say.
Megan: Yeah, documentation becomes like your own internal product that has to be kept up to date, and I feel more way more so than when you’re co-located. Sure.
Matt: Yeah. I could say…so it goes back to some of the earlier questions and I didn’t say this then but it goes to documentation. And I think this is something you practice in a way at Help Scout, Megan is documenting your decisions. So I think that’s been really important. And we’ve changed, we’ve recently changed how we do this. Like we’ve always had message for posts or Google Docs of decisions along the way, like we’ve had those artefacts more written down but we’ve changed how we do this.
I was introduced to this tool, it’s called the Spade toolkit whereby it was brought to us from…a new employee brought it to my attention but it’s from somebody else. And we’ve kind of made it our own a little bit, or we’re just kind of making it our own, where there’s more of a framework to the decision. And we use…since we use Basecamp…I mean, you could use Google Docs too, or whatever tool you’re using.
You have to like, @mention people, and specific roles in the decision process to battle consensus, or, like, people are waiting for more information.
So the idea of this page does is it allows anybody on the team to be responsible for the decision and they put their name on it. They need an approver. It could be a teammate, it could be a manager, it could be a subject matter expert for the system you know, whatever. They have to figure that out and get agreement. And then they like, @mention a whole bunch of people they think have an opinion, right? Like I think these people have an opinion.
And what that does…before we weren’t @mentioning people, and we would just start the thread, and then somehow it would end. What we’re finding now the thread is a big team, more complex problems, the threads would never end. People would, “Oh, no,” they would keep refining the idea. And now we’re like taking it back to the original person and say, you don’t have to wait for that to finish. You have this documented. Now you can make your decision and move along.
And I think that’s been a huge part of the written communication. I’m seeing it help because we were starting to write too much. We were starting to wait, “Oh, I gotta give another eight hours for somebody else to respond, because I gotta wait for some time zones to pass.” And it’s like, no, they each had their…like you gave more than 24 hours. You gave… Everybody had a chance. And I think that’s helped us because that is a part of remote decision making, or when you come to a problem in remote, it’s like, you can’t just ask somebody next to you and move on. You have to like go to the documentation, but then you start waiting for more time or you don’t know who’s making the decision. I found that to be really powerful recently to help be asynchronous, stay asynchronous.
Mike: Cool. I just wanna jump in here as we’re approaching time. So if anybody has any final questions for our hosts here, feel free to post those in the channel now because we’re gonna start wrapping up here shortly. So anybody else, now is a good time to ask any additional questions. All right, well, looks like you have too much going on. Debbie has one here that the teams for…the teams pair program that you both kinda talked about.
Matt: But in the truest sense, but we do…the team will kind of…at times different people will fire up their Zoom and spend an hour working through the code. So like they’ll do what you see in an office where two people sit in a cube just to solve a problem and then they go back to their desk but we don’t do the long-term pairing.
Megan: Same approach at Help Scout.
Matt: That’s a great question.
Megan: The question was after going remote for the first time what surprised you the most? What kind of misconceptions do you think people have about remote work? I have a hard time answering this because I’ve actually been working remotely since I graduated from college just a long time ago. So I don’t know what the misconceptions are. I think maybe what surprised me more about working from Help Scout is just how successful it can be, especially when you have, you know, very clear objectives about what the company is trying to do so that the teams can form their objectives.
And then you have a lot of trust between leadership and the teams, a lot of transparency between leadership and the teams, and a lot of autonomy, which also comes with a lot of responsibility.
And so there’s this circle of trust and transparency that I think if you didn’t have that it would be very difficult to be a successful team. I think you could do it, it’s just it would always feel like you’re fighting something. I guess the misconception could be that companies could actually be incredibly transparent and extend a huge amount of trust and autonomy to folks outside of leadership and still be very successful.
Matt: Yeah, for sure. We operate very much the same way, very open. I think people are surprised by that, who are new to our company, at least about remote. And I’ve seen that across a lot of remote companies I think it’s kind of a requirement just because of the distance between people. And you know, I think misconceptions…I think the people who…it’s you’re not working and this is very much work. Like I work just as hard because I’m at home and so does all my team, right? It’s not an easier job because you’re working from home. It’s still work. So I think some people think it’s people goofing off sometimes.
But the people who are trying to get remote work don’t think that. I think that’s the misconception from a lot of people who were forced to it. They were like, “Oh, man, I thought this was gonna be easier and it’s actually harder because of the separation of family and work. So that could be one. I see a question about biggest challenges. So that would be something you know, just separating that or turning it off. How about for you Megan?
Megan: Separating work from…I’d say the biggest challenges that I see at the team are making very large decisions that have wide impact across multiple teams. So we have every six months remote retreat as well…sorry, we have a retreat.
This last retreat was remote, but we do retreat every six months and we find that…like, we’ll save these really big, meaty problems and then we’ll solve them in like 45 minutes with everybody in the same room. And like it could be something we’ve been talking about for the last two months. So those sorts of problems are always easier to solve when everyone is in the same room. So we haven’t quite cracked that one. I’m gonna say it’s a big challenge.
Matt: Question about favorite tools for staying on track. Whatever one works for the team because there are so many, Jira, and Pivotal Tracker, I don’t know, there’s spreadsheets, I think Trello you know they all will help you. It depends on my team because everybody’s gonna have their own preference for the tool they pick.
Megan: Yeah, I mean…
Matt: Do you have time for that question about the remote retreat because I haven’t done one. I think we might all be thinking about having them. I guess we’re having them this summer.
Megan: Yeah, exactly. So we just went through one in March, and it was as successful as it could have been. And our Head of People Ops wrote a blog post about it so I just dropped it in the chat and you can read all about it. It was really fun. We just scheduled a lot of like, fun activities. We said no work you know, all play. We had happy hours. We had fun games. It ended up being really great, despite the fact that we didn’t all get to go to Dublin.
Matt: Yeah, they do help. And so I think that is a challenge in remote is trying to figure those things out. We figured out how to solve other problems so I know companies like ours can do those kinds of things, like we’d work through together and we figure it out.
Megan: There was one other question. Braandon asked about any favorite tools for staying on track with longer-term projects. Again, like no extra special tools that you wouldn’t use, I think in a co-located company. I would just say don’t underestimate the power of sync of meetings. Like, I know that people tend to hate on meetings, but like 15 minutes can align a bunch of people way faster than trying to work it out through a tool.
Matt: I agree with that.
Mike: You know, any final questions? Put them in now otherwise you know, we’ll hear any closing thoughts from either of you and I’ll go ahead and wrap this up. Looks like no more questions. So yeah, anything you guys wanna kind of, say, finalize for covering today’s topics or…?
Matt: No. Thanks for joining us. And Megan, good to have you here.
Megan: Yeah, it’s great. I enjoyed it. Thank you.
Mike: Excellent. Well, thank you both so much for taking the time to do this. I think there are a lot of great takeaways here and it’s a very interactive conversation. So we really appreciate both of you taking the time. For everybody out there I’ll be following up with you know their Twitter handles, if you guys want to follow them there, and then contact information for myself as well as recording for the webinar today. But feel free to reach back out if you wanna get in touch otherwise, we’ll go ahead and end. And thank you, everybody. Stay safe and continue to follow Arc for more sessions like this. All right, thank you. I’ll talk to y’all later.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
